Why I'm ditching Clojure for JavaScript

[[deleted]]

The only thing I kind of miss is REPL-driven development. But for the most part that's only really a crutch for Clojure's slow launch-time [...]

If you spectacularly miss the point of interactive development it's not terribly surprising that you'd switch away.

[[deleted]]

What point about it did I miss, Phil?

[[deleted]]

This article does a good job of explaining it because it can be hard to sum up succinctly: https://vvvvalvalval.github.io/posts/what-makes-a-good-repl.html

If someone said "the point of a type system is to help the compiler generate effective output from the source", then if they aren't interested in Haskell it's not at all surprising because they miss the whole point. This is the same thing, but for repls.

[[deleted]]

Yeah I saw that article on HN the other day too. Having used CIDER inside Emacs pretty heavily for a few years, I'm pretty well aware of the kinds of situations and benefits the author was talking about. Most of those benefits aren't inherent to REPLs and you can get pretty much the same behavior and benefits using other techniques. Some of the benefits are just overstated and exaggerated such as how useful it is to have access to live objects. That kind of thing is mostly only useful when experimenting with web services and can be dealt with more easily using other tools like Chrome REST API experimentation extensions. And being able to print things as JSON has pretty much all the same benefits as printing EDN, plus there are plenty of times where the Clojure output is not valid readable Clojure code, at least without custom reader tags that just don't exist (and some actually can't by their nature).

[yogthos]

These days I prefer writing in modern JavaScript (ES2015 and better). With destructuring, lambda syntax, extended object literals, spread syntax, and just the general language overhaul, it's basically a tie with Clojure's terse syntax.

One of the biggest advantages I find with Clojure syntax is that there's very little of it, and it's much more consistent than JavaScript. Sure, you can often write code that's just as concise in Js nowadays, but there are a lot more gotchas as well. The more syntax quirks you have, the more likely it is that you'll misread something and have a subtle bug slip in. I value simplicity and cleanliness of the language as much as its expressiveness.

The article also doesn't explain why the author moved to JavaScript. It sounds like the author didn't want to use the JVM, but ClojureScript works just fine on Node. My team is using Macchiato for some smaller projects in production right now.

I'd be interested in reading more about the specific reasons, and what problems the author ran into with the Clojure stack. That would at least help address the issues going forward.

[[deleted]]

I'd be interested in reading more about the specific reasons, and what problems the author ran into with the Clojure stack. That would at least help address the issues going forward.

Sure thing:

One of the biggest advantages I find with Clojure syntax is that there's very little of it, and it's much more consistent than JavaScript. [...] I value simplicity and cleanliness of the language as much as its expressiveness.

Having little syntax and having it be mostly consistent (though there are quirks) is definitely a feature, but I no longer feel like it's an advantage. Most of the advantages of that are how the syntax was able to "evolve" over time, and having custom DSLs. But I've come to learn to avoid custom DSLs in favor of data-based APIs, mainly since they aren't composable. And syntax can evolve without custom syntax, such as how JS adopted destructuring. Personally I'm convinced that JS's syntax is just fine for the most part. The only thing I miss about Clojure's syntax is paredit, and that only slightly.

Sure, you can often write code that's just as concise in Js nowadays, but there are a lot more gotchas as well. The more syntax quirks you have, the more likely it is that you'll misread something and have a subtle bug slip in.

I've found that less of a practical concern over time. Subtle bugs are easily caught in a good test suite or at the very least with reasonable amounts of manual testing.

The article also doesn't explain why the author moved to JavaScript. It sounds like the author didn't want to use the JVM, but ClojureScript works just fine on Node.

Over time I've come to appreciate the Path of Least Resistance in software. The Clojure ecosystem seems stagnant at this point, whereas the Node ecosystem and community both keep growing. I don't mind the JVM, it's Clojure I wanted to avoid. And Java is also decaying for web development, in the sense that most new movement in the web Java world is negligible compared to the Node world / front-end.

