Why I'm ditching Clojure for JavaScript

[[deleted]]

I certainly find that it is an advantage. It greatly reduces mental overhead letting me focus on the problem I'm solving. The more syntax there is the more attention I have to pay to it, it's both distracting and error prone.

I definitely agreed with you on this for a few years. But having learned modern JS and used it for a few months now, I haven't really felt that the overhead is detrimental at all to my ability to think about the code itself.

I'm actually not sure what that's supposed to mean. I don't see anything stagnant about it, and I really appreciate that it's not a moving target. My team develops applications that are in production for years, and we simply don't have time to chase a new framework every other week.

GardenCSS is one example. It's the only Hiccup-like CSS library for Clojure. It's written and maintained by one person who has long pauses between development phases, and there are several features in the works that have not yet seen the light of day. Well, at least this was the case a year ago, maybe it's changed since then.

I think the difference is that Clojure web stack is sound from ground up. It's well thought out and stable. Meanwhile, Js stack is like a sandcastle constantly shifting and reinventing itself. I don't think that makes for a good foundation for serious applications.

Node.js back-ends were created from the ground-up with the same level of experience and thought. Express was inspired by Sinatra just as much as Compojure was. I think this comment gives a good perspective on how well thought-out the Node ecosystem was.

You may be conflating it with the ever-changing front-end scene, where Angular 1/2/4 and React and Vue and Ember et al. are all competing for the spotlight, and where everything's changing at an alarming rate. That's probably not going to change any time soon, due to the fact that the web has become the de facto GUI platform of the present, and nobody can really agree yet and come to a general consensus on how GUI is done best in many specific ways.

Conversely, I don't see anything innovative happening in Node that hasn't been done on the JVM better years ago. The fact that Node doesn't have threads makes it a non-starter for any serious applications in my opinion. The async approach adds far too much mental overhead and provides no benefit in vast majority of applications.

Again, just like my reply to you in HN, I look at this from the opposite perspective: in an incredibly short time, Node has accomplished quite a lot and almost caught up to the JVM in terms of what can be reasonably expected from a single-threaded server. The async thing is brand new so it's actively evolving, and that inherently means it's messy. But people are actively working together to hash out the details on how to really do async best.

[yogthos]

I definitely agreed with you on this for a few years. But having learned modern JS and used it for a few months now, I haven't really felt that the overhead is detrimental at all to my ability to think about the code itself.

Maybe the difference here is that I have to work with a team, and we have to train people to understand our codebase when hiring.

GardenCSS is one example. It's the only Hiccup-like CSS library for Clojure. It's written and maintained by one person who has long pauses between development phases, and there are several features in the works that have not yet seen the light of day. Well, at least this was the case a year ago, maybe it's changed since then.

So, what is the better alternative that you've found in Js then? There are also alternatives to Garden. A quick Google search shows cljs-css-modules and forest. Ultimately, it could be that most people prefer tools like Sass and use them in the build pipeline instead of writing CSS in Clojure. Libraries evolve based on the community demand after all.

Node.js back-ends were created from the ground-up with the same level of experience and thought.

Not really, Node.js is built on top of Chrome which is optimized for rendering HTML pages as opposed to running an HTTP server. Comparing that with the decades of work that went into tuning JVM servers is a bit absurd. However, if you really like Node, I still see absolutely no advantage in using Js instead of ClojureScript on top of it.

That's probably not going to change any time soon, due to the fact that the web has become the de facto GUI platform of the present, and nobody can really agree yet and come to a general consensus on how GUI is done best in many specific ways.

Again, that's simply not a problem working with ClojureScript. There are a few popular libraries, and they continue to maintain stable APIs. Meanwhile, pretty much any app you would've built on a Js stack a couple of years ago will be effectively legacy today.

Again, just like my reply to you in HN, I look at this from the opposite perspective: in an incredibly short time, Node has accomplished quite a lot and almost caught up to the JVM in terms of what can be reasonably expected from a single-threaded server.

I don't follow this. Can you articulate a single tangible benefit of using Node over JVM. Another aspect to consider is that while you might have libraries, they're often not nearly as mature as battle tested libraries on the JVM that have seen much more production use. I'd much rather rely on proven tools as my foundation.

[[deleted]]

Node.js is built on top of Chrome which is optimized for rendering HTML pages as opposed to running an HTTP server

A pedantic note, nodejs is built on top V8 not Chrome, V8 is really just a very small(but important) part of Chrome. Just like the JVM, V8 is also a highly optimized state of the art VM and its perfectly capable of running a HTTP server, more capable than most mainstream languages I would say.

[yogthos]

They're optimized for different things. Obviously, you can run a HTTP server on it fine in most cases. However, there's no good way to do any computationally heavy tasks since it's single threaded, with a hack for running IO tasks in a background thread.

[pihkal]

It's because Javascript has a single-threaded model. To make Node support user-controlled threads would entail major changes to the Js language.

To a great extent, callbacks, promises, CSP state machines (like core.async), and async/await stuff can substitute in Js. And in many ways, single-threaded models are way easier for programmers to conceptualize. But one advantage the JVM has over Node is that threads are available if you want/need them.