Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.circleci.com

Post reply on HN
Print view View original

61–70 of 74 posts

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

#61

Post by tim333 »

>2 We could throw out the entire list and rebuild it in one go, but re-rendering large amounts of DOM is also slow.

Out of curiosity I tried swapping "ArtichokesBroccoliCabbageDillEggplant"

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).

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

#62

Post by sbensu »

Touche wrote: post #39
robto wrote: post #37

Earlier quoted context omitted.

I don't have experience with Om, but another comparable React wrapper in the Clojurescript world is Re-Frame, and it has a top-notch community. The original developers are still active, but there are many new contributors who are adding substantial new features and polish.

It's David Nolen and the way he runs his projects, making people sign Contributor Agreements and such. He wants to remain the BDFL which is fine, his project, but the downside is that people are less enthusiastic to contribute.

As a contributor to some of David's projects, I gotta say, he does a great job of helping you contribute. He walked me through every issue I had until I could make a meaningful contribution. The one thing which makes it hard to contribute, is that he expects very high quality code, which requires time. I think it is a good tradeoff.

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

#63

Post by sbensu »

mwilliamson wrote: post #45

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

Yes, a few. Look for David's talk on Om Next he usually lists were he departed from GraphQL/Relay and Falcor. A big one is that both GraphQL and Falcor are string based, while Om Next uses data structures which are easier to programmatically manipulate and compose.

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

#64

Post by ds_ »

dustingetz wrote: post #15
aikah wrote: post #14

Earlier quoted context omitted.

> Solving this impedance mismatch 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.

My opinion is that REST is exposing the O/R impedance mismatch to the client, and we are only feeling this now as our client apps get really complicated, and i think the O/R imnpedance mismatch is caused by pervasive mutability, and i think the problem can be solved by making the database immutable (e.g. CQRS/ES, Datomic), and i think that will make the problems with REST go away too. (This is not quite what GraphQL…

"Om Next is meant to be paired with Datomic" - although datomic makes some things easier, Om Next has no opinion on what backend you use.

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

#65

Post by slorber »

jlongster wrote: post #13
Cshelton wrote: post #11

Earlier quoted context omitted.

Ok I see now. I think both methods have a place going into the future. 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…

I don't think it's that's simple. It's not that it works better for hugely complex apps. It just works better for certain kinds of apps, even if they are small. The project I'm working on is small, but Om Next is far better suited to it (the complexity of using Redux+Redux/etc on it would be far greater). The question is, are the majority of apps better suited for a tree-based state or a queryable graph? I'm not sure…

Is the same data displayed into multiple branches of the tree? :)

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

#66

Post by masklinn »

jlongster wrote: post #6
Cshelton wrote: post #3

So I've been looking at Elm recently, what would the advantages/disadvantages for something like Elm over Om/Om Next?

Elm's HTML engine conceptually the same as React+Redux and Om Now. It's just a big single atom app state with ways to describe how to update it. It has all the same problems as Om Now (maybe not quite as bad because it doesn't have cursors, but it doesn't solve the data-as-a-graph problem).

> Elm's HTML engine conceptually the same as React+Redux and Om Now. It's just a big single atom app state with ways to describe how to update it. It has all the same problems as Om Now (maybe not quite as bad because it doesn't have cursors, but it doesn't solve the data-as-a-graph problem).

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".

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

#67

Post by [deleted] »

pandeiro wrote: post #56
dustingetz wrote: post #46

Earlier quoted context omitted.

Did you know that David wrote all of ClojureScript? https://github.com/clojure/clojurescript/graphs/contributors

Umm, taking nothing away from his incredible stewardship and everything, but that's not true. I believe Rich Hickey et al did the first implementation. Not to mention that contributors have added hundreds of commits.

[deleted]

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

#68

Post by jlongster »

slorber wrote: post #65
jlongster wrote: post #13

Earlier quoted context omitted.

I don't think it's that's simple. It's not that it works better for hugely complex apps. It just works better for certain kinds of apps, even if they are small. The project I'm working on is small, but Om Next is far better suited to it (the complexity of using Redux+Redux/etc on it would be far greater). The question is, are the majority of apps better suited for a tree-based state or a queryable graph? I'm not sure…

Is the same data displayed into multiple branches of the tree? :)

You mean the component tree? Sure, it can mixed in whatever way the component tree wants it.

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

#69

Post by peeja »

tim333 wrote: post #61

>2 We could throw out the entire list and rebuild it in one go, but re-rendering large amounts of DOM is also slow. Out of curiosity I tried swapping " Artichokes Broccoli Cabbage Dill Eggplant " 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 fr…

Author here. I actually glossed over some of the problems here, as the article was already getting quite long. In a trivial example like this, you're right. If you do this to the entire page, though, it gets stickier. An additional problem is that you're throwing away and rebuilding state that's associated with the elements, such as event handlers. (Also, letting React do the actual DOM manipulation makes it easier to implement transitions, where a Virtual DOM element goes away now, but the real DOM element sticks around for a bit while it animates off.)

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.

Post reply on HN