Why We Use Om, and Why We’re Excited for Om Next

I was the main author of Circle&#x27;s frontend (the code is open-source: <a href="https:&#x2F;&#x2F;github.com&#x2F;circleci&#x2F;frontend" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;circleci&#x2F;frontend</a>).<p>I went on to build Precursor (<a href="https:&#x2F;&#x2F;precursorapp.com" rel="nofollow">https:&#x2F;&#x2F;precursorapp.com</a>), which uses Datascript (<a href="https:&#x2F;&#x2F;github.com&#x2F;tonsky&#x2F;datascript" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tonsky&#x2F;datascript</a>) to accomplish a lot of the things that Om Next promises. If you haven&#x27;t tried Datascript, you should really take a look! It does require a bit of work to make datascript transactions trigger re-renders, but the benefits are huge. It&#x27;s like the difference between using a database and manually managing files on disk for backend code.<p>My understanding is that Om Next will integrate nicely with Datascript, so you can keep using it once you upgrade.<p>If you&#x27;re interested in learning more about building UIs with Datascript, I&#x27;m giving a talk on Monday at the datomic&#x2F;datascript meetup: <a href="http:&#x2F;&#x2F;www.meetup.com&#x2F;sf-datomic-datascript&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.meetup.com&#x2F;sf-datomic-datascript&#x2F;</a>. I&#x27;ll be going over Dato (<a href="https:&#x2F;&#x2F;github.com&#x2F;datodev&#x2F;dato" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;datodev&#x2F;dato</a>), a framework for building apps like Circle and Precursor.

I&#x27;ve spent the last few weeks building a side project in Om Next, and this article is spot on. Really excited to see CircleCI&#x27;s plans to migrate, as it&#x27;ll be fun to read their code and learn how they use it.<p>Relay and Falcor are great, but when I look at their docs it&#x27;s unclear how to integrate with whatever backend I want (especially Relay). Looking at Om Next, it was totally clear how to write my own backend. The tradeoff is that everything is a little more manual, but that control gives you a ton of flexibility.<p>In a small amount of code, I have a client that can query financial data in a bunch of different ways, and if the data isn&#x27;t available it sends the query to the backend, which executes it against a SQLite database and returns it to the client. The components are all unaware of this: they are just running queries against data and everything just works.<p>Combine this is with first-class REPL and hot reloading support via Figwheel (both frontend and backend) and I&#x27;m blown away at how fast I&#x27;m going to develop this app.

It seems like the setup I use is pretty similar to Om Next, but via independent libraries. I am looking forward to seeing the finished Om Next to compare.<p>ClojureScript is shaping up to be a fantastic way to program browser-based applications. This is what I use:<p>* Reagent -- another ClojureScript React wrapper<p>* Datascript -- An in-memory database with datalog query lang, this is used as the central store for all application data.<p>* Posh -- Datascript transaction watcher that updates Reagent components when their queries&#x27; return data changes<p>* core.async -- used for handling any kind of event dispatch and subscription. I do a unidirectional data flow type thing and it only took like 15 lines of ClojureScript.<p>This is one of the nicest front end development experiences I&#x27;ve had. Just the composition of these four libraries gives you a ton of flexibility and a good way to structure your application. You can use this setup to write a real-time syncing&#x2F;fetching system with a backend database pretty easily.

Our team used Om for our app (balboa.io) for the first 3 months of development. We switched to Reagent and have been using that for the last 8 months.<p>We ran into the same problems with Om as the CircleCI guys, specifically: 1) our front-end data model wasn&#x27;t complex enough to merit a heavy-weight data access system that required a huge amount of extra digging to get right. We spent far too much time arguing about how to structure app-data, and it only got worse as the app got more complex. The cursor system in its first iteration was just too cumbersome (for exactly the reasons this author states). We kept trying to restructure the data model in order to get it to do what we needed. To be fair though, this is well known, and David Nolen has done a lot to alleviate this in recently releases (ironically by making it more Reagent-like). 2) our app is end-to-end encrypted and requires pulling down potentially hundreds of blobs, decrypting them, and inserting them into the dom. Under these conditions, Om would kick it and the UI would grind to a halt.<p>We switched to Reagent, and found that it was far faster and &quot;got out of the way&quot; of development. Add-watch is amazing too. Our app is quite large (front end SLOC is around ~50k lines), and Reagent has scaled beautifully and is a beast at large-scale insertions (on the order of 1000).<p>Om has some delightful features (undo ability is very powerful, routes coupled with Secretary is also great for Om), and David Nolen is a genius, but I think even the author has to acknowledge that the app-data&#x2F;cursor construct is more of a pain than it&#x27;s worth...

