Why We Use Om, and Why We’re Excited for Om Next • Hacker News Board

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

#21

Post by jraines » Thu, Jan 21, 2016, 7:23 PM UTC

darksaints wrote: post #17

I really like David Nolen as a conceptual visionary. His work with Om and core.logic is great and has inspired a lot of derivative work. But I would never rely on his libraries in production. It seems like he always gets to 90% before moving on to the next new thing. 90% documentation, 90% cljs->js coverage, 90% tested, 90% issues addressed. I wouldn't touch Om unless I was willing to employ at least one person to wo…

Seems like that's as much (or more! esp. with docs) as you can expect from an open source maintainer.

For something to take off, the community has to step up. I get the concern, though. There's a phase where (if you're an early adopter) it seems like "everyone" is interested, but like, 5 people are experts.

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

#22

Post by jlongster » Thu, Jan 21, 2016, 7:25 PM UTC

darksaints wrote: post #17

I really like David Nolen as a conceptual visionary. His work with Om and core.logic is great and has inspired a lot of derivative work. But I would never rely on his libraries in production. It seems like he always gets to 90% before moving on to the next new thing. 90% documentation, 90% cljs->js coverage, 90% tested, 90% issues addressed. I wouldn't touch Om unless I was willing to employ at least one person to wo…

I'd say 90% is pretty good for a single person. Open-source requires a community to work.

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

#23

Post by riwsky » Thu, Jan 21, 2016, 7:28 PM UTC

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?

"It depends".

Are you writing a whole new app? or are you integrating with pre-existing js? Elm is designed around statically-typed functional reactive programming, and as part of maintaining that integrity at runtime, it puts some ceremony around js interop. Clojurescript javascript interop is lower-friction, with all of the potential runtime failures that entails. So it seems that the less your component needs to interact with js, the more pleasant Elm would be, and vice-versa.

What do you and your team already know? In circle ci's case, they already used clojure, so it was an easy choice to stick to that language on the front end. If you or anyone you know don't already have some familiarity with either an ML (in elm's case) or a lisp (in clojurescript's), consider looking into a language like that on the server at the same time.

And of the two, clojurescript is more popular. This entails some confusion, sure (om? om next? reagent? wha? vs the 'just use the stdlib' of elm) but it is generally a Good Thing. In my experience, you're more likely to find answers to cljs questions, to have better tooling ('top speed'), and an easier time setting up that tooling ('acceleration').

You'll notice I compared Elm and Clojurescript, not Elm and Om/Om next. I think the attributes of the two languages probably outweigh any particular differences in app structure between Elm's "StartApp" recommended structure and om.

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

#24

Post by ricardobeat » Thu, Jan 21, 2016, 7:34 PM UTC

The new plan sounds a lot like Redux.

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

#25

Post by saosebastiao » Thu, Jan 21, 2016, 7:35 PM UTC

jlongster wrote: post #22

darksaints wrote: post #17

I really like David Nolen as a conceptual visionary. His work with Om and core.logic is great and has inspired a lot of derivative work. But I would never rely on his libraries in production. It seems like he always gets to 90% before moving on to the next new thing. 90% documentation, 90% cljs->js coverage, 90% tested, 90% issues addressed. I wouldn't touch Om unless I was willing to employ at least one person to wo…

I'd say 90% is pretty good for a single person. Open-source requires a community to work.

It is pretty good, but the community never seems to form. Maybe it is just the lisp NIH culture, maybe it is the way the projects are managed, but either way it doesn't make for production-ready software. You have to be able to support it yourself if you want to use it.

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

#26

Post by jraines » Thu, Jan 21, 2016, 7:42 PM UTC

ricardobeat wrote: post #24

The new plan sounds a lot like Redux.

It's pretty different. It's not flux or flux-like. And almost every Redux example or tutorial does use ES6 or more. As far as the platform, I had an easier time learning ClojureScript and Leiningen than Gulp/Webpack/Babel.

Not saying that Redux isn't easier, though. It's very nice.

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

#27

Post by misiti3780 » Thu, Jan 21, 2016, 7:43 PM UTC

I am surprised their backend is written in closure. I would think it make hiring developers much harder (smaller group of people know it) and training people a lot harder. You can jump on to a project and learn enough go to fix bugs in a day or so (less than a week for sure). I am not sure the same could be said about closure.

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

#28

Post by jlongster » Thu, Jan 21, 2016, 7:51 PM UTC

ricardobeat wrote: post #24

The new plan sounds a lot like Redux.

No, Redux is far more like Om Now. In fact, Om Now was one of the early influencers for the single atom app state idea. The only difference is that, instead of using cursors, Redux uses flux-style actions for mutations. You select data from the app state by digging into the app state manually, exactly like you would in Om Now.

It's a common misconception (I fell for this too) that simply having a single atom app state and colocating state accessors with the component is similar to this architecture. It's really not. The query syntax is an extremely important part here, with transparent server syncing, and support for arbitrary graph representations of the state.

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

#29

Post by [deleted] » Thu, Jan 21, 2016, 7:55 PM UTC

darksaints wrote: post #17

I really like David Nolen as a conceptual visionary. His work with Om and core.logic is great and has inspired a lot of derivative work. But I would never rely on his libraries in production. It seems like he always gets to 90% before moving on to the next new thing. 90% documentation, 90% cljs->js coverage, 90% tested, 90% issues addressed. I wouldn't touch Om unless I was willing to employ at least one person to wo…

[deleted]

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

#30

Post by jraines » Thu, Jan 21, 2016, 7:56 PM UTC

misiti3780 wrote: post #27

I am surprised their backend is written in closure. I would think it make hiring developers much harder (smaller group of people know it) and training people a lot harder. You can jump on to a project and learn enough go to fix bugs in a day or so (less than a week for sure). I am not sure the same could be said about closure.

From the last Clojure/conj (conference), it definitely seems that Clojure is at, or even past, an inflection point.

I doubt any companies (that are themselves, aside from tech stack, appealing to work for) are having trouble at least getting a lot of interest for Clojure positions.