5 ms·

Om Next Quick Start

71 points by ds_ 11y ago

amelius 11y 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)?
- Skinney 11y 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.
  - amelius 11y 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.
    - jraines 11y 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/todomvc/src/cljs/todomvc/parser.cljs#L25 https://github.com/swannodette/om-next-demo/blob/master/todo... Mutating: https://github.com/swannodette/om-next-demo/blob/master/todomvc/src/cljs/todomvc/parser.cljs#L60 https://github.com/swannodette/om-next-demo/blob/master/todo...
    - Skinney 11y 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.
- sotojuan 11y 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.
Gonzih 11y ago
I was hoping that in om next boilerplate will be cleaned up, but seems like it's not really different from original om. No reify is nice though.
hawkice 11y ago
I use Reagent (another Clojurescript React library), and it seems this might widen the gap between the two in terms of ease-of-getting-started. Reagent is dead simple to get going with, and requires you learn basically nothing to build even moderately complicated things. Om is... somewhat notorious for having more complex abstractions built around deep thought about maintaining e.g. a single point of mutable data. This new stuff is... not something I think I could get right the first try. That all being said, David Nolan is clearly a gamer -- Om will be interesting to watch even for people who aren't using it.
- amelius 11y ago
  What I always worry about is not the ease-of-getting-started, but more the ease-of-scaling-modification-and-extending :)
  - moomin 11y ago
    The jury remains out on that one too. Om is a bit marmite. :)
- Skinney 11y ago
  If you use re-frame with reagent (and you should) then the ideas aren't that difficult to grasp. Om.next is more oppinionated regarding where you're allowed to run queries (subscriptions in re-frame) and transactions (handlers in re-frame), and forces you to build a single large query from the root component (wheras re-frame allows you to run several queries from every component).
- jraines 11y ago
  Reagent is very nice and by itself very easy to get started with. That said, I think Om Next is more comparable to Re-frame (https://github.com/Day8/re-frame https://github.com/Day8/re-frame) as far as being more opinionated about handling data flow. In that comparison, I don't think it involves any more complex abstractions or deep thought. In both cases, there is some of that, but both cases are also shining examples of explanatory documentation, which to me were edifying to read because they turn those abstractions into concrete implementations, with examples, and explain the deep thought in a clear manner.
intellectable 11y ago
Works great with React Devtools [0]! [0] https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi?hl=en https://chrome.google.com/webstore/detail/react-developer-to...
swannodette 11y ago
Lots of new stuff in Om Next. Unlike Relay and Falcor we have recovered HTTP caching https://github.com/omcljs/om/wiki/Remote-Synchronization-Tutorial https://github.com/omcljs/om/wiki/Remote-Synchronization-Tut.... And due to the redesign Om Next now has a really fantastically simple automated testing story https://github.com/omcljs/om/wiki/Applying-Property-Based-Testing-to-User-Interfaces https://github.com/omcljs/om/wiki/Applying-Property-Based-Te... Happy to take any questions.
- jarpineh 11y ago
  Could you clarify a bit the state of JS on ClojureScript land? I just spend a weekend watching videos about Om Next and Devcards. I got Om Next inside Devcards working, but the journey from there to getting my JS based React components there was less than smooth. I believe that things like GraphQL, Relay and Redux could provide what I have been missing on my web development story, namely code working with the data regardless of client/server separation. Om Next looks to give these things with a better language. I'm now starting to build things with Om Next, since playing with Cljs on Devcards was really fun. I just had to rage quit a couple times trying to use my existing stuff. I saw support for directly importing JS modules mentioned, but I could not find docs on how it could be used. Other option was to modify build configuration to get my JS files inserted into package space or converting them (I assume) to Clojure packages with CLJSJS. Finally I just mangled several build configs together which somehow worked. I realize trying to keep one feet on JS land and other on Cljs side might not be high in your priorities, but my use case happens to require this. I keep trying, though, so thank you very much for what you've done.
  - Skinney 11y ago
    Importing amd.js/umd/es6 modules would be preferred, but you could also include your .js files using the preamble option.
    - jarpineh 11y ago
      I think I used foreign-libs at the end. I might have had preamble there at one point, but that iteration did not work. Using Figwheel + Devcards build in Leininged seems to swallow compile information, or at least I couldn't see any error messages unless I broke the build very badly...
zubairq 11y ago
As the author of Coils, another Clojure framework (coils.cc) I am really impressed to see Om Next, and I think that Om Next will become the de facto framework for building interactive websites

71 points by ds_ 11y 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)?

