
Om Next Quick Start - ds_
https://github.com/omcljs/om/wiki/Quick-Start-%28om.next%29
======
swannodette
Lots of new stuff in Om Next. Unlike Relay and Falcor we have recovered HTTP
caching [https://github.com/omcljs/om/wiki/Remote-Synchronization-
Tut...](https://github.com/omcljs/om/wiki/Remote-Synchronization-Tutorial).
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-Te...](https://github.com/omcljs/om/wiki/Applying-Property-Based-
Testing-to-User-Interfaces)

Happy to take any questions.

~~~
jarpineh
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.

~~~
swannodette
Using the most popular JavaScript libraries is absolutely not a problem.
However integrating random React components in a ClojureScript build is a work
in progress (you could also just pre-build your React bits first and avoid
this issue entirely). Maria Geller and others in the community have pushed the
CommonJS integration forward an incredible distance, we're at the point now
where the devil is in the details. I suspect in 6 months or so using a random
React component in the ClojureScript build process will not be so challenging.

~~~
jarpineh
Ok, thank you.

I have to see how to go about making JS with Webpack -> Cljs a bit more
automated.

------
hawkice
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
What I always worry about is not the ease-of-getting-started, but more the
ease-of-scaling-modification-and-extending :)

~~~
moomin
The jury remains out on that one too. Om is a bit marmite. :)

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

------
intellectable
Works great with React Devtools [0]!

[0] [https://chrome.google.com/webstore/detail/react-developer-
to...](https://chrome.google.com/webstore/detail/react-developer-
tools/fmkadmapgofadopljbjfkapdkoienihi?hl=en)

------
zubairq
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

------
amelius
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
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
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
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...](https://github.com/swannodette/om-next-
demo/blob/master/todomvc/src/cljs/todomvc/parser.cljs#L25)

Mutating: [https://github.com/swannodette/om-next-
demo/blob/master/todo...](https://github.com/swannodette/om-next-
demo/blob/master/todomvc/src/cljs/todomvc/parser.cljs#L60)