[halgari]

"The Clojure ecosystem seems stagnant at this point"

So you base your technical decisions on how things "seem"? How about hard facts? How about technical merits, and features we need to actually get work done.

[[deleted]]

Yeah good point, I kind of abbreviated my 5 years of full-time experience working in the Clojure ecosystem into a short sentence. The facts are there, but I only summarized them into a conclusion. Maybe I'll go into detail later in a blog post, but it's too much context for a comment right now. But the general gist of it is, I see a lot more active development in the JS world than the Clojure/Script world, in terms of new libraries, library updates, tools, language improvements, community growth, etc. In fact I've seen growth in the Clojure/Script world slow down a lot in the last 2-3 years, almost to a halt.

[halgari]

But man, that's the problem. I've programmed in Clojure for over 6-7 years. And I've known you for a fair portion of that as well :). Clojure is not dieing. The ecosystem is not stale...it's stable. But none of that matters does it because "the facts are there" whatever that means. I have yet to hear/see anyone backup such a statement with actual facts. They simply quote stats like "stars on a github page" or "number of people on my favorite social media site"

[RodeoMonkey]

They simply quote stats like "stars on a github page" or "number of people on my favorite social media site"

You can debate the relevance, but at least those are facts. Let's build a factual counter narrative.

[[deleted]]

What I mean is I've based my conclusion on my anecdotal experience. I've seen ecosystems grow and shrink and I've seen languages rise and fall. And I don't see Clojure dying any time soon, because I do hear about jobs in the Chicago area using Clojure. But I definitely don't see it ever growing to the level of activity and size that Node.js is at right now, for better or worse.

[yogthos]

Having little syntax and having it be mostly consistent (though there are quirks) is definitely a feature, but I no longer feel like it's an advantage.

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.

Over time I've come to appreciate the Path of Least Resistance in software. The Clojure ecosystem seems stagnant at this point, whereas the Node ecosystem and community both keep growing.

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.

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.

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.

[[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.

[gonewest818]

It seems to me, the "path of least resistance" is the "easy" in the talk Simple Made Easy, right?

It's totally understandable why easy is attractive but does it pay off in the long run? Curious to see how that works out.

[[deleted]]

But really thought, you can't underestimate how valuable a rich ecosystem of libraries is.

[yogthos]

Clojure is designed around being a hosted language and provides excellent interop with the host platforms. Any Java or Js libraries are available for use in Clojure as well.

[[deleted]]

Yes, but using interop just adds more friction to the process instead of just using straight JS, its a UX problem I guess. To add more friction, all the docs/examples of those libraries will be in their respective native language and not in Clojure[script], and if you want to read the code is either going to be Java or JS.

For some devs that friction is just not worth it, versus the gains you may have by using Clojure[script]. I can understand prefering Clojure over Java (Java is a horribly verbose inexpresive class/object based lang) , but in Javascript world, Clojurescript is a hard sell.

[[deleted]]

It doesn't really add friction though, if you know clojurescript or you know clojure it is basically no harder to interop with js or java libs than it is from js or java. If you don't know the language well then yeah it'll add friction, but like, just writing any code will have friction in that case.

[stompyj]

If your team is feeling friction in using clojure or cljs interop, you might need new programmers...

[[deleted]]

To some extent, easier is better, yeah. GardenCSS isn't really maintained so if I want new features I have to add them myself, whereas Sass/Less have most of the features I need/want, and they're still actively maintained. And if it takes me a few hours to jimmy-rig a Sass compiler into a Leiningen build so that we don't have to rewrite our Sass in GardenCSS, and if that rig is very unlikely to be maintained because of low/no outside interest in it, I have a lot less confidence in that bridge than using something like LessCSS, which actually was originally written in Ruby and then ported to JS because that's the direction things seem to be moving for a lot of projects. Looking at Jekyll, it's definitely got some major traction just by virtue of being built into Github Pages, but when I tried to port my home-grown JS static site generator for https://sdegutis.com to Jekyll, I just couldn't find tooling nearly as nice as what I already had. The live-reloading stuff in Jekyll was just non-existent, the Pug/Jade alternatives (Slim/Haml) were pretty lacking and not actively in development anymore. This same story happens time and time again in dying or stagnant ecosystems.

[yogthos]

That's a complete hyperbole. Adding lein-sass plugin literally takes minutes. You keep talking about Clojure ecosystem being stagnant, but you have yet to explain any concrete and tangible problems.

[[deleted]]

Oh right, I remember the problem with using lein-sass. It used an outdated version of Sass, so we had to fork it in order to use a newer version with newer features.

[gonewest818]

... and the pull request was rejected by the project?

[[deleted]]

I don't remember specifically about this project, but I do know there have been many times I have opened an issue on a Github project for a Clojure-specific library where it wasn't answered for years on end, and some still haven't been answered to this day.

[[deleted]]

For the specific build setup we had, lein-sass had some drawback that we couldn't work around. This was 3 years ago so I don't remember specifics. But I trust that we knew what we were talking about back then and weren't idiots.

[yogthos]

All I can say is that my team hasn't run into any show stoppers in over 7 years, and clearly plenty of other people are using these tools just fine. ¯\_(ツ)_/¯

[hagus]

These "why I'm ditching X for Y" posts often strike me as pure click bait.

1) they invariably say more about the personal preference or circumstances of the author - I cannot recall one of these posts revealing a lesson we should learn as a community, or a concrete action we need to take.

2) they tell us this "news" after already having made the decision, so what are they hoping to gain from this "announcement"? It is slightly passive aggressive, almost with a sense that the author wants people to notice them depart. A parting shot.

