Should the future of Clojure be ClojureScript?

Community Center Watercooler
41

My expectation is that the JVM will be just fine and microservices will be “dead”.

Node popularity might even go down. I has pretty much peaked. It is a terrible platform to write anything on that requires doing actual work. It is OK if you basically just transfer IO from one place to another (eg. REST APIs). As CPU core counts go up the scaling of node becomes worse since you need separate isolated processes to use them. Those can’t share memory so you end up using way more resources than a typical JVM process would.

People have been proclaiming the death of Java and the JVM for decades but it doesn’t seem to be happening anytime soon. JS isn’t going anywhere either but its role on the server will go down over time. Maybe WASM will take its place.

7 Likes
42

I don’t really see the JVM going anywhere either, but as for “microservices”, its such a loaded term.

I agree that the “mircoservice” as a “service so small it can be rewritten in 2 weeks” should die (as the tradeoff in operational overhead is just far too great… who want’s to manage 1000s of them?), but the “microservice” as an “application constrained to serve a single particular business function or domain”? That should still be around (the system that manages financial transactions shouldn’t also be sending out marketing emails after all).

So long as JS remains dominant in the browser, I think it will be popular on the server. Node.js came about to make server-side development easy (in the Rich Hickey sense of “near at hand”). All those JS developers creating new single-page apps needed to start creating APIs to serve up the data. Node.js really exists in a very different space than something more general purpose like the JVM or .Net. I think its there to bridge the gap between “serious” back-end systems and the end user, and I think it does an OK job of doing that (warts and all).

I am definitely awaiting the rise of WASM though. Maybe that is the actual long term target for Clojure?

1 Like
43

My own experience after trying to do a backend with cljs/node is that I switched back to clojure/JVM on the backend :wink:

One strength of clojure is that it allows you to write code for these different environments JVM/Node/Browser in the ‘same’ language … I used to be a full stack dev writing python/Django on the backend and JS on the frontend (long ago) and my brain would melt because of the constant switches between those two. I don’t have the same problem when I switch from clojure to cljs/browser or from cljs/node to cljs/browser …

It’s a bit dishonest to say that cljs on frontend and backend is the same thing because these are very different environments

Just my 2 cents …

2 Likes
44

A few more remarks :
I think that the whole discussion is a bit pointless, NodeJS and the JVM do not try to be the same thing and they do not really compete with each other … I would never do a compute intensive task on nodejs or a small IO script with clojure (even thou there is babashka for that now). So both can co-exist in peace.

@thheller You made is so much more easy to work on cljs, especially with node modules, with shadow-cljs, Great work and thanks dude!

Finally, even Ryan Dahl said that NodeJS has many flaws, especially security-wise. And he has been working on Deno to try to fix that, Deno seems promising and the fact that it has a compiler approach first (typescript) might be a good fit to have “native” clojurescript support in Deno (eventually)

Video of Ryan Dahl about the flaws of Nodejs
Deno main website

1 Like
45

We’ll have to see. I don’t see monolithic servers ever making a comeback.

It’s only been around for 2 decades. Death proclamations have only been for one. :slight_smile: I agree the JVM will stick around, but it will be a COBOL or Fortran type situation. It’ll always have a place, but not the place it currently has.

I don’t see WASM surviving. The only thing it gets you at this point is being able to write your code in other languages. It had some hope back when it had a performance edge over JS, but now that JS has a JIT that advantage is gone.

46

True. I’m sure they’ll be around just fine just a bit more moderated.

Of couse JS devs will naturally look for node (or maybe deno) since they don’t have another choice. We do.

This is exactly why Clojure + ClojureScript is so fantastic and also why I haven’t looked for something else since adopting it. Previously in my career I always had one language on the server and one on the client. Be that Java + JS, PHP + JS, Perl + JS or whatever. Now I can enjoy the same language and even get to choose whichever host platform is best suited for the Job. Sure there are still differences but so much less than before.

FWIW I’ll try to be less dismissive about node on the server in the future. It does have its place even if its just to slowly lure people over to Clojure that are at first scared of it. :wink:

We’ll see. Still very early and missing a lot of important pieces. The WASM I’m talking about is not the WASM that is available today. WASI and other efforts first need to stabilize and be widely available.

2 Likes
47

I agree, and I also believe the JVM is a better choice for most server-side scenarios, and one that I would probably choose… when given the choice. Which is where my original impetus for starting this topic came from.