I really like David Nolen as a conceptual visionary. His work with Om and core.logic is great and has inspired a lot of derivative work. But I would <i>never</i> rely on his libraries in production. It seems like he always gets to 90% before moving on to the next new thing. 90% documentation, 90% cljs-&gt;js coverage, 90% tested, 90% issues addressed. I wouldn&#x27;t touch Om unless I was willing to employ at least one person to work on Om full time.

&gt; Most data is not a tree<p>This is huge. I think it might even be the single largest problem to most projects&#x27; progress. I&#x27;ve seen a lot of projects that have tried to force non-tree data into tree-structures, and it never works out well. Projects grind to a halt after 6 months to a year because nobody can keep track of the dance steps they have to do with the tree-oriented code to manage their graph-oriented data.<p>Real, actual tree structures are just incredibly rare. Even some things that &quot;obviously&quot; seem like they should be modeled as a tree are far better off as a directed graph. Like databases of family trees - it&#x27;s possible someone is literally married to their sister! Less cringe-worthy examples involving large families living near other large families with generational overlaps causing the children of one group marring the grand-children of the other, and vice versa.<p>You don&#x27;t really <i>need</i> React. If you can do the ostensibly hard work of figuring out the DOM edits yourself, your app will actually be faster than if you&#x27;re using React, i.e. React has its own overhead. As long as the data relationship was right, I&#x27;ve never found it difficult to manage state thereafter. It&#x27;s when the shoe doesn&#x27;t fit that things become a problem.<p>The problem is, we have a systemic problem of treating front-end devs as not &quot;real&quot; developers, not capable of forging their own paths. It&#x27;s not just from the outside-in, I see a lot of front-end devs lacking a lot of confidence in their own skills. As a culture, we yell at any JavaScript programmer going his or her own way, building their own thing. &quot;Don&#x27;t reinvent the wheel!&quot; they are told. Screw that. I can think of at least 3 times off the top of my head that the wheel itself was significantly and usefully re-invented in the 20th century alone. The problem is not &quot;reinventing wheels&quot;. The problem is this institutional fear of making ones own decisions, leading people to think they need to learn <i>everything</i>.

