4 ms·

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 star

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) https://github.com/omcljs/om/wiki/Quick-Start-(om.next)

thom 10y ago
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.
- malcolmjuxt 10y ago
  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.
- pandeiro 10y ago
  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?
  - thom 10y ago
    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.
    - pandeiro 10y ago
      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.
- cutler 10y ago
  Have you looked at the Untangled framework? It seems to be exactly what you're looking for. https://untangled-web.github.io/untangled/ https://untangled-web.github.io/untangled/
swannodette 10y ago
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.

thom 10y ago

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.

malcolmjuxt 10y ago
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.
pandeiro 10y ago
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?
- thom 10y ago
  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.
  - pandeiro 10y ago
    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.
cutler 10y ago
Have you looked at the Untangled framework? It seems to be exactly what you're looking for. https://untangled-web.github.io/untangled/ https://untangled-web.github.io/untangled/

swannodette 10y ago

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.