4 ms·

I would love to try out all these cool alternatives to pure JS plus Vue or React, but at what point is this a good idea for a commercial production application?

invalidOrTaken 6y ago
At this point I think it's safe to say---clojurescript has proven itself and is not a risk. An excellent language, good libraries (Metosin's ambidextrous router, Reitit, stands out here), the best development story with Figwheel, and oh, dead code elimination for free, as the cljs compiler leverages Google's Closure (not to be mistaken for Clojure) compiler. Not to mention that cljs is actually a better fit for React even than JavaScript---implicit return, bias towards functional programming, and it requires no magic JSX step---in cljs you just write your html in nested data literals. It's a dream. I haven't even mentioned black magic like core.async, or that now your front-end devs have a foothold on the JVM rather than the more-impoverished Node ecosystem(oh, you want to keep Node? Well, cljs runs there too!). Pitch is a well-funded German startup making a presentation tool in the browser---as in, they can't afford to get their front end wrong---and they're comfortably using cljs. Frankly at this point I think anyone serious about the frontend, who wants it to be good, not just passable, should be using clojurescript. There are reasons not to---if you need something today, and don't have time to learn a lisp---but for anything not due next week, I'd recommend cljs.
- yakshaving_jgt 6y ago
  Conversely, I found the experience pretty terrible when I worked on a big cljs/reagent/reframe/figwheel app over the course of a couple of years. It was slow, prone to runtime errors (though not as much as JavaScript), and often presented weird edge-cases at the intersection between the Lisp world and the React world. The company ended up abandoning all this stuff after having been big Clojure/ClojureScript evangelists for a long time. On the other hand, after having built several large Elm applications, Elm is still the tool I'd recommend. On my current ~10KLOC Elm project, compilation is near enough instant, the structure of the code is more rigid so it's far easier to understand — even for beginners — and there's far less potential for runtime errors to occur. Of course, this is the classic religious war in programming, so I expect someone to appear soon and point out that there is no empirical evidence to support the idea that a type system like the one in Elm or Haskell results in fewer errors in practice. Or perhaps they'll say jet fuel can't melt steel beams.
  - MikeOfAu 6y ago
    Hmm. This is likely to devolve into a static vs dynamic typing borefest. There is no right here: it is just different brain wiring (preferences), backed by motivated reasoning on both sides. But to address the three points you raise... I'm surprised to hear that there was a problem at the Reagent/React boundary. We find that works sooooo well. I genuinely love Elm's claims around 0 runtime errors. It gets my nerdy juices flowing. But then I remind myself that this is simply not a problem I have. We might get one every blue moon (in production) and then it is fixed and deployed about 10 mins later. I have many technical challenges (eg. Kubernetes etc), but runtime problems is not in my top 20. As to slowness, I can't comment without knowing more. We don't have that problem but that doesn't mean it might not exist in some domains. Then again, it could be bad design decisions. Dunno. One thing for sure, I'd choose Elm over javascript any day, but ClojureScript is just working too well for us right now.
  - invalidOrTaken 6y ago
    I'm glad you commented, because the GP comment originally had at the end something like, "With one caveat---I still haven't given Elm a fair shake." Then I thought, "Nah, too esoteric for HN, I don't want to dilute things" and erased it. Joke is on me! I do hope to be able to make the time to play with Elm at some point---at one point I was very excited about FRP, and what took me away was time, not some fundamental, principled thing.
auganov 6y ago
Two main considerations: Does the bundle size matter? CLJS bundles are not terribly huge but if you need a very lightweight bundle you're out of luck. Vs plain JS there is just no comparison. Vs plain JS + just a few libraries CLJS will probably do worse too. But for anything bigger it starts to catch up. Say I'd never use CLJS for a landing page, but for most kinds of apps there shouldn't be a problem. How do you plan to interact with the wider JS ecosystem? One problem with CLJS is while you can pull in most JS stuff, it doesn't work the other way around. Your CLJS library will not be a first class citizen in the JS world. It can be done but it's not a good idea. You can contribute to the CLJS world, but forget about contributing anything significant back to the JS world. If these two don't bother you, you should be fine.
- adamkl 6y ago
  > Your CLJS library will not be a first class citizen in the JS world. It can be done but it's not a good idea. Why is this? What makes it a bad idea? Does ClojureScript’s new ‘bundle’ compilation target [0] help resolve whatever issues you are referring to? Genuinely curious. [0] https://clojurescript.org/news/2020-04-24-bundle-target https://clojurescript.org/news/2020-04-24-bundle-target
  - auganov 6y ago
    Any CLJS code has to bundle the CLJS runtime. CLJS doesn't compile to idiomatic JS, for example a vector will be a cljs.core/PersistentVector not a JS Array. So code for most CLJS basics has to be bundled with any CLJS code to run. Let's say you write a tiny library that solves just one problem. I would imagine most people wouldn't want to have to pull in the CLJS runtime for just that. So let me be clear - there is no problem in using JS libraries, what you linked speaks to using npm libraries which previously was tougher. CLJS is doing very well on that front. What I'm saying is - if you write a library in CLJS, don't expect plain JavaScripters to use it.

