Om or quiescent ?

[Dein Diener]

Hi, i am new to clojurescript and want to build a small webapp with it to learn. I took a detailed look at the todo sample-app of 1. om and 2. quiescent and found the second one (quiescent) easier to understand... so i would like to go with quiescent. But aware of the fact, that Om is much "bigger"... my question is: what does Om have that quiescent misses ? Thanks ;)

[Mike Thompson]

On Friday, November 28, 2014 6:42:47 AM UTC+11, Dein Diener wrote:
> Hi, i am new to clojurescript and want to build a small webapp with it to learn. I took a detailed look at the todo sample-app of 1. om and 2. quiescent and found the second one (quiescent) easier to understand... so i would like to go with quiescent. But aware of the fact, that Om is much "bigger"... my question is: what does Om have that quiescent misses ? Thanks ;)

For what it is worth, I went through the same process at the start of this year, and ended up choosing Reagent. At this point, I believe I choose well. I've found it a delight to use.

Here's the library: https://github.com/reagent-project/reagent
Here's the overall project: https://github.com/reagent-project


--
Mike

[Dein Diener]

*haha* I dont know why, but i like this kind of answer... ;)) It amuses me and makes me confident somehow. Thank you so much.

[Walter van der Laan]

On Thursday, November 27, 2014 8:42:47 PM UTC+1, Dein Diener wrote:
> Hi, i am new to clojurescript and want to build a small webapp with it to learn. I took a detailed look at the todo sample-app of 1. om and 2. quiescent and found the second one (quiescent) easier to understand... so i would like to go with quiescent. But aware of the fact, that Om is much "bigger"... my question is: what does Om have that quiescent misses ? Thanks ;)

Om has stateful components, just like Reagent and React itself. Quiescent only uses the React virtual DOM. Quiescent does not store state in React components. All UI-state is stored outside React using e.g. Clojurescript atoms. This is why Quiescent is easier to understand. AFAICT there is nothing that Om can do which Quiescent misses.

[Ahmad Hammad]

On Thursday, November 27, 2014 7:42:47 PM UTC, Dein Diener wrote:
> Hi, i am new to clojurescript and want to build a small webapp with it to learn. I took a detailed look at the todo sample-app of 1. om and 2. quiescent and found the second one (quiescent) easier to understand... so i would like to go with quiescent. But aware of the fact, that Om is much "bigger"... my question is: what does Om have that quiescent misses ? Thanks ;)

Om certainly has a learning curve and can be frustrating at times however I believe it is designed to achieve two things:

1) help you build decoupled and reusable components. You can certainly do this with the other libraries but then it is entirely up to you to architect your app & components such a way, so in that sense, it simplifies things for you in the long run.

2) make the most of persistent data structures to give you performance out of the box.

[jack james]

The quiescent readme provides a lot of specific information about the comparison:

https://github.com/levand/quiescent#comparison-with-om

FWIW, I'd encourage you to make the investment and learn Om. It doesn't take long before the stuff that you're not understanding at first glance seems trivial.

[Sean Corfield]

On Nov 28, 2014, at 7:53 AM, jack james <jack.jack...@gmail.com> wrote:
> FWIW, I'd encourage you to make the investment and learn Om. It doesn't take long before the stuff that you're not understanding at first glance seems trivial.

Even as someone who ultimately switched to Reagent, I totally agree with this: learning Om is a worthwhile investigate because you will get to understand a lot more about React and how to use it effectively if you start with Om.

At World Singles, we started with Om and once our app got to about 1,000 lines, we switched to Reagent (which shrank the code base quite a bit). Our grounding in Om really helped us in designing Reagent "components" that could be reused more easily.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[nuryoku san]

If you want to get adventurous... take a step further back and take a look at FRP and Elm. The examples show incredible terse and readable(?) code. Elm might be a light ahead that shines for clojure ui-programming too, but ... as always nothing really good comes for free.

[Colin Yates]

I think om is much more opinionated about how things should be done where as queiscent is a more narrowly focused API around react.

You will find a whole bunch of people that start with om, run into some stylistic issue (incidental complexity around the API seems common) and move onto reagent, usually claiming a much more positive experience.

I don't know much about queiscent other than it doesn't seem as popular as om or reagent, but that is subjective.

For me personally, I started with om about a month ago now and have about 2K sloc in om (wc -l). I expect a good percentage of that could be shaved off if I went with reagent.

The reason I am sticking with om though? At the moment I like the level of opinion it has and I really like the "world in an atom view" coupled with cursors, and Prismatic's om-tools make mixins trivial. I was at the bottom of the clojurescript, react, om, core.async etc. learning curve so the more "safe pair of opinionated hands" I could get the better.

It definitely takes a bit of getting used to, and you do have to jump through some hoops (composing components for example), but like others have said, if you don't know react then om is a helpful right of passage :).

