om VS rum

We're pleased to announce that our client GreenPowerMonitor has allowed us to open-source re-om, an event-driven functional framework which is giving new life to an existing legacy SPA that uses Om.

Not sure if it is still the case, but Circle used Clojure/Om [1]... when I heard them say they did that so many years ago, I knew right away it would end up being something nobody wanted to work on.

Sure enough, just checked, Om was abandoned [2] and the person blogging about how great everything was is long gone [3]. This is the absolute definition of tech debt.

[1] https://circleci.com/blog/how-circleci-processes-4-5-million...

[2] https://github.com/omcljs/om

[3] https://circleci.com/blog/why-we-use-om-and-why-were-excited...

Om (https://github.com/omcljs/om)

Maybe it will be useful for someone: wrappers for ClojureScript over React.js is quite a lot. Here are some, besides reagent/reframe: https://github.com/omcljs/om https://github.com/levand/quiescent https://github.com/roman01la/uix . And here are these UI components: https://github.com/priornix/antizer looking, as it seems, not bad.

(Note that Rum is also a React wrapper, but you don't have to use that part of it; you can simply use it for static rendering of HTML.)

https://github.com/tonsky/rum

I love React as long as it has a thin skim of clojurescript over top. Rum is the underdog compared to reagent but is still my weapon of choice - https://github.com/tonsky/rum

Was disillusioned when I had to dive into a pure js project using it.

The real benefit, I think, is that you get the well established Clojure idioms around isolating and managing mutable state.

State is stored in a Atom, which is atomically mutated, and reactive components essentially 'subscribe' to updates upon that atom to re render.

The mutations can be handled centrally by a message queue, but really, event sourcing like that is not always needed.

We've been using re-om during the last 6 months and it has really made our lives much easier. Before open-sourcing it, we decided to extract from re-om the code that was independent of any view technology. This code is now part of reffectory and it might be used as the base for creating frameworks similar to re-om for other view technologies, like for example rum, or even for pure Clojure projects.

I've had an in-browser animated meme editor in the freezer for a few years now:

https://www.ultime.me/

The idea came when I wanted to make a simple animated meme, but found it exceedingly frustrating to caption a simple animated gif with nice text options (like outlines). Over time, it's grown to have full keyframe animation for all text and image/video clip attributes, so it is actually pretty capable short of using a desktop video editing/fx package.

That said, the UX is bad and I should feel bad :) . I made the deliberate choice up front to focus on the underlying data model and internal APIs rather than polishing the UI - as such, it is very much an engineer interface. It would be more usable with some demo videos or call-to-action helpers for new users, but really the UX just needs reworked. Especially around animation/keyframing.

On the bright side, the clean data model and content addressable assets leave the path clear to add things like collaborative multi-user meme editing, git like meme-forking(and diffing?), and so forth.

Started it about 3 years ago when I had a period of mostly free time to play. It's been idle for a long time due to starting a family and getting consulting momentum, but I'm intending to make the time this year to polish the UX to the point of general usability and experiment with promotion/monetization. Failing that, I'll probably just open source it and write a couple of blog posts about the internals.

It is more or less a static web app, with no server side function short of some optional stats collection. It's written in Clojurescript/Clojure and uses https://github.com/tonsky/rum as a React wrapper and