&gt; Application state as a single, immutable data structure.<p>react-cursor gives this pattern in javascript, immutability and all, but with regular old javascript objects. It also comes with all the same caveats as in this article. (I don&#x27;t speak for the creator of Om, I speak for myself as the author of this library which was inspired by Om and Clojure)<p><a href="https:&#x2F;&#x2F;github.com&#x2F;dustingetz&#x2F;react-cursor&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dustingetz&#x2F;react-cursor&#x2F;</a><p>The beautiy of the state-at-root pattern with cursors, is that each little component, each subtree of the view, can stand alone as its own little stateful app, and they naturally nest&#x2F;compose recursively into larger apps. This fiddle is meant to demonstrate this: <a href="https:&#x2F;&#x2F;jsfiddle.net&#x2F;dustingetz&#x2F;n9kfc17x&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jsfiddle.net&#x2F;dustingetz&#x2F;n9kfc17x&#x2F;</a><p>&gt; The tree is really a graph.<p>Solving this impedance mismatch is the main UI research problem of 2015&#x2F;2016. Om Next, GraphQL, Falcor etc. It&#x27;s still a research problem, IMO. The solution will also solve the object&#x2F;relational impedance mismatch, i think, which is a highly related problem, maybe the same problem.

This is a more coherent summary of Om than exists elsewhere, including the official Om site.

What&#x27;s not stated in the article, re: &quot;Why we use Om&quot;, is that much of Om&#x27;s adoption was because of its high-profile creator and all the status&#x2F;momentum that brings along.<p>But I think it&#x27;s approaching a consensus already within the CLJS community that, on API alone, reagent is the React interface you want.<p>It&#x27;s extremely elegant and performant; probably the best frontend library I&#x27;ve ever used in close to a decade of web development.

So I&#x27;ve been looking at Elm recently, what would the advantages&#x2F;disadvantages for something like Elm over Om&#x2F;Om Next?

Clojure and ClojureScript for president in 2016! No, but seriously, one of the most promising pair of practically useful languages in existence.

I would love to see some code examples of this part &quot;If we try to show a component that needs to know the current user’s initiated builds, that triggers an API call that asks the server for the data. If we stop using that component, we stop making that request. Automatically.&quot;<p>I&#x27;m currently knee deep in a react&#x2F;redux implementation, which I guess is quite similar.

I am surprised their backend is written in closure. I would think it make hiring developers much harder (smaller group of people know it) and training people a lot harder. You can jump on to a project and learn enough go to fix bugs in a day or so (less than a week for sure). I am not sure the same could be said about closure.

&gt;2 We could throw out the entire list and rebuild it in one go, but re-rendering large amounts of DOM is also slow.<p>Out of curiosity I tried swapping &quot;&lt;ul&gt;&lt;li&gt;Artichokes&lt;&#x2F;li&gt;&lt;li&gt;Broccoli&lt;&#x2F;li&gt;&lt;li&gt;Cabbage&lt;&#x2F;li&gt;&lt;li&gt;Dill&lt;&#x2F;li&gt;&lt;li&gt;Eggplant&lt;&#x2F;li&gt;&lt;&#x2F;ul&gt;&quot;<p>and the same without the broccoli and dill, back and forth a few thousand times using jquery.<p>The average time per change was 28 nanoseconds or 35000 changes per second (Chrome, MacBook Air). Trying swapping a list of 300 fruits for a list of 500 fruits was 1.4 milliseconds per change.<p>I wonder if using some convoluted framework to &quot;solve—or at least mitigate&quot; this might be premature optimisation? (As well as actually slower).

Can anybody comment on how security is handled in Om? How do you ensure that certain parts of the database (which may depend on complicated rules) are not inadvertently exposed to the client?

&gt; We could insert new list items into the existing DOM, but finding the right place to insert them is error-prone, and each insert will cause the browser to repaint the page, which is slow.<p>I don’t think the last part is true. Browsers don’t repaint (nor they reflow) the page until it’s really needed. So if you have a loop that modifies the DOM multiple times, but does not read from the DOM, there performance hit described by the author should not occur.

Essentially this is exactly what we have with Redux and pure JS. Gaearon has led the way here:<p>- Redux as your single state tree&#x2F;graph<p>- Normalizr to denormalize data and store it in a graph, including pulling nested resources out as records<p>- Reselect to query on your denormalized data<p>And the best thing is this is production ready, in JS, today.

Nice article! I&#x27;m the author of <a href="https:&#x2F;&#x2F;github.com&#x2F;zubairq&#x2F;AppShare" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;zubairq&#x2F;AppShare</a> which using Om, and can say that Om Next is definitely the future of clojurescript apps

&gt; Om’s creator, David Nolen, likes to show off how easy this makes it to implement undo: just remember a of list old states, and you can reset! the state atom to any of them at any time.<p>How does that work if multiple users are collaborating on the same state simultaneously?

The post mentions borrowing ideas from GraphQL and Falcor: if I used GraphQL or Falcor, is there some pain I&#x27;d hit that Om Next would avoid?

The new plan sounds a lot like Redux.

does anyone know how challenging it is to add Datomic subscriptions to Om Next?

For a lot of companies however a good first step would be to ensure that the pages work w&#x2F;o Javascript.<p>When a basically crud website tells me my perfectly fine browser isn&#x27;t supported I say: FAIL.