Comment by lkrubner | Hacker News Reader

Comment by lkrubner | Hacker News Reader

About this:

"In many ways ClojureScript has and continues to be ahead of the JavaScript mainstream with respect to best practices. Concepts which are only starting to break into the mainstream such as immutability, single atom application state, and agile UI development via robust hot-code reloading are old news to ClojureScript users. "

To my mind, the most compelling thing about Javascript-in-Clojure is working with Om Next. I say this as someone who has recently done some big projects with React.

I think it would be accurate to say that over the last 2 years React has been the Javascript framework that had the biggest impact on how people think about working with Javascript. You look at how much Angular tried to reinvent itself to be a bit more like React.

There are a lot of interesting ideas in React, and I learned a lot while working with it, yet I hate working with it. It is ridiculously verbose. And I hate the way it handles mutations -- it's as if React was trying to be Functional, but then decided to go back and be Object Oriented when it came to mutations.

But I don't mean to go off on a tangent. There are a lot of good ideas in React. Especially GraphQL, which arose as part of the React effort, but which I think will have a long life quite independent of React. React might some day fade away and be forgotten, but GraphQL's critique of the RESTful style is likely to change the way the industry thinks about APIs over the net.

But as I said, React is verbose. I like where Om Next is going -- in terms of immutability and data flow, it has the same basic outlook as React, but Om Next is simpler and it is truer to the Functional paradigm.

If I do any further work with ClojureScript, it will be because of Om Next.

https://github.com/omcljs/om/wiki/Quick-Start-(om.next)

I found almost everything about Om almost egregiously, shamelessly complex. I absolute _love_ the core philosophy, and I think it's a valuable technical effort. But even Om Next is not the big refactoring towards user friendliness that I was hoping for.

It's likely that I'm just too dumb for modern web programming, but I am waiting for someone to distill the (admittedly brilliant) ideas behind Om into something just as powerful but more usable. Reagent is elegant and simple, but you can see how it falls down in the face of larger apps, re-frame I just find a mess. I'm excited about all of this, but I don't think we're really there yet.

Very well put. I think this is an extremely insightful summary of the state of ClojureScript for the web today. I feel I'm still waiting for another leap forward.

What about re-frame is "a mess"? Pretty tiny API surface, solely aimed at forcing the best practices of unidirectional data flow / single source of truth. Have you ever looked at what the same thing entails in JavaScript, ie Redux?

I'd be happy to concede that my real-life experience of re-frame isn't representative, if someone were to show me an example of best practise. My main worry working on real apps has been that it's very hard to layer subscribe/dispatch in a way that allows for modular components, while at the same time separating out component instance state and app state.

Beyond that, the new reg-effect-fx system isn't particularly mature, individual fx aren't extensible, e.g. being able to extend http-fx to cancel or debounce requests.

I don't _hate_ it, I'm building apps in it. I just think there's a lot of overhead above Reagent that I have yet to see pay off, and the idea that it _forces_ best practises is wrong. It's like an MVC system that lets you put (_encourages_ you to, if you read the docs) controller code anywhere.

Knowing where to use `subscribe` (vs pure components) is an art and something that gets easier/clearer as you understand the app better. I'm happy to take responsibility for that aspect of the architecture though; the library's role is to provide the operations and patterns I might want. And if further generalizable patterns evolve, those can be turned into a higher level library.

Have you looked at the Untangled framework? It seems to be exactly what you're looking for. https://untangled-web.github.io/untangled/

we're using untangled framework in production, I can't say enough good things about it.

Ta, I'd seen the name, but not looked at it in depth.

Check out Rum: https://github.com/tonsky/rum

Om.next shows it's strength when you're working on a complex application 5k+ lines of code. A core abstractions of om.next (and graphQL) is to express data dependencies of your react classes in a query language (e.g. component X depends on data title, author, created, updated), then the logic around how to fetch data, refresh data, cache data or access cached data, update data, deduplicate data when it's needed in many places, optimistically update client-side data and wait for server-side data to synchronize is all disentangled from the logic on rendering complete data, missing data, data being loaded, reacting to user events, etc. In a smaller code base expressing these data dependencies would just seem tedious (writing graphQL or query expressions), but it pays up big time in larger applications.

I absolutely agree that larger apps are complicated, and that Om has thoughtful solutions to those problems, at the right level of abstraction. But I found it an absolute _pain_ to get going, and at every step it presented me with so many different primitives I felt lost.

If I had to compare it to any other tool, it'd be git. I love git. I use git every day. Do I understand the underlying mental model of git, or the 348 different git commands? Hell no.

I'd have to agree. Reagent was able to expose the beauty of the concept to me more clearly than Om. When I approached Om, I found it to be on a completely different level with regards to things to understand and absorb.

Having said that, I'm also pretty sure that Om yields bigger payoffs further down the road as far as I can tell.

Yes, I think those are all valid points/weaknesses. While I don't personal struggle with understanding the internals of git or om.next the learning curve is no joke. The community is aware of this, but it's still alpha software they're working on it. I actually think of om.next more like a library than a web framework. As a library it has many degrees of freedom in how it can be composed and i imagine the author prioritized flexibility/generality over concreteness, and a lot of work is still left up to the user in filling in the blanks of a full fledge web app, untangled (https://untangled-web.github.io/untangled/) is one project tries to fill in all the missing gaps and expose a framework API, much better documentation, more concrete than om.next.

Thanks for the kind words but I do think ClojureScript is much, much bigger than Om Next :) People are succeeding with many different approaches - Reagent, Rum, Hoplon, etc. all have enthusiastic, active user bases and for good reason. While I'm happy too see Om Next gain traction, in the end I'm much more excited to hear about someone adopting ClojureScript regardless of what other technology choices they might make.

Reply on news.ycombinator.com