Should the future of Clojure be ClojureScript?

So, its well understood that Clojure gained traction by being a hosted language on the dominant platform of the time (Java, duh), and ClojureScript was created later to target JavaScript in the browser, allowing for “full-stack” Clojure.

This approach has served the Clojure community well for a long time, but Java is no longer the dominant platform it once was, and I wonder if current pecking order of Clojure/Java being the “primary” version of Clojure and ClojureScript/JavaScript being the “browser” version of Clojure is hampering continued adoption of the language.

These days, new developers and large enterprises are much more likely (in my experience) to choose JavaScript/Node.js for their full stack (or at least large portions of it), and having identical language semantics and build processes for both browser and server eliminates a lot of friction.

Even though Clojure and ClojureScript are largely identical in their semantics, their interop/build process/runtimes/tooling are very different, and quite frankly, when it comes to new user adoption, once I mention Java-on-the-server, it becomes an instant “no thanks, not interested”.

Is it time for ClojureScript to take center stage? Should the community start looking at ClojureScript/Node.js for server-side development (e.g. Macchiato) as a viable alternative to Clojure/Java?

Just some thoughts from a Clojure fan-boy who’d love to see more people using it.

6 Likes

Who in their right mind would choose NodeJS over the JVM for server side programming? I must be living under a rock, but maybe I’ll just stay there.

25 Likes

Depends on your use case.

I agree that the JVM would be better for serious computation, but a primary use case for Node.js in enterprise is to integrate data from various back-end sources (including mainframes) for presentation via APIs. In that case, your primary concern is IO, and providing an API layer for consumption. This is where fullstack JavaScript/Node.js shines (even if JavaScript, the language, doesn’t).

Also, I don’t mean to be rude, but:

Who in their right mind would choose NodeJS over the JVM for server side programming?

Is, maybe, the kind of attitude that can alienate the millions of developers who do just that.

I’m personally not a fan of JavaScript (which is why I want to see more adoption of Clojure!), but you’d have to be living under a rock not to see that Node.js has supplanted Java in a lot of places as the dominant platform. And we can either stay under that rock and watch the world go by or accept that things change.

Maybe I should be taking a look in the mirror. If I want more people looking at ClojureScript/Node.js for server-side development, I should start promoting it to those around me as a start.

2 Likes

Java is still the primary choice of many, many companies – and especially “enterprise” companies. The JVM is heavily optimized for performance over the long haul. I agree with @borkdude: I cannot imagine anyone choosing NodeJS over the JVM for serious server side programming! I want multi-threading and battle-tested infrastructure, not callback hell.

15 Likes

I think there are people pursuing using Node and clojurescript as their backend, with the main driver being React server side rendering. (Although there are also people going the other way and using GraalVM for that).

But ClojureScript will IMO always struggle to offer the same development experience as Clojure because of the complexities and limitations of being a compile-to-js language. Clojure lives within its runtime and thus can offer the dynamic behavior of a true LISP. Clojurescript is “just” a compiler.

It’s also a very hypothetical question, a shift like that simply will not happen. What could happen is that a new project takes the lessons learned from Clojure and clojurescript and takes them in a new direction with different design goals. Either as a fork or as something brand new. That would certainly be interesting to see.

4 Likes

I’m curious about this. Maybe I’m missing some of the nuance in the differences between Clojure and ClojureScript, but my development experience via the REPL has been largely the same for both.

In both cases (Clojure via Clojure CLI/deps.edn [0], and ClojureScript via Shadow-cljs) I can connect the REPL to a running process, evaluate code in my application, and instantly see the changes. Is there something more to the experience that I’m missing?

[0] Thanks to Sean’s dot-clojure, which is a great reference

Out of curiosity, is there anything that the developers of Clojure and ClojureScript are doing that is hindering others from using ClojureScript on the server?

1 Like

I’d say no. In fact, the work of @thheller on Shadow-cljs and @Yogthos on Macchiato has made it easier than ever to use ClojureScript on the server.

I just felt like raising a concern (in an arguably click-baity way, apologies) that we are losing an opportunity to introduce Clojure to a whole generation of JavaScript developers by being so dismissive of the idea of using ClojureScript on the server.

I’m all for trying to introduce JavaScript developers to ClojureScript since it addresses so many flaws in JS and if they’re already using JS on the server, they’re no worse off using ClojureScript on the server.

But you pitched your original post as an argument for ClojureScript/Node.js to replace Clojure/JVM which I think is wrong-headed: people who chose the JVM for all its benefits are simply not going to choose Node.js and therefore in parallel with encouraging JS devs to switch to cljs we should also keep up the encouragement for Java/Scala/Groovy/etc devs to switch to Clojure. In both cases, you have developers who are comfortable with their infrastructure and used to the tooling and devops around it, and “all” they need to do is trade up from their current language to Clojure/Script and keep everything else the same.

And don’t forget ClojureCLR where we can encourage C# and F# developers to switch to Clojure and still keep everything else the same! :slight_smile:

6 Likes

Thinking about this some more, probably one of the biggest obstacles to ClojureScript adoption in JavaScript shops is that the ClojureScript compiler requires a JVM – and macros essentially have to be “escaped” into Clojure/JVM land (even if that happens “magically” via the cljs compiler running on the JVM).

There are also differences where Clojure is simply richer as a language than ClojureScript: Vars (as reified entities), refs, STM, agents, namespaces (distinct entities in Clojure, regular JS vars in cljs), etc per https://www.clojurescript.org/about/differences

2 Likes