I see many large (non-tech) organizations (my own included) that are moving toward Node.js for new development, for much the same reason that Java was used in the past. Not necessarily because its technically better than the alternatives, but because its easy to find new, young, “full-stack” JavaScript developers.

I wonder if there is growth potential there for ClojureScript? Similar to the classic “sneaking Clojure in because its just another jar file”. If given the option, will there be JavaScript developers who start writing ClojureScript on the server, because “its just another js file”?

I’d like to think the answer is yes, but there is validity in what @Richard_Heller said:

My main issue is that JavaScript is a kitchen sink language that tries to be everything to everyone (object-oriented, prototype-based, functional, and procedural!), and I’d like to see more JavaScript developers adopt ClojureScript so they don’t have to worry about 10 different ways to accomplish the same task.

Many JS developers seem happy with that though, because it allows them to write code in a very individualistic way… Which can make for some very hodge-podgy codebases. At least with the surge in TypeScript popularity, the hodge-podge is “strongly typed”.

3 Likes
48

I suspect serverless might eat Node’s pie in the future. And when it comes to the future of micro-services, I also imagine serverless to be it. Though there’s a chance Node also position itself as the defacto serverless run-time, that would be a great move for it.

I’m also getting the feel that typescript will probably be a nice jumping ground for JS devs to move away from JS and into Java, Kotlin, C# and Go. I think for any dev going full backend, that can be a logical transition. You’re now one step closer, and the jump becomes much easier. That might actually hurt Clojure[Script] adoption actually, as more people are being evangelized in the school of simple type systems.

JS will probably remain very popular, for the same reason that PHP is still one of the most popular language around. Its just easy to get into, and really accessible.

From my experience, and granted I guess I come from the generation just before Node? Where we still learned Java in school. So the devs I know are also of that generation. A lot of them actually avoid jobs with NodeJS backend. At least the traditional backend devs. The more modern full stack dev, which has come to the backend from a website building beginning isn’t as opposed to it. This is just my observation in the Seattle area.

And let’s not forget about C#. Their new blazer tech is prone to take over all enterprise front-end work in my opinion. They already have a stronghold on the small to medium backend enterprise. I suspect that might leave Node more in the consumer space and maybe the SAAS space. As big enterprise continues with Java and small and medium adopts even more C#.

Its hard to predict these things. What I wonder is where that leaves Clojure. For me, the answer is probably that Clojure will forever be a niche. And that works for me, we can just move to whatever platform is most popular next, just like it went from Java to Javascript, is now making a move towards .Net Core, etc.

1 Like
49

I’m not sure I agree with that anymore. “Most server-side” seems to mean REST at this point. I stopped applying for Java jobs because they’re all Spring based and I can’t stand Spring. Given that “server” is meaning “REST server” more and more, I don’t think the JVM is necessarily the best choice. Python and Node are much better glue languages. When you look at companies that have scaled to massive size, there’s no clear winner as to languages. Some use Java, some Node, some Python, etc. I don’t think the language matters much. The Python community might actually be right with their mantra that developer speed is more important than processing speed. Use whatever language your developers work fastest in and go with it.

That’s an interesting one. I think it still has the Microsoft stigma to it which means Linux shops avoid it. I like the language, it has a lot going for it, but I’ve yet to come across it at any job. I know .NET Core now runs on Linux, but I think it’s being used more by people going from Windows to Linux and it’s not something the Linux people have shown much interest in.

50

Just to provide a data point here.

As someone with JS background and no JVM knowledge, I had the same thought before. I wished we could just use clojurescript on top of JS and didn’t have to deal the jvm at all. But I gave up on that thought.

Maybe, there’s no better between Node and JVM. Even if there is, maybe it doesn’t matter. What matters is the people and their knowledge and familiarity with them.

Even if JVM is absolutely better than NodeJS for server side programming, so what? For whatever historical reason, I already know something of Node but nothing of JVM, so I will do my server side programming on Node.

I totally understand why the replies are one-sided:
Clojure is a hosted language, and requires people to know and embrace JVM. I believe ALL the big voices in the community already know JVM well. They likely knew JVM well before using Clojure.

Even if JS is dominant, or becoming the future, so what? For people who know JVM well already, they naturally don’t feel the burden anymore, and it’s impossible for them to abandon all the time and energy they have invested in it.

2 Likes
51

I’ve been managing teams doing Clojure development since late 2008 in 3 different companies (and with mostly the same core group of great Clojure devs). All the previous efforts were primarily backend. It was all great.