To be honest, looking at om and reagent, you can't go wrong - they are both great tools. I have no idea about quiescent.

Google this group for "om reagent" for a bunch of really good articles if you are interested in following the "well trodden path" (https://groups.google.com/d/msg/clojurescript/NlaYPfQBW2I/oiFkVLZYafMJ is probably the starting point).

[Nikita Dudnik]

On Friday, November 28, 2014 9:43:16 PM UTC+3, nuryoku san wrote:
> If you want to get adventurous... take a step further back and take a look at FRP and Elm. The examples show incredible terse and readable(?) code. Elm might be a light ahead that shines for clojure ui-programming too, but ... as always nothing really good comes for free.

I don't think FRP and virtual-dom based frameworks are mutually exclusive approaches to building front-ends. React (or any stand-alone implementation of a virtual-dom) is perfectly combinable with FRP. Just keep your app's state in one place, update it using your FR logic, use v-dom to rerender everything when state changes.
I consider this combination a much better approach for a system with a lot of asynchronous client-side logic.

But talking about ClojureScript there is no need for FRP because core.async is much easier to learn and reason about.

[Chris Oakman]

We have had success at work using Quiescent with Sablono. The mental model of "all state is captured in one place; there is no transient component state" is easy to understand.

We have another team member who has been successful with Om + Sablono.

I think the differences between Om, Reagent, and Quiescent aren't as important as the UI paradigm that React.js supports. That ClojureScript's immutable data structures works well with the React.js model is a side effect of the simplicity of both technologies.

[James MacAulay]

On Saturday, 29 November 2014 08:44:42 UTC-5, Nikita Dudnik wrote:
> I don't think FRP and virtual-dom based frameworks are mutually exclusive approaches to building front-ends. React (or any stand-alone implementation of a virtual-dom) is perfectly combinable with FRP. Just keep your app's state in one place, update it using your FR logic, use v-dom to rerender everything when state changes.

I've been building a port of Elm's FRP system to Clojure/ClojureScript, and this is the approach I've been taking so far:

https://github.com/jamesmacaulay/zelkova/blob/d683225ff26c4af13d5d94d801b6dfc48b801bb8/examples/drag-and-drop/src/drag_and_drop/core.cljs#L102-L169

I think there's a lot of potential with approaches like this.

> But talking about ClojureScript there is no need for FRP because core.async is much easier to learn and reason about.

I think it's probably true that core.async is easier to learn at first, for most people. But once you're comfortable with both of them, I think FRP systems *can be* a lot easier to reason about. I consider core.async to be a good low-level system for co-ordinating events, but everything you do with it requires poking channels with "the mutating stick," with all the complexity that entails.

FRP has its own conceptual hurdles, but I find the fact that FRP signal values are immutable is a huge win (immutable in the sense that composing signals together doesn't change how they behave). That being said, FRP is much newer territory than CSP, so if you're building applications with it top-to-bottom then you're likely to run into a number of problems whose solutions are still open research topics :P

[James MacAulay]

On Saturday, 29 November 2014 23:42:52 UTC-5, James MacAulay wrote:
> I've been building a port of Elm's FRP system to Clojure/ClojureScript, and this is the approach I've been taking so far:
>

Sorry, if it wasn't clear: I was referring specifically to what you were talking about with hooking up an FRP signal graph to the app state.

[Nikita Dudnik]

No worries, it was clear enough. I appreciate the info on CSP drawbacks ‘cause I have more experience with FRP (client-side JS, bacon.js implementation). I’ll take a closer look at your project. Seems both relevant and interesting. 

—

Nikita Dudnik

http://nikdudnik.com

--

Note that posts from new members are moderated - please be patient with your first post.

---

You received this message because you are subscribed to a topic in the Google Groups "ClojureScript" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/XGtuD0CdC5c/unsubscribe.

To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com.

To post to this group, send email to clojur...@googlegroups.com.

Visit this group at http://groups.google.com/group/clojurescript.

[whodidthis]

Here's another elm library https://github.com/ericnormand/elm-frp

Hopefully i'll get to use one of these with om soon, could make reasoning with multiple inputs quite nice.

[Nikita Dudnik]

Here's another elm library https://github.com/ericnormand/elm-frp

I’ve seen it but I’m pretty sure it’s just a proof of concept for Eric Normand’s blog post:

http://www.lispcast.com/elm-frp-clojure-core-async

Hopefully i'll get to use one of these with om soon, could make reasoning with multiple inputs quite nice.

At the moment I’m experimenting with combination of bacon.js, immutable.js and virtual-dom libraries (yep, pure browser JS environment) and starting to feel like both Om and React do too much. 

[Colin Yates]

Hi Nikita,

This isn't a challenge, but a question of clarity. By "too much" do you mean:
- solving "problems" which are aren't problems (e.g. enforcing an opinion)
- solving problems which do need to be solved but in the wrong way
- conflating the solution to too many problems
- something else entirely

Are you suggesting they are fundamentally flawed (it doesn't sound
like it) or could be improved if only they did X...?

[Nikita Dudnik]

This isn't a challenge, but a question of clarity.

Can’t argue with that.

By "too much" do you mean:

- solving "problems" which are aren't problems (e.g. enforcing an opinion)

- solving problems which do need to be solved but in the wrong way

- conflating the solution to too many problems

- something else entirely

Nothing fundamentally wrong about Om. 

It’s more about it enforcing an opinion and conflating the solution.

Om gives you a protocol for component’s implementation.

Om controls application state.

Om components have local state.

These choices complicate smaller projects.

There is a good alternative if all you need is rendering immutable values to HTML:

https://github.com/levand/quiescent

It’s rationale is highly relevant to our discussion.

[Nikita Dudnik]

Sorry, I was too deep in a thread. :) We are already discussing Om vs. Quiescent.

—

Nikita Dudnik

http://nikdudnik.com

[David Nolen]

On Mon, Dec 1, 2014 at 9:45 AM, Nikita Dudnik <nikd...@gmail.com> wrote:
> Nothing fundamentally wrong about Om.
> It’s more about it enforcing an opinion and conflating the solution.

Om doesn't actually enforce anything, it does provide defaults because
eventually you bottom out at "taste".

> Om gives you a protocol for component’s implementation.

Yes.

> Om controls application state.

No, there are protocols and it provides a default implementation.

> Om components have local state.

Again no, it provides protocols and provides a default implementation.

> There is a good alternative if all you need is rendering immutable values to
> HTML:
> https://github.com/levand/quiescent
>
> It’s rationale is highly relevant to our discussion.

I work with Luke and I'm a big fan of Quiescent's minimal approach.
But this is not what I consider a good rationale. A good rationale
focuses on *problems*.

As of yet no one in this thread has pointed out that React based
solutions actually introduce new *problems*. The Flux architecture is
a solution to some of these problems. Om provides a different set of
solutions than Flux.

Quiescent simply throws its hand up about the large set of fundamental
issues you encounter when architecting larger React programs.

It is absolutely inevitable that React based programs will encounter
the problems that Flux & Om attempt to address. You can either adopt a
well maintained solution or forge your own path but there no getting
around the issues.

David

[Nikita Dudnik]

Om doesn't actually enforce anything, it does provide defaults because

eventually you bottom out at "taste".

I absolutely haven’t hit the bottom yet and I really appreciate you sharing your experience.

I work with Luke and I'm a big fan of Quiescent's minimal approach.

But this is not what I consider a good rationale. A good rationale

focuses on *problems*.

As of yet no one in this thread has pointed out that React based

solutions actually introduce new *problems*. The Flux architecture is

a solution to some of these problems. Om provides a different set of

solutions than Flux.

Quiescent simply throws its hand up about the large set of fundamental

issues you encounter when architecting larger React programs.

Can you elaborate on those problems, please? 

It is absolutely inevitable that React based programs will encounter

the problems that Flux & Om attempt to address. You can either adopt a

well maintained solution or forge your own path but there no getting

around the issues.

Do you see Om as universal solution?

Are there any benefits using FRP + Quiescent at least for some particular kinds of projects?

 

—

Nikita

[David Nolen]

On Mon, Dec 1, 2014 at 6:03 PM, Nikita Dudnik <nikd...@gmail.com> wrote:
> Can you elaborate on those problems, please?

I could but I think it's better for people to come to their own
conclusions about the fundamental issues inherent in React-like
systems that Flux tries to overcome. Only when you can see this can
you even been to start having meaningful discussions about React and
its derivatives.

David

[Nikita Dudnik]

I could but I think it's better for people to come to their own

conclusions about the fundamental issues inherent in React-like

systems that Flux tries to overcome. Only when you can see this can

you even been to start having meaningful discussions about React and

its derivatives.

Ок :)

—

Nikita 

[Mike Thompson]

I would claim that Reagent is FRP via its use of the ratom. Once you understand how it works the penny drops. Reagent effectively has its own version of "lift" (look for "reaction" and "run!" which are not promoted by the standard docs).

As a result, I would claim that Reagent has more in common with Elm and Hoplon/javelin, than OM.

--
Mike

[Nikita Dudnik]

> I would claim that Reagent is FRP via its use of the ratom. Once you understand how it works the penny drops. Reagent effectively has its own version of "lift" (look for "reaction" and "run!" which are not promoted by the standard docs).
>
> As a result, I would claim that Reagent has more in common with Elm and Hoplon/javelin, than OM.

Sounds interesting! I'll take a more thorough look at it.

---
Nikita

[p...@banphim.net]

In my case Om wins over Quiescent more often (because of its short name - just kidding ;) until Datascript enters the game. Anyway, it's still all about the problem.