by nwjsmith on 1/21/16, 5:25 PM with 65 comments
by dwwoelfel on 1/21/16, 11:02 PM
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.
by jlongster on 1/21/16, 6:43 PM
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.
by mej10 on 1/21/16, 6:53 PM
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.
by pkcsecurity on 1/21/16, 7:11 PM
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...
by darksaints on 1/21/16, 7:12 PM
by moron4hire on 1/21/16, 7:21 PM
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.
by dustingetz on 1/21/16, 6:47 PM
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.
by th0ma5 on 1/21/16, 6:05 PM
by pandeiro on 1/22/16, 1:08 AM
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.
by Cshelton on 1/21/16, 6:33 PM
by cheez on 1/21/16, 6:57 PM
by CuriousSkeptic on 1/21/16, 6:56 PM
I'm currently knee deep in a react/redux implementation, which I guess is quite similar.
by misiti3780 on 1/21/16, 7:43 PM
by tim333 on 1/22/16, 7:47 AM
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).
by amelius on 1/21/16, 9:34 PM
by jdudek on 1/21/16, 9:55 PM
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.
by tonyhb on 1/22/16, 5:05 AM
- 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.
by zubairq on 1/22/16, 6:18 PM
by amelius on 1/21/16, 11:11 PM
How does that work if multiple users are collaborating on the same state simultaneously?
by mwilliamson on 1/21/16, 10:52 PM
by ricardobeat on 1/21/16, 7:34 PM
by faceyspacey on 1/22/16, 12:26 AM
by reitanqild on 1/22/16, 5:37 AM
When a basically crud website tells me my perfectly fine browser isn't supported I say: FAIL.