Just about all the folks on our Dev teams had little interest in Clojurescript but more to the point, interest in doing frontend work. Some of this was chauvinism; “Frontend isn’t real development”, etc and some was just personal interest.

Over the years, I dipped my toes (well fingers) into doing actual Clojure / Clojurescript development several times, always loved the language, but didn’t really do much with it personally and had found Clojurescript hard to do anything practical with primarily due to it being very difficult to Interop with JS / node libraries.

Several months ago, we had a need to do some spikes with UI oriented stuff. Since the real devs were both busy and not particularly interested, I checked in to the Clojurescript state of the art and discovered @thheller’s shadow-cljs. This made the Clojurescript so much more usable than in the past with its easy integration of npm libraries among other things.

The ability to leverage NPM libraries in Clojurescript almost as easily as Java libraries in Clojure, made developing with Clojurescript really really fun and powerful!

I was able to do one Clojurescript project building Chrome Extensions (with a little help from the community) and a proof of concept Clojurescript protoytpe that integrated with AWS Amplify for authentication of a webapp.

Recently our company had to pivot to survive in the Age of Coronavirus with a totally new service that is UI centric. Myself and two other Devs (well mostly the two other devs) built a sophisticated Live Streaming ecommerce app on top of AWS Amplify / App Sync serverless architecture all in Clojurescript / Reagent / Re-frame / react-bootstrap, with Lambdas in Clojure->GraalVM in about 2 months. We still have a lot to learn about UI/UX and the formally backend devs now have a lot more respect for folks who do frontend work!

My point in terms of this thread is; The JVM is not the big issue of Clojurescript becoming more popular among JS AND Clojure devs. There may be a non language platform bias / comfort of backend development and frontend development. I’ve seen that in my own teams. In general I find devs tend to settle in particular layers of the stack they work in.

Whats more important to advance Clojurescript adoption, is to continue to rapidly improve the ease of use and interop of Clojurescript with the JS/NPM ecosystem.

There already was a huge leap in usability / interop of Clojurescript and the NPM ecosystem with shadow-cljs. Many Clojure Devs might not be aware of this if the last time they played with Clojurescript was in the days of Cljsjs

IMHO: The next big leap will be when there is a step improvement in the interop with React (and in particular React hooks)

Clojurescript doesn’t replace Clojure, it extends Clojure Superpowers into UI. I hope more Clojurians join in the fun and help to build the full stack Clojure[script] ecosystem.

5 Likes
52

That’s totally acceptable to leverage your existing knowledge, it’s smart even. Though I want to say, it’s really not that effortful to learn the JVM. Like I’d say at most it’s a 2 month ramp up time. And really in a week you can learn enough to get going. Just saying it as an encouragement to dip your toes in, if you’re interested. I know it looks doubting at first.

This is true, but it is also where certain people (like me) have grown a disdain for the JS/Node ecosystem. People trying to make this better are well aware of how messy and broken the JS world of modules and dependencies is, and that makes this task painful and difficult. So you’ll literally hear from the mouth of those working towards this a lot of complaint about it as well lol. But I think it’ll get there eventually, though it won’t until JavaScript itself stabilises in this area to be honest.

And in fairness to JS, a browser target does make it difficult to have something stable and practical, so I also understand why it’s in the state it is in.

I’ve only done ClojureScript as a hobby, but isn’t this available now? When using Rum, I didn’t feel like anything from React was missing, it even supports hooks. And I think there’s a few libs now specially designed to work with hooks like Hx.

2 Likes
53

Will JavaScript take over the world? Probably not.

2 Likes
54

Agreed. My company looked at cljs back when Reagent had just appeared (early 2014). We built a proof of concept in Om and then rebuilt it in Reagent. It was a fairly painful experience in many ways so we decided not to pursue cljs at that time (and a while later we hired some JS devs and they built an all-new front end for our platform using React.js / Redux / Immutable.js etc).

When I switched from ProtoREPL in Atom to Chlorine (late 2018 I think?), I did some hacking on Chlorine itself which is developed with Shadow-cljs and it was a huge improvement over the tooling that we used to have.

Even so, the fact that ClojureScript is a compile-to-JS language means you have a chunk of config/workflow that is specific to compilation – something that isn’t present in the Clojure/JVM world – so the workflow and the tooling is always going to be harder to work with, regardless of whether you’re targeting the browser or Node.js.

