Hacker News new | ask | show | jobs
by amelius 3887 days ago
What about performance? How many data queries can it handle per component, realistically? How many connections can it handle? I.e., where will this solution break down?

Are the transactions (issued from within the browser) performed optimistically? If so, will this not give "flicker" in the browser in case a transaction needs to be rolled back? Is it also possible to easily perform a transaction from the server (i.e., not optimistically)?
2 comments
Skinney 3887 days ago
Don't understand the question. Om.Next allows you to have a single root component, that component is responsible for building a query for every sub-component. So you really only have a single query, then render based on the results of that query. Whenever data that is touched by the query changes, affected components are re-rendered. I would also assume that the time it takes to render the view is much greater than the time it takes to run a query, although that depends on your app/query.
link
amelius 3887 days ago
Ok, perhaps I should rephrase the question. Let's assume there are X items in your component (say a simple list box), and there are Y users, each editing one or more items in that same component. At what values of X and Y will Om break down?

Why I ask this is that before I get hooked on Om, I want to be sure that I'm not in a dead-end alley :) I want my application to be able to scale as necessary.

link
jraines 3887 days ago
Hard to answer that with concrete numbers but Om Next handles optimistic and non-optimistic updates quite elegantly. Roughly speaking: each query expression is parsed twice, once locally and once in remote mode, and as long as your backend can handle Om Next query expressions, it Just Works:

Reading: https://github.com/swannodette/om-next-demo/blob/master/todo...

Mutating: https://github.com/swannodette/om-next-demo/blob/master/todo...

link
Skinney 3887 days ago
Depends entirely on your queries/mutations and app requirements. Om does produce regular React components, and due to immutable by default collections and data, Om can even beat React when it comes to rendering performance. At the very least, you should expect React-like performance. Then again, I've written a couple of frontend applications, and React/Reagent/Om has never been a problem for me from a performance standpoint. If it was, ClojureScript makes it easy to write code that uses regular js-objects and arrays, so it's always possible to optimize with "low-level" code when necessary. Like I said though, it has never been necessary.
link
sotojuan 3887 days ago
> Are the transactions (issued from within the browser) performed optimistically? If so, will this not give "flicker" in the browser in case a transaction needs to be rolled back? Is it also possible to easily perform a transaction from the server (i.e., not optimistically)?

I was at the Lisp NYC talk where David talked about Om Next. He specifically spent some time talking about this and demonstrated how to perform optimistic updates that do not flicker.

I can't really say anything else (the talk was great, but way above my head at this point), but it seems to be able to do that.

link