invalidOrTaken 6y ago

At this point I think it's safe to say---clojurescript has proven itself and is not a risk. An excellent language, good libraries (Metosin's ambidextrous router, Reitit, stands out here), the best development story with Figwheel, and oh, dead code elimination for free, as the cljs compiler leverages Google's Closure (not to be mistaken for Clojure) compiler. Not to mention that cljs is actually a better fit for React even than JavaScript---implicit return, bias towards functional programming, and it requires no magic JSX step---in cljs you just write your html in nested data literals. It's a dream. I haven't even mentioned black magic like core.async, or that now your front-end devs have a foothold on the JVM rather than the more-impoverished Node ecosystem(oh, you want to keep Node? Well, cljs runs there too!). Pitch is a well-funded German startup making a presentation tool in the browser---as in, they can't afford to get their front end wrong---and they're comfortably using cljs. Frankly at this point I think anyone serious about the frontend, who wants it to be good, not just passable, should be using clojurescript. There are reasons not to---if you need something today, and don't have time to learn a lisp---but for anything not due next week, I'd recommend cljs.

yakshaving_jgt 6y ago
Conversely, I found the experience pretty terrible when I worked on a big cljs/reagent/reframe/figwheel app over the course of a couple of years. It was slow, prone to runtime errors (though not as much as JavaScript), and often presented weird edge-cases at the intersection between the Lisp world and the React world. The company ended up abandoning all this stuff after having been big Clojure/ClojureScript evangelists for a long time. On the other hand, after having built several large Elm applications, Elm is still the tool I'd recommend. On my current ~10KLOC Elm project, compilation is near enough instant, the structure of the code is more rigid so it's far easier to understand — even for beginners — and there's far less potential for runtime errors to occur. Of course, this is the classic religious war in programming, so I expect someone to appear soon and point out that there is no empirical evidence to support the idea that a type system like the one in Elm or Haskell results in fewer errors in practice. Or perhaps they'll say jet fuel can't melt steel beams.
- MikeOfAu 6y ago
  Hmm. This is likely to devolve into a static vs dynamic typing borefest. There is no right here: it is just different brain wiring (preferences), backed by motivated reasoning on both sides. But to address the three points you raise... I'm surprised to hear that there was a problem at the Reagent/React boundary. We find that works sooooo well. I genuinely love Elm's claims around 0 runtime errors. It gets my nerdy juices flowing. But then I remind myself that this is simply not a problem I have. We might get one every blue moon (in production) and then it is fixed and deployed about 10 mins later. I have many technical challenges (eg. Kubernetes etc), but runtime problems is not in my top 20. As to slowness, I can't comment without knowing more. We don't have that problem but that doesn't mean it might not exist in some domains. Then again, it could be bad design decisions. Dunno. One thing for sure, I'd choose Elm over javascript any day, but ClojureScript is just working too well for us right now.
- invalidOrTaken 6y ago
  I'm glad you commented, because the GP comment originally had at the end something like, "With one caveat---I still haven't given Elm a fair shake." Then I thought, "Nah, too esoteric for HN, I don't want to dilute things" and erased it. Joke is on me! I do hope to be able to make the time to play with Elm at some point---at one point I was very excited about FRP, and what took me away was time, not some fundamental, principled thing.

auganov 6y ago

Two main considerations: Does the bundle size matter? CLJS bundles are not terribly huge but if you need a very lightweight bundle you're out of luck. Vs plain JS there is just no comparison. Vs plain JS + just a few libraries CLJS will probably do worse too. But for anything bigger it starts to catch up. Say I'd never use CLJS for a landing page, but for most kinds of apps there shouldn't be a problem. How do you plan to interact with the wider JS ecosystem? One problem with CLJS is while you can pull in most JS stuff, it doesn't work the other way around. Your CLJS library will not be a first class citizen in the JS world. It can be done but it's not a good idea. You can contribute to the CLJS world, but forget about contributing anything significant back to the JS world. If these two don't bother you, you should be fine.

adamkl 6y ago
> Your CLJS library will not be a first class citizen in the JS world. It can be done but it's not a good idea. Why is this? What makes it a bad idea? Does ClojureScript’s new ‘bundle’ compilation target [0] help resolve whatever issues you are referring to? Genuinely curious. [0] https://clojurescript.org/news/2020-04-24-bundle-target https://clojurescript.org/news/2020-04-24-bundle-target
- auganov 6y ago
  Any CLJS code has to bundle the CLJS runtime. CLJS doesn't compile to idiomatic JS, for example a vector will be a cljs.core/PersistentVector not a JS Array. So code for most CLJS basics has to be bundled with any CLJS code to run. Let's say you write a tiny library that solves just one problem. I would imagine most people wouldn't want to have to pull in the CLJS runtime for just that. So let me be clear - there is no problem in using JS libraries, what you linked speaks to using npm libraries which previously was tougher. CLJS is doing very well on that front. What I'm saying is - if you write a library in CLJS, don't expect plain JavaScripters to use it.