I see what my JS colleagues have to deal with, just using JS alone, and it’s so much more complicated than the ecosystem I deal with on a day-to-day basis using the JVM. Knowing both systems is why I would never choose to develop on Node.js, even with cljs helping avoid most of the awfulness of JS :slight_smile:

5 Likes
55

Yes, Helix (replacement of hx), Uix, Rum and some exciting new things going on in Reagent with Function Components / Hiccup Compiler changes that allow for easy access to React Hooks are what I was implying as the exciting bits!

2 Likes
56

It’s true that the JS/Node/Browser world is crazy. But its also amazing what is being accomplished. But again, I think the issue is more Backend Folks vs Frontend Folks. UI has always been insane, complex and sucky tools. Also the main consumer of UI are funky Humans, whereas Backend the consumer is primarily logical computers.

In general, I much prefer logical computers, but there is a thrill in making a UI work past all the craziness. Like right now I’m depressed because its so hard to make a scrollable div always show new text at the bottom of the div. But the thrill of victory when its done is unmeasurable :laughing:

3 Likes
57

Not so sure about that. I’ve largely been a generalist, in recent years often working throughout the stack for mobile apps. Last year though I did some work involving a bunch of Spring Boot and node/aws stuff. I was only passingly familiar with either, so there was a fair bit of study needed on my part. For all the magic and bureaucratic verbosity of Spring, I’ll take it over node/npm/webpack et al any day. What a horror show of accidental complexity the latter is - little of this having much to do with UI per se.

2 Likes
58

Ya I’m also not sure about this. I’ve done front-end desktop development, things like QT, Java Swing, WPF, Flash and Silverlight.

The dependency issues and challenges come from the browser space in my opinion, being a competitive environment, vendors took a long time to play along, and you always need something that can work with the browsers. And that prevented a lot of normal evolution. People competed for JS standards heavily, creating many standards that now need to be reconciled.

I think another issue is how far web UIs have gone compared to what the initial design of the web thought it would become. Now with SPAs, we’re very far from static HTML/CSS with a little bit of interactivity from JS. So it’s grown really fast, and in ways that weren’t really planned for.

Only recent JS UI toolkits like React, Vue, Angular, etc., I think are starting to rival the traditional front-end environmentz, by bringing back grid layouts, UI components, etc. Before that, it was really hard to build a proper reusable and extendable UI toolkit. And even now, you have the competition at play, with some toolkit being built over React, others Vue, etc.

Before that, the web didn’t really have a UX toolkit, it was mostly text and images in tables, with forms as input.

While I say all this, I like where things are ending up. In some way, this competition also pushed forward the innovation. Some desktop toolkit with their OOP and imperative heavy design are showing archaic in comparison. And the renderers and interactivity that web browsers has achieved is really impressive, with a push for resolution independence, vectorize graphics, GPU acceleration, support for screen readers and all that. So in the end, I think it’ll end up better, and already is showing signs, which is why some people now are bringing the web UI kits to the desktop. That said, the road is rough, and full of breaking changes and competing standards.

Oh, and not to forget, UI toolkits didn’t used to need to be bundled with each view. People would get their app delivered to them through a download/install, a CD ROM, etc. Or the OS would have the toolkit pre-installed. So the whole complexities around bundling and bundle size is another thing that makes web front-end way more challenging.

2 Likes
59

Yep, agree with all that. In some ways I think the Front/Back end distinction is largely an artifact of the complexity (accidental & intrinsic) of web UI tech.

Totally - for all the implementation complexities involved, web UIs are clearly going to dominate. My inner GUI power user occasionally complains, but overall it’s a good thing.

60

I think it also has influences on my mind being a JavaScript developers for years. Even with help of TypeScript, programming UI with virtual DOM is still a lot like “scripting”(besides templating and styling). I say “scripting” since it can be quite different from “programming”. I see my friend post their code in Rust, TypeScript, Haskell and some of the code are like controlling all the details before code is executed. While doing “scripting”, I don’t have every detail in control, I do trying and fast iterating again and again.

With this in mind, Node.js turned out to be quite a nice tool for scripting. And with help of ClojureScript, It hot replaces running code as I save file, functions got updated without breaking any connections(like WebSockets). That’s quite handy. I don’t do much server-side programming so I’m not sure how backend people really think about this. But probably there are a lots of reason choosing JVM for the purpose of “programming”.

1 Like