React Server Side Rendering with GraalVM for Clojure
nextjournal.com
nextjournal.com
> GraalVM's polyglot abilities to load the JavaScript artifact from the ClojureScript app into the Clojure JVM and directly call the function with almost no overhead
I think Clojure is uniquely positioned here in its ability to fuse these JS<->JVM technologies using a single language and, in this instance, fully supplant the need for nodejs. Very impressive!
Why? Aren't there a lot of other languages that do the same? What is different about Clojure? Genuinely interested!
There was briefly (now deleted) a response to fulafel's comment which essentially pointed out how JavaScript itself should be considered a production-quality language that is up to the task. After all, JavaScript can also now be used to build JVM applications thanks to GraalJS ...except I wouldn't bet on that technology direction gaining much traction at this point in time (unless maybe Oracle has a trick up its sleeve).
It's super helpful for shared libraries. A lot of our code can be shared between JVM servers, JS lambdas, or JS frontend code without much development effort. It's mostly just a matter of naming a file .cljc and you're off to the races.
So is graal polyglot already compatible with newer JDKs and it's just native image generation that's blocking the upgrade? https://github.com/oracle/graal/issues/651
We are working with a very high priority on JDK 11 support. We should be able to ship it in a few months from now.
> So is graal polyglot already compatible with newer JDKs and it's just native image generation that's blocking the upgrade?
Not just. We also need to upgrade the JVMCI version we use in order to support libgraal (Graal compiler as native-image in HotSpot). Also, modules make everything a little bit more complicated as well.
Now, the benefit of using the best tool for the job, and separating concerns (the API and the React server renderer can be deployed, logged & scaled independently) far outweighs the overhead of managing and connecting several different runtimes, because that's trivial with k8s.
The only slight advantage I can think of is loading data on server renders 'in-process' and not having to go via http, though I emphasise slight as this is certainly not a bottleneck and not something I worry about at all frankly.
I think this is cool, and I get that Clojure + Clojurescript add another reason to pair these things together and perhaps this is quite a Clojure-specific thing, but just wondering if anyone would pick this over running separate JVM + node services in k8s or similar (assuming that's an option)?
At Nextjournal, it won't stop with server side rendering. For example we're using ProseMirror as the rich text editor in the browser. For real-time collaboration on notebooks, we want to use ProseMirrors out of the box support for it: http://prosemirror.net/docs/guide/#collab
This means our server has to provide the "central authority". This leaves us again with the choice of:
1) expose this central authority in a nodejs service via http to our Clojure/JVM app (which manages also the websocket connections and database persistence) 2) rewrite the central authority and applying the transformation functions in Clojure/Java and maintain compatibility with the Javascript implementation 3) leverage the polyglot abilities from GraalVM to just call ProseMirror's transformation functions from our Clojure code
Here, 3) seems to be the obvious choice, as throughput is much higher than for occasional server side rendering and the http overhead for the nodejs-service approach would be a deal breaker.
The idea of server-side rendering is fascinating. With correct abstraction, there's no extra code required for every component at all. And there's no more ad-hoc client-side script in order to rescue back-end HTML anymore.
It's just annoying currently it's only easier on Node.js until WASM decades arrives.
So no, you don't need to worry from the only company that cared about saving Java.
I worked with Clojure for about a month. Then I decided to go back to NodeJS.
- I have no need to java or JVM.
- The Clojure stack traces aren't easily decipherable
- One doesn't need Clojure for functional, immutable programming. NodeJS is flexible & has a massive community with tons of packages, including ones for immutable work. Functional programming on the other hand is simple-- just create & use JS functions (in the context of JS that is).
- Ultimately I saw no need for Clojure
What I do see though, is a small group of outspoken activists pushing clojure.
Now, why don't I want to use it, besides what I've written above?
Another contributor to my dislike of the language/"community" is the founder's stance-- Rich Hickey in this commentary "Open Source is not about you" https://www.reddit.com/r/Clojure/comments/a0pjq9/rich_hickey...
Clojure is owned by Cognitect. Any changes to be made must be (very slowly or not at all) approved by Rich Hickey. This is a language with a development/expansion/growth bottleneck of one person.
This particular person considers the language his property-- which it is, he created it after all.
But once I realized this, I immediately moved back to the NodeJS & Python communities.
Also, Clojure libraries are mostly abandoned. Clojure's heyday seemed to be around 2005-2013 or so. Sure, you can find a couple recent ones like Reagent (for ReactJS rendering) which is a few versions behind ReactJS.
After working with it though, I saw no real benefit over simply using ReactJS directly. In fact, I found it cumbersome to have to work through two potential layers of errors: ClojureScript & Javascript.
Now we just see activists trying to pump it up in the news. I'd rather read about the interesting new things happening with JS and Python.
TL;DR; After working at a company with Clojure & ClojureScript, I realized that:
1. It's practically closed source
2. Most of its packages are abandoned
3. There is a small vocal group of folks pushing it... despite the fact that the community leaders seem to have (and claim to have) no interest in the community that has grown around the language.
4. Personally, I'd rather work with React directly than some transpiled language on top of it (which I have no use/need for, given that I have no use/need for java)
This means I benefit from a lot of the things that are going on in JavaScript and Java land over time like improvements in runtimes and libraries. Being able to use React from ClojureScript or being able to use GraalVM is actually a good example for this.
I do think that onboarding and figuring out what went wrong and why when you run into errors could be smoother. That said a lot of community effort is going into this recently.
In hindsight I wish I had looked into Clojure earlier.
Clojure is not "owned" by Cognitect, it's an open-source language. In a sense it's as much "owned" as Rust is owned by Mozilla, C# by MSFT and Golang by Google. Yes, changes to the core ultimately do need to be approved by Rich Hickey and that's not necessarily a bad thing. Clojure's stability is something of a legend. In no other language ecosystem you can update things with such impunity. Where other languages start crumbling under their own weight, Clojure over the years stayed true to its core principles - it's predictable, moving from one major version to another won't cost you weeks of your time. I don't know where you get the notion of Clojure libraries being abandoned. Just because people not coming up with yet another front-end framework every couple of weeks?
I bet you just don't know Javascript to the point (or haven't worked on large enough projects) when it starts feeling very tiresome. Clojurescript offers multitude of tools to make it easier. That's why dev surveys like StackOverflow and State of JS show that Clojure is mainly chosen by more experienced programmers.
Frankly, even one full month of working with any language is not enough to learn its idioms and become comfortable with it. You didn't like - it's fine, you have your own reasons. There are people who do like it and you're struggling to understand why. No, they are not fanatics, they are pragmatists. For example: whenever I need to write code in any language and for whatever reason it cannot be Clojure - I would first do my prototyping in Clojure and then translate it to the other language. Even doing that I'm still much more faster.
Maybe you’ve never heard about Clojure, but it’s had a huge impact on you how program front-ends regardless.
Redux, immutable data, time travel debugging, hot reloading — all of this has been inspired by the Clojure community.
Yes you can fork it, but good luck getting the money that Google pours into it.
1. Wrong
2. There’s a difference between “abandoned” and “done”.
3. About 83% wrong*
4. OK
* The group is indeed small in relative terms
I have not run across any Clojure libraries I wanted to use that were "abandoned". I've found some that have a low version number (< 1.0) and haven't had any commits in the past couple years, but that's because they do everything they set out to do, and have no (reported) bugs. I wish other ecosystems were this stable.
I'm not sure exactly what complaint 3 is about. Is it that the leaders of a project aren't doing a good job of marketing and positioning, and don't understand their users? The first release of Linux was "just a hobby, won't be big and professional", and warning it "is NOT portable" and "probably never will support anything other than AT-harddisks". Python was developed for the Tanenbaum's Amoeba OS. If we use that as our barometer of a valid open source project, I don't think any project in the world is going to be judged suitable.
The word "transpiled" seems to only exist so people can make fun of other programming languages. (Similarly, calling its users "outspoken activists".) Your JavaScript has a virtual machine, too. Are you suggesting it's better because it lacks an explicitly specified bytecode?