I wouldn’t say I suggested that everyone running Clojure/JVM should stop what their doing, tear everything down, and switch to ClojureScript/Node.js. Just like I wouldn’t suggest that everyone using ClojureCLR stops using that.

I’m not an expert, but my understanding was that Clojure on JVM was a pragmatic choice, based on the dominance of Java at the time and the desire to leverage an existing ecosystem.

But now the dominant ecosystem is JavaScript (like it or not, and I don’t), so if Clojure was created now, would it still have leveraged the JVM? Or would Clojure have targeted JavaScript first and would ClojureJVM have come later?

Is the fact that Clojure is so closely associated with the JVM a hindrance to further adoption?

I don’t have a bone to pick with the JVM. I just want more developers to try Clojure, but for many of them, the JVM is a dealbreaker, which is unfortunate.

I would not bet on the JVM over Javascript in 2030

4 Likes

I’d say that Clojure and ClojureScript complement each other wonderfully. Neither should or can “replace” the other. I will never write anything server-side running node when I have the option to use Clojure. ClojureScript can reach places that Clojure can’t. That was the original plan and it is working great.

3 Likes

Maybe its working great for people who started with Clojure/JVM and saw ClojureScript as an alternative to JavaScript, but what about the other side of the fence? Those who start with JavaScript (which is now, far and away, the majority)?

In the JavaScript ecosystem you have libraries like immutable with 3 million downloads/week and ramda with nearly 6 million downloads/week. These libraries are clearly inspired by Clojure, so why aren’t these developers just using Clojure? I think its due in large part (from my conversations with younger developers, and whether we like it or not) that having to use the JVM on the server is a non-starter (or maybe it really is just all the parens!).

I realize that most everyone here (already heavy Clojure users, and likely intimately familiar with Java/JVM) are productive and happy with the current state of affairs.

I just wanted to raise the question, would Clojure have greater adoption if ClojureScript was presented as a first-class option for server-side development?

I don’t know why anyone does anything.

Who says it isn’t? It is not a job of the Clojure team to promote anything. It is a community thing. Just write about how cool CLJS is and stop using the JVM as an argument or even mentioning it. In ClojureScript it certainly is not an issue and probably nobody ever wrote any Java to write ClojureScript. Maybe people just equate the JVM with Java which just completely misses the point. Anyone dismissing ClojureScript just because of the JVM probably didn’t have much interest to begin with.

Especially “younger developers” probably lack the experience to judge for themselves properly and get infected by the anti-JVM FUD more easily. If your company forbids using the JVM they probably wouldn’t allow ClojureScript in the first place either.

Getting started with Clojure(Script) is hard. The learning curve is absolutely steep. There are soo many things to learn all at once. I don’t think that the JVM is the problem we need to address (or a problem at all for that matter). I heard from enough people that were actually surprised that shadow-cljs used the JVM so it can’t be that big of a factor.

3 Likes

Some of the bigger voices in the Clojure community:

Also:

I agree:

I just wanted to start a discussion to see if people were receptive to the idea of ClojureScript playing a bigger role in the Clojure community.

It seems like the clear answer here is: No, and that’s OK. Stick with what works I suppose.

1 Like

We maybe don’t express it well. CLJS is absolutely viable, we just prefer Clojure when we have the option. This however also comes from experience so it might be worth considering that this is not without reason and maybe we should talk more about why that is.

1 Like

I think in terms of dollar sign, JVM is still ahead of NodeJS. And I’d be willing to bet that C# might be second or even beats the JVM, again, in terms of dollar signs. While I have no data to back this up, and actually would love it if someone had data about this, even if it shows me wrong :stuck_out_tongue_closed_eyes:

Anyways, I am in full support of efforts to make ClojureScript server side more viable. I also love self-hosted ClojureScript, but the issue is that the Google Closure compiler is Java based, and its JS counterpart lags behind and is still experimental and it’s not clear if Google will ever shift its focus from the Java one to the JS one.

As a full featured language, Node provides less opportunities, the platform isn’t as evolved yet, but it could catch up eventually, though maybe Node is just another JS fad soon to be replaced by Deno who knows.

With all that in mind, I think it’s best to address what some others mentioned:

  1. What’s lacking when it comes to ClojureScript?
  2. Why not both?

I think reach is a fundamental goal of Clojure, and that’s why Rich Hickey actually provided three implementations: Clojure, ClojureCLR and ClojureScript. And nowadays we also have a pretty solid interpreted variant Babashka (and SCI), and something that’s getting close to production ready in Magic (for Mono) and in Clojerl (for Erlang).

I love all of them and think the future is all of them. Which one will become dominant I don’t know, but a personal appeal of Clojure is that reach.

5 Likes

I can’t help but agree with this. JS is becoming the universal runtime, implemented by multiple large organizations with huge investments, and growing rapidly. Dismissing it seems classic innovators dilemma.

Personally, I occasionally daydream about a clojure like lang minus the java idioms, more js ecosystem native and that plugs into the denojs runtime as typescript does.

1 Like

I love using ClojureScript however most of my work is in TypeScript doing frontend work. JavaScript code generated by ClojureScript is too complicated for debugging and I would not expect people loving that. If ClojureScript was created today, given the situation that WebAssembly has already been supported by all major browsers, I would expect more on Clojure on WASM, even though there are still years before WASM become really mature. I would say JavaScript is not a good compilation target for Clojure since JavaScript has its own semantics and TC39 is still adding features to it. We are mostly compiling to ES5 today, while JavaScript is already moving toward ES2021. And JavaScript was definitely not designed to be a compilation target, while WebAssembly paid lots of attention on that.

2 Likes