Skinney 11y 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.
- amelius 11y 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.
  - jraines 11y 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/todomvc/src/cljs/todomvc/parser.cljs#L25 https://github.com/swannodette/om-next-demo/blob/master/todo... Mutating: https://github.com/swannodette/om-next-demo/blob/master/todomvc/src/cljs/todomvc/parser.cljs#L60 https://github.com/swannodette/om-next-demo/blob/master/todo...
  - Skinney 11y 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.
sotojuan 11y 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.

Gonzih 11y ago

I was hoping that in om next boilerplate will be cleaned up, but seems like it's not really different from original om. No reify is nice though.

hawkice 11y ago

I use Reagent (another Clojurescript React library), and it seems this might widen the gap between the two in terms of ease-of-getting-started. Reagent is dead simple to get going with, and requires you learn basically nothing to build even moderately complicated things. Om is... somewhat notorious for having more complex abstractions built around deep thought about maintaining e.g. a single point of mutable data. This new stuff is... not something I think I could get right the first try. That all being said, David Nolan is clearly a gamer -- Om will be interesting to watch even for people who aren't using it.

amelius 11y ago
What I always worry about is not the ease-of-getting-started, but more the ease-of-scaling-modification-and-extending :)
- moomin 11y ago
  The jury remains out on that one too. Om is a bit marmite. :)
Skinney 11y ago
If you use re-frame with reagent (and you should) then the ideas aren't that difficult to grasp. Om.next is more oppinionated regarding where you're allowed to run queries (subscriptions in re-frame) and transactions (handlers in re-frame), and forces you to build a single large query from the root component (wheras re-frame allows you to run several queries from every component).
jraines 11y ago
Reagent is very nice and by itself very easy to get started with. That said, I think Om Next is more comparable to Re-frame (https://github.com/Day8/re-frame https://github.com/Day8/re-frame) as far as being more opinionated about handling data flow. In that comparison, I don't think it involves any more complex abstractions or deep thought. In both cases, there is some of that, but both cases are also shining examples of explanatory documentation, which to me were edifying to read because they turn those abstractions into concrete implementations, with examples, and explain the deep thought in a clear manner.

intellectable 11y ago

Works great with React Devtools [0]! [0] https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi?hl=en https://chrome.google.com/webstore/detail/react-developer-to...

swannodette 11y ago

Lots of new stuff in Om Next. Unlike Relay and Falcor we have recovered HTTP caching https://github.com/omcljs/om/wiki/Remote-Synchronization-Tutorial https://github.com/omcljs/om/wiki/Remote-Synchronization-Tut.... And due to the redesign Om Next now has a really fantastically simple automated testing story https://github.com/omcljs/om/wiki/Applying-Property-Based-Testing-to-User-Interfaces https://github.com/omcljs/om/wiki/Applying-Property-Based-Te... Happy to take any questions.

jarpineh 11y ago
Could you clarify a bit the state of JS on ClojureScript land? I just spend a weekend watching videos about Om Next and Devcards. I got Om Next inside Devcards working, but the journey from there to getting my JS based React components there was less than smooth. I believe that things like GraphQL, Relay and Redux could provide what I have been missing on my web development story, namely code working with the data regardless of client/server separation. Om Next looks to give these things with a better language. I'm now starting to build things with Om Next, since playing with Cljs on Devcards was really fun. I just had to rage quit a couple times trying to use my existing stuff. I saw support for directly importing JS modules mentioned, but I could not find docs on how it could be used. Other option was to modify build configuration to get my JS files inserted into package space or converting them (I assume) to Clojure packages with CLJSJS. Finally I just mangled several build configs together which somehow worked. I realize trying to keep one feet on JS land and other on Cljs side might not be high in your priorities, but my use case happens to require this. I keep trying, though, so thank you very much for what you've done.
- Skinney 11y ago
  Importing amd.js/umd/es6 modules would be preferred, but you could also include your .js files using the preamble option.
  - jarpineh 11y ago
    I think I used foreign-libs at the end. I might have had preamble there at one point, but that iteration did not work. Using Figwheel + Devcards build in Leininged seems to swallow compile information, or at least I couldn't see any error messages unless I broke the build very badly...

zubairq 11y ago

As the author of Coils, another Clojure framework (coils.cc) I am really impressed to see Om Next, and I think that Om Next will become the de facto framework for building interactive websites