My perspective as someone who writes clojure for the back end as a living: not in the near future, if ever.
There’s more to backend than connecting to the front end. You can have plenty of services processing very large volumes of traffic which don’t even breath in the direction of client facing data. In that type of environment the JVM is amazing. It’s very well engineered and does its job extremely well. Threading, JIT, STM and runtime dynamism make it a very good match for Clojure. On top of that you have the huge and well tested Java ecosystem.
Even if you dislike Java, I wouldn’t want to move away from the JVM.
5 Likes
In applications that use multithreading I think ClojureScript cannot replace Clojure without fundamental changes to how multithreaded concurrency or parallelism is achieved (in JVM a process can have multiple threads and they can communicate with each other, in JS as far as I know you would need to start different processes, lacking inter-threading communication between the processes, which forces you to use some extra infrastructure for such communication if you would need it)
1 Like
There’s lots of arguments being made here on the technical superiority of the JVM as a language runtime, and how using anything but the JVM for Clojure on the server-side is a mistake.
I don’t dispute that the JVM is an excellent general purpose runtime (I said earlier, I have no bones to pick with JVM, I’m happy to use it when it makes sense). Node.js specialty is async IO, and there are cases where it makes sense to use it.
But my original question wasn’t about the technical merits of one runtime over another, but rather about the continued adoption of Clojure the language. Rich made a pragmatic choice by designing Clojure to be a hosted language on the dominant runtime, and it gained a lot of traction by offering an alternative for existing Java developers (i.e., most of the people on this forum), but (to be a little hyperbolic about it) that ship has sailed. After +10 years, most of the Java developers that would have made the switch already have, so what about the next 10 years?
Just for a little perspective for those who haven’t worked with Node.js, express, the most popular webserver library for Node.js, sees more downloads in one week than ring has probably seen in its lifetime. The number of Node.js/JavaScript developers is staggering.
ClojureScript seems to be viewed as an alternative to JavaScript for Clojure developers. All I’m raising is the idea that if ClojureScript was presented as first-class language in its own right, an alternative to JavaScript for JavaScript developers (as it was for Java), it might entice some JavaScript developers to make the switch.
2 Likes
I do love Clojure and Clojurescript but agree with others that I will always choose clojure when possible and vastly prefer working in it overall.
I don’t think Node is superior to the JVM at async IO. Node doesn’t have real threads. You could implement anything you could do on JS on the JVM pretty easily but the reverse is not true.
Do you have anything other than popularity, familiarity and ease of use as a reason to make this change? These things are pretty explicitly non-goals in the design and stewardship of Clojure. Of course you are free promote your own agenda.
The creation of cljs was a brilliant move intended to extend the reach of clojure and I think it is doing a great job at that. The two complement each other excellently.
If anything, I’d say we work towards bringing back the JVM in the browser. Applets 2.0! 
1 Like
As someone who has evangelized ClojureScript for nearly at decade at various JavaScript conferences, I’ve seen no evidence that doing anything JavaScript specific around the technology would dramatically change the level of interest.
There are also no real barriers to doing what you’ve proposed. We’ve had self-hosted (JVM-less) ClojureScript for nearly five years.
I think it’s worth pondering why it hasn’t already happened.
Yet somehow given the lack of any specific effort on our apart to appease JavaScript developers the annual Clojure surveys show an increasing number of users coming from JavaScript.
My own opinion is that JavaScript fatigue is quite real, and disillusionment will only increase with time and we don’t have to do much other than make reliable software that embraces Clojure’s principles.
18 Likes
Just for a little perspective for those who haven’t worked with Node.js, express, the most popular webserver library for Node.js, sees more downloads in one week than ring has probably seen in its lifetime. The number of Node.js/JavaScript developers is staggering.
While I agree that express is much more popular than ring, I don’t think the download numbers can be meaningfully compared. I think they reflect differences in build tooling more than anything.
1 Like
What I understand from this is that only java developers will try clojure, while only javascript developers will try clojurescript, and I disagree with that.
While being familiarized with a certain runtime could make you try Clojure(script) on that specific runtime, I don’t think the choice of ‘main’ language (Clojure/ClojureScript) should be solely made on user adoption or familiarity. I myself come from using (functional) javascript and I picked Clojure over ClojureScript on my server project because multithreading is something important in my application that wouldn’t be possible on ClojureScript.
ClojureScript seems to be viewed as an alternative to JavaScript for Clojure developers. All I’m raising is the idea that if ClojureScript was presented as first-class language in its own right, an alternative to JavaScript for JavaScript developers (as it was for Java), it might entice some JavaScript developers to make the switch.
I agree, it looks like ClojureScript is more what the Clojure people use as javascript alternative for frontend, rather than a real alternative to JavaScript people, although I think that ClojureScript can be presented as a first class language right now without having to “replace” Clojure to become more dominant
Is this not how we present it?
I’d agree about the lack of distinction in tutorials, guides and books between content about Clojure and content about ClojureScript. And I guess the overall lack of good ClojureScript specific resources. Maybe this is all that would be needed to make it feel more “first class” like you say?
Or are you envisioning tooling and the language changing in some ways?
I guess it would help the conversation to move to the second level, let’s say we agree and want to make ClojureScript the future of Clojure, then what? What would we do differently?
2 Likes
I must comment on this since you brought up these numbers before. These numbers are absolute horseshit. Do not trust them. I do not know what they are counting but it does not represent users.
According to npm shadow-cljs sees ~16k weekly downloads. According to clojars it had ~327k downloads total in the 3-ish years since release. These numbers do not add up. Not that they mean anything in the first place.
You know, for somebody who has done such great work at trying to get ClojureScript and JavaScript to play well together, you seem to have a lot of disdain for the JavaScript community. Implying that both the size of it being “absolute horseshit” and full of developers who “lack the experience to judge for themselves properly” when it comes to their technology choices.
Credit to @didibus for trying to make a conversation out of this, which is all I was trying to get started, but it seems pretty clear that much of the Clojure community is happy with the status quo. Which is totally OK.
I just thought that, given the prominence of the current JavaScript community, ClojureScript could be a major player in the increased adoption of Clojure (the language), and, quite frankly, I’m a little surprised by the hostility that idea received.
I agree that the disillusionment is real, but I don’t think that “ignore them, and they will come” is a realistic strategy to increase adoption.
But then again, maybe that isn’t the goal of anyone here, which is fair.
1 Like
I don’t think there’s any hostility about the general idea. Just disagreements about how to go about it. ClojureScript has already been a major player in Clojure’s adoption and continues to be.
I didn’t imply ignoring. Just that I haven’t seen any evidence that’s there’s any sustained interest in what you’re suggesting - in fact the opposite. People have tried over the years and it’s never gained much traction. Instead what appears to happen is that people start using ClojureScript and then realize Clojure is waiting for them. Beginners aren’t beginners forever.
But it’s possible that somehow people have done it wrong time and time again and you have a better way to go about it wrt. getting JavaScript developers specifically excited about adopting ClojureScript.
So either this is a sort of empty conversation, or you’re proposing to take this one yourself and lead the way 
8 Likes
I guess its a self-fulfilling prophesy when even the lead developer of ClojureScript implies that its for beginners, and the only true Clojure is on the JVM.
I concede. No hard feelings. 
There is no hostility here. Sorry if it appeared that way on my end. I do like JavaScript and use it quite a lot, otherwise shadow-cljs probably wouldn’t exist. I also do try my best to make the experience for JS devs as seamless as possible. I do want more people to adopt Clojure(Script). I do want to support all use-cases and I have guided multiple people through some node issues. I do however not care one bit about converting people that dismiss Clojure(Script) outright because of the JVM. That energy is better spent elsewhere.
2 Likes
Hrm? I’m talking about users with a lack of familiarity around Java / JVM. As people use ClojureScript they tend to lose their uneasiness about an unfamiliar piece of technology over time. In that process it’s not surprising that they also eventually embrace Clojure as part of their stack.
Believing I implied anything else would be stretch The “only true Clojure” running on my iOS and Android devices is ClojureScript.
4 Likes
I think part of the problem here is that you come in, with your very first post in this community and assert stuff like:
and suggesting that “the community” consider switching from Clojure/JVM to ClojureScript/Node.js (you literally said that: “Should the community start looking at ClojureScript/Node.js for server-side development (e.g. Macchiato) as a viable alternative to Clojure/Java?”).
And then you got annoyed with several people who pushed back and said that the JVM was really good for serious server-side development and that they wouldn’t use Node.js (for various perfectly good reasons). Then you started to ascribe hostility to everyone who joined the thread and didn’t agree with you – even after you admitted your initial post was “click-baity” (which is not a good way to start any serious discussion – and we just had a whole thread about “X considered harmful” being a bad way to start a discussion!).
You’re not doing a great job of “reading the room” here.
Let’s wind back to the beginning and look at what people are saying:
- Java is still one of the top languages out there. Tiobe, for all its flaws, puts Java 2nd and JavaScript 7th. Stack Overflow’s 2020 survey ranked JS 1st and Java still 5th (but given that it ranked HTML/CSS as the 2nd top choice, I’m not sure I put much credence to their choices or methodology). The IEEE ranked Java as the 3rd most desirable skill to learn in 2020, ahead of JS (4th). Java is the new COBOL: millions upon millions of lines of it mean it’s not going away any time soon and, together with the flood of new languages based on the JVM, that means that the JVM isn’t going away either. So Clojure/JVM is going to be a solid choice for a long time (and the JVM just keeps getting better with every release).
- Everyone here concedes that JavaScript is popular and that having ClojureScript as an alternative for JS developers is a good thing. Some of us wouldn’t touch JS under any circumstances, some of us just wouldn’t use it on the server, and some of us use JS alongside side or even instead of ClojureScript (where I work, our entire front end is built in JS and I have major admiration for our front end devs and all the churn they have to deal with the in JS ecosystem).
- As the author of shadow-cljs said, the JVM is pretty much a non-issue for folks using that tool for ClojureScript (some are even surprised to learn it requires a JVM to run).
- The project lead for ClojureScript – who has been promoting ClojureScript for a decade in the JS world – has seen no evidence that the level of interest could be dramatically increased by changing how ClojureScript is presented (and, knowing how enthusiastic he is about ClojureScript, and how incredibly smart he is, I’m inclined to believe him).
- We would all love to see more people using Clojure/Script – no matter what their background. The reality is that Clojure/Script is a niche language: there are lots of reasons people either don’t want to learn it or don’t like it after they’ve spent time using it. Even some people who’ve spoken enthusiastically at Clojure conferences and/or written plenty of glowing articles have moved on from the language, either back to their prior language (be it Java or JavaScript) or on to something new.
In the JS space – for running on Node.js or in the browser – there are plenty of language choices so ClojureScript is “competing” with them, just as Clojure is “competing” with (most the same ones) on the JVM too. Scala, Kotlin, Haskell are examples of strong stories in both the JS and JVM space. CoffeeScript, TypeScript, PureScript are examples of JS-specific languages that also have dedicated followings. The JS world is a very big tent. But, just like the JVM world, moving people from {insert favorite language} to Clojure/Script is a tough sell if they’re not already curious and/or haven’t already run into many of the problems that Clojure/Script aims to solve – and as you, yourself, have already noted: some of the problems already have “solutions” in the JS world to some degree (immutable data structures, functional programming, hot code reloading, a “REPL”) – and that makes it even harder to persuade some people that ClojureScript is a radically better choice than JS.
We get that you’re enthusiastic (and new here, even if you may not be new to the Clojure/Script world at large). We get that you want more people to use your favorite language. Just don’t be upset at the measured response you get here when you come in “all guns blazing”, okay?
15 Likes
Okay. (Seriously, sorry if I rubbed anyone the wrong way 
)
2 Likes
I think everyone started defensive. Clojure devs often have to deal with JVM bashers. And Node devs often have to deal with JS bashers as well. So we got in a double defensive.
In reality, both platforms are quite similar. They both are running state of the art VMs, and have a great solid set of standard APIs and can run on multiple target OS and architectures. Yet, they both suffer from having a lowest common denominator default programming language that is good enough so it remains, but not good enough for a lot of people to enjoy coding in.
In both cases, Clojure recognises the solid foundation, and swoops in to provide a language that brings those unsatisfied with Java or JS the joy and simplicity they’d wished for.
One thing that seems important to the core maintainers is to be sure that Clojure doesn’t become a Kotlin or a Coffeescript. Its not meant as a better Java or a better JS. It has an identity unique to itself, and happens to leverage existing platforms in a commensalism relationship.
I think this is the vision for Clojure, and it kind of stand opposed to the idea that ClojureScript would be future of Clojure. Similarly, saying that Clojure JVM Would be the future of Clojure is also on opposite. Core maintainers consider other hosted platforms in their design. For example, adding the clojure.string namespace and some other core functions to better support portability accross hosts.
In ClojureScript land, there are a lot of JS devs asking for ClojureScript to make design choices that would not be portable to other platforms and would not be a good fit, but would help with JS interop or be more familiar, like adding async/await for example. And maybe those will happen, but my point is, if you consider the future to be portable and supporting multiple key platforms to give it the broadest reach, then these things must be done in ways that doesn’t harm that goal, and that’s extra challenging.
And I totally get it. This is kind of what happens when you take refugees from other languages. Even in JVM Clojure, these debates happens, lots of people want support for functional interfaces for example and better interop. Its problems unique to being a hosted language as well. Better tooling, more integrated tooling, keep up with the host, etc.
Hum, kind of lost track of my point lol, I think I’m just saying, it’s harder then it looks, and everyone tends to get defensive, because as someone trying to use Clojure[Script] you’re already going against the grain and having to defend yourself all the time.
So back on point. I am still interested in hearing like, what could be better? For example, I don’t think there’s anything missing for full on server side ClojureScript except someone with the will to do it. No Clojure dev will have that will, because they don’t have the desire for it. So I think it needs to come from JS expats mostly, who love Node, and really want to push ClojureScript usage for it.
5 Likes
I think this is an excellent point, and I think the comments I made earlier about the “community” (as nebulous as that is) missed that nuance, and I apologize to those understood my intention to be that Clojure/JVM should be replaced by ClojureScript, which I don’t believe to be the case. Only that I’d like to think there is opportunity for growth on the ClojureScript side of things.
You’re absolutely right @didibus, that any push for ClojureScript on the server would have to come from JavaScript/Node.js users/expats, so, perhaps, I should be looking at myself in the mirror.
2 Likes
This became a thing when the industry shifted away from monolithic servers and towards Dockerized micro services. Also, for throwing together REST APIs, you can’t beat Node. JSON is the de-facto data format now and what better language to deal with JavaScript Object Notation than JavaScript? As monolithic servers are being broken up into smaller pieces, very few are sticking with the JVM. The parts are being done primarily in Node or Python.
Regarding threads, people are moving away from those. As servers are becoming small and specialized, the need for threads is decreasing. Async has replaced threading. There are plenty of benchmarks where Node scales just as well as, if not better than, JVM languages.
So what’s the barrier to getting Node developers to use ClojureScript? Mainly that there’s no pain point that it solves. JS is very Lisp-y, albeit with a lot of weird quirks. JS developers are used to the quirks, though. My first impression of Common Lisp, for example, was “this is like JS without the stupid.” When writing CLJS, I sometimes forget which language I’m using because it’s basically the same as writing JS.
There’s also the formatting issue. When people talk about “all those parenthesis” with Lisp, they’re really talking about the tradition of stacking the close parens. For people who are used to traditional languages, that’s a major annoyance that isn’t worth dealing with.
I think Clojure has made more of a dent in JVM land than CLJS would make in the JS world. I like CLJS and think it should continue, but I don’t think it’s at a point where it should be the primary focus. Give it another 5 or 10 years, though, and it’ll rise in importance as the JVM fazes out.
4 Likes
Another point with regards to the popularity argument - you’re more likely to see an explosion in the FE bubble than you are in backend/general programming areas.
Clojure was designed to be general purpose, pragmatic, and for experience developers. There’s something to be said for JS’s ease of adoption. Shall we look at its experience distribution vs. other languages? Not to mention the ecosystem with things like leftPad and isEven.
Maybe I’m just being a dinosaur about it.
1 Like