Why We Use Om, and Why We’re Excited for Om Next
blog.circleci.com
blog.circleci.com
I went on to build Precursor (https://precursorapp.com), which uses Datascript (https://github.com/tonsky/datascript) to accomplish a lot of the things that Om Next promises. If you haven'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's like the difference between using a database and manually managing files on disk for backend code.
My understanding is that Om Next will integrate nicely with Datascript, so you can keep using it once you upgrade.
If you're interested in learning more about building UIs with Datascript, I'm giving a talk on Monday at the datomic/datascript meetup: http://www.meetup.com/sf-datomic-datascript/. I'll be going over Dato (https://github.com/datodev/dato), a framework for building apps like Circle and Precursor.
Relay and Falcor are great, but when I look at their docs it'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.
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'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.
Combine this is with first-class REPL and hot reloading support via Figwheel (both frontend and backend) and I'm blown away at how fast I'm going to develop this app.
ClojureScript is shaping up to be a fantastic way to program browser-based applications. This is what I use:
* Reagent -- another ClojureScript React wrapper
* Datascript -- An in-memory database with datalog query lang, this is used as the central store for all application data.
* Posh -- Datascript transaction watcher that updates Reagent components when their queries' return data changes
* 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.
This is one of the nicest front end development experiences I'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/fetching system with a backend database pretty easily.
We ran into the same problems with Om as the CircleCI guys, specifically: 1) our front-end data model wasn'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.
We switched to Reagent, and found that it was far faster and "got out of the way" 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).
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/cursor construct is more of a pain than it's worth...
For something to take off, the community has to step up. I get the concern, though. There's a phase where (if you're an early adopter) it seems like "everyone" is interested, but like, 5 people are experts.
This is huge. I think it might even be the single largest problem to most projects' progress. I'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.
Real, actual tree structures are just incredibly rare. Even some things that "obviously" seem like they should be modeled as a tree are far better off as a directed graph. Like databases of family trees - it'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.
You don't really need 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're using React, i.e. React has its own overhead. As long as the data relationship was right, I've never found it difficult to manage state thereafter. It's when the shoe doesn't fit that things become a problem.
The problem is, we have a systemic problem of treating front-end devs as not "real" developers, not capable of forging their own paths. It'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. "Don't reinvent the wheel!" 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 "reinventing wheels". The problem is this institutional fear of making ones own decisions, leading people to think they need to learn everything.
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't speak for the creator of Om, I speak for myself as the author of this library which was inspired by Om and Clojure)
https://github.com/dustingetz/react-cursor/
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/compose recursively into larger apps. This fiddle is meant to demonstrate this: https://jsfiddle.net/dustingetz/n9kfc17x/
> The tree is really a graph.
Solving this impedance mismatch is the main UI research problem of 2015/2016. Om Next, GraphQL, Falcor etc. It's still a research problem, IMO. The solution will also solve the object/relational impedance mismatch, i think, which is a highly related problem, maybe the same problem.
The solution seems now to get rid of the REST paradigm(GraphQL ...).
While I have no opinion on what should be the right solution, I welcome the idea of questioning the usefulness and the significance of REST, especially in the era of fat web clients.
But I think it's approaching a consensus already within the CLJS community that, on API alone, reagent is the React interface you want.
It's extremely elegant and performant; probably the best frontend library I've ever used in close to a decade of web development.
What I've understood from Relay/Falcore/etc. is those technologies are great for something like Facebook or Netflix, hence why they made the frameworks, but for many other cloud/web apps, it may not make sense. A single atom app state works really well. Is that along the lines of the right thinking? I'm using React+redux along with websockets and haven't had any problems with large state trees, but the whole state can be sent to and from the server very fast as it's not too big.
I'm sure Elm will have something comparable to Om Next/Relay/falcore as well then, to solve those use cases.
The question is, are the majority of apps better suited for a tree-based state or a queryable graph? I'm not sure, but it's at least even.
I've heard Elm is working on something similar, so I wouldn't be surprised if that happens.
That's really not true. The nature of the Elm architecture means it already does this:
> Instead, Om Next asks you to define a set of mutation operations which can change your application’s state.
except it calls that "the `update` function".
The graph problem also seems slightly different, although it is way less convenient than Om Next as it is less declarative and must be bubbled through intermediate "components", Elm "render state" (and render hierarchy) doesn't have to match the application state, it's perfectly possible (and very useful) to duplicate, denormalise and process application state during rendering to match your rendering hierarchy (although it is a very bad idea to denormalise the application state itself).
Elm's trouble is mostly the "remote mismatch".
Are you writing a whole new app? or are you integrating with pre-existing js? Elm is designed around statically-typed functional reactive programming, and as part of maintaining that integrity at runtime, it puts some ceremony around js interop. Clojurescript <-> javascript interop is lower-friction, with all of the potential runtime failures that entails. So it seems that the less your component needs to interact with js, the more pleasant Elm would be, and vice-versa.
What do you and your team already know? In circle ci's case, they already used clojure, so it was an easy choice to stick to that language on the front end. If you or anyone you know don't already have some familiarity with either an ML (in elm's case) or a lisp (in clojurescript's), consider looking into a language like that on the server at the same time.
And of the two, clojurescript is more popular. This entails some confusion, sure (om? om next? reagent? wha? vs the 'just use the stdlib' of elm) but it is generally a Good Thing. In my experience, you're more likely to find answers to cljs questions, to have better tooling ('top speed'), and an easier time setting up that tooling ('acceleration').
You'll notice I compared Elm and Clojurescript, not Elm and Om/Om next. I think the attributes of the two languages probably outweigh any particular differences in app structure between Elm's "StartApp" recommended structure and om.
I'm currently knee deep in a react/redux implementation, which I guess is quite similar.
Basically, you specify a query as a remote query and it calls a `send` function that you specify, and you manually pass the query to the server to execute, which will return results and automatically be merged into the app state (and of course, re-render components that depend on that query).
For the part where they stop making that request, they must do custom lifecycle code so that when the component unmounts, they are able to access current open requests (probably indexed by component manually) and cancel it. That part is not builtin to Om Next.
I doubt any companies (that are themselves, aside from tech stack, appealing to work for) are having trouble at least getting a lot of interest for Clojure positions.
Also, I would avoid optimizing TTFBugFix the wrong way. You want the system to be easy to fix because it's well designed & documented, not because it's written in a language you already know.
Out of curiosity I tried swapping "<ul><li>Artichokes</li><li>Broccoli</li><li>Cabbage</li><li>Dill</li><li>Eggplant</li></ul>"
and the same without the broccoli and dill, back and forth a few thousand times using jquery.
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.
I wonder if using some convoluted framework to "solve—or at least mitigate" this might be premature optimisation? (As well as actually slower).
To be fair, I haven't done actual benchmarks, and I'm basing this on the stated rationale for React. I'd be surprised if swapping out the DOM of most of the page wasn't considerably slower more difficult to work with than what React does, though.
Om.next takes code you writes and makes it go.
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.
- Redux as your single state tree/graph
- Normalizr to denormalize data and store it in a graph, including pulling nested resources out as records
- Reselect to query on your denormalized data
And the best thing is this is production ready, in JS, today.
How does that work if multiple users are collaborating on the same state simultaneously?
The state they're talking about here is local to the client--it's stored in memory on the browser. One one user can use it at a time.
Not saying that Redux isn't easier, though. It's very nice.
It's a common misconception (I fell for this too) that simply having a single atom app state and colocating state accessors with the component is similar to this architecture. It's really not. The query syntax is an extremely important part here, with transparent server syncing, and support for arbitrary graph representations of the state.
Not sure what else to say, actions and queries are completely different things.
When a basically crud website tells me my perfectly fine browser isn't supported I say: FAIL.