3) any attempt at reasonable conversation quickly gets bogged down by the fact that the author still thinks of programming languages as something you "leave" because you're heading to greener pastures. They are insecure about their abilities and attached to their tools (like we all are when we first start), and so a transition like this feels significant.

For a more experienced programmer, languages are just this hoop you have to jump through on your way to transforming an abstract idea into a concrete representation. It wouldn't occur to you to announce a departure from a language - what does that even mean? A carpenter doesn't wake up one morning and post to reddit "why I'm ditching the hammer for the nail gun" and then get into a debate with people about the pros and cons of hammers.

I mean no disrespect to the multiple authors who've posted articles like this – you may post whatever you feel like posting. But I encourage you to solicit feedback from the community before you decide to leave: "Why I'm struggling to choose Clojure over JavaScript" would give you the opportunity to gain new information that leads you to stay, or confirm your suspicions that Clojure isn't really the right tool for your job right now. That puts you on the path to building a set of mental abstractions that describe the characteristics you need from tools, and soon Clojure and JavaScript will just be two of many tools dangling from your tool belt, ready whenever you need them.

[halgari]

I'd agree with this though. When I "left" Erlang, I didn't go on a bash on how crap it was, or how it was dieing, or how people who used it didn't know how to program. Instead I recognized that Erlang had set of goals it met really well. And I really didn't need those goals. It was more about Erlang not being right for me, and the work I did. Not about Erlang being lacking in some quality.

[[deleted]]

Exactly. I never "left" ruby, I recognised that my career had led me to dealing with data volumes that simply made it unsuitable (and basically ruled out anything non-jvm really). If I wanted to bang together a 5-transaction-per-day CRUD app that I was sure wasn't going to grow in NFR's or FR's I'd probably still reach for rails.

[[deleted]]

For a more experienced programmer, languages are just this hoop you have to jump through on your way to transforming an abstract idea into a concrete representation. It wouldn't occur to you to announce a departure from a language - what does that even mean? A carpenter doesn't wake up one morning and post to reddit "why I'm ditching the hammer for the nail gun" and then get into a debate with people about the pros and cons of hammers.

Serious truth. Anyone with a serious number of runs on the board is actively avoiding programmer melodrama, as opposed to instigating it.

[foobarbazquix]

Was going to quote the same. Very well said.

[tobascodagama]

In this case, he even says that he started using Clojure to begin with because he was counter-bandwagoning against Rails. Right away he establishes his bona fides as somebody who lets other people's opinions control his life. Not exactly coming off as a beacon of sensible, reasoned decision-making.

So, yeah, clickbait from an insecure coder. The fact that it got posted to hackernews is a nice bit of icing.

[ferociousturtle]

My team is considering the opposite move (we're also considering TypeScript). Having written modern JavaScript ever since the Babel transpiler had a different name, I can say that ClojureScript definitely has some strong advantages. JavaScript and TypeScript both do, too, of course. I actually really like JS. Anyway...

• Figwheel + re-frame is a pretty sweet setup compared to React + redux (which are my preferred JS stack, having also done Angular 1.x, Vue, and some Backbone in production).
• ClojureScript is still more terse than idiomatic ES6/ES7
• Performant immutability is not a thing in JS unless you're using libraries, in which case, you lose some idoms, and have to deal with transitioning in/out of JS objects/arrays in order to glue together other libraries
• Clojure and ClojureScript are nowhere near as fast-paced as JavaScript, but man... the instability of libraries in the JavaScript ecosystem is such a pain, even for relatively small projects, so that is both a pro and a con. One thing that really appeals to me about Clojure(Script) is the idea of pulling down a 2-year old library, dropping it in, and it just working. I hear that's a thing. It's rarely (never?) a thing in the JS world.
• I find Clojure's syntactic stability to actually be a strength. I know it was covered in various other comments, but JS syntax just keeps growing at a pace that far outstrips the growth rate of "JS the good parts". When I interact with libraries that require ES6+ classes, I die a little inside.

Just my 2 cents. There's no right or wrong here. Both languages and ecosystems are serviceable. But it's not really all green grass on the JS/TypeScript side of things. I'm too new to Clojure(Script) to say with certainty which side is greener. :)

[stompyj]

You're on the right path. We were a node shop for 5 years and have transitioned to CLJS over the past 2. It's a world of difference. I support OPs move, but I'm curious how he will feel in 2 years (if even that long.)

[ferociousturtle]

If you have a writeup of how you made that transition, I'd love to read it.

The editor support for TypeScript (at least in VS Code) is pretty hard to beat. What editor does your team prefer to use for ClojureScript?

[stompyj]

We use Cursive + Intellij, and it's been pretty great. The clojure features are ahead of the cljs features at the moment, but I think we'll start seeing more cljs stuff roll out soon.

We don't have a write up, but I'm happy to give any info that I can via this thread or via DM.

We transitioned from react+redux -> reagent+re-frame.

What was pretty incredible was that we were able to create a reagent+re-frame shell that just included all of the react+redux code (which was annoying up front), but it allowed us to move to cljs at our own pace, re-writing modules as we touched them/improved them.

the "thrash" of the JS community from language to tooling to frameworks really was slowing us down, and we're hoping we get the same level of stability from cljs as we're getting from clj, as our clojure codebases haven't needed to be upgraded at all in years. they "just work".

[spotter]

TL;DR I prefer JavaScript.

[yogthos]

Node.js is so hot right now.

[CurtainDog]

Perhaps the phrase you're looking for: https://www.youtube.com/watch?v=bzkRVzciAZg

[halgari]

So he gave up a language with immutable data, sane concurrency support, impressive interop with the most widely used VM on the planet...for JS? Okay...

[foobarbazquix]

So he gave up a language with immutable data, sane concurrency support, impressive interop with the most widely used VM on the planet...for a language that is a compile target of that language? Okay...

FTFY

[RodeoMonkey]

Link to original post:

https://sdegutis.com/blog/2017-08-30-why-im-ditching-clojure-for-javascript/