
React Server Side Rendering with GraalVM for Clojure - tosh
https://nextjournal.com/kommen/react-server-side-rendering-with-graalvm-for-clojure
======
refset
> we switched our production JVM to GraalVM, which opened a new possibility
> since it comes with GraalJS, a JavaScript engine which aims to compete with
> today's faster JavaScript engines like V8 and JavaScriptCore on performance.
> It lets us embed the ClojureScript app into our Clojure app so it can
> perform the rendering in-process in the JVM

> 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!

~~~
chrisjc
> I think Clojure is uniquely positioned here in its ability to fuse these
> JS<->JVM technologies using a single language

Why? Aren't there a lot of other languages that do the same? What is different
about Clojure? Genuinely interested!

~~~
fulafel
Few languages can run the same code on both JS and JVM. Of those Clojure is
probably the most production-quality.

~~~
chrisseaton
More production quality than JS itself?

------
pron
Note that you aren't tied to Java 8, which is quite old by now, but can also
run GraalJS with OpenJDK 11, 12, 13, and enjoy the recent performance
improvements to the GC (using ZGC or Shenandoah) and startup time (using
Application CDS):

[https://github.com/graalvm/graal-js-jdk11-maven-
demo](https://github.com/graalvm/graal-js-jdk11-maven-demo)

~~~
kvlr
Ah nice, we do want to switch Nextjournal to Shenandoah eventually after
reading [http://clojure-goes-fast.com/blog/shenandoah-in-
production/](http://clojure-goes-fast.com/blog/shenandoah-in-production/)

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](https://github.com/oracle/graal/issues/651)

~~~
grashalm
Graal-dev here,

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.

------
davnicwil
The prospect of doing React server rendering within the JVM, rather than in
node, used to be a lot more attractive to me before I switched to
containerizing my apps, specifically with kubernetes.

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)?

~~~
kommen
Hi, I'm the author of the post.

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](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.

~~~
davnicwil
Ah, ok, really interesting thanks. With this type of deep integration &
communication needed between the two, I can see why running everything in the
same JVM is a better solution.

------
namelosw
Great to see this, as I'm leaning the Fulcro/Pathom.

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.

------
codenut
I want to try GraalVM and use in my side project. But whats holding me back is
that its from Oracle. Is that something that I should be worry of?

~~~
yogthos
GraalVM has a community edition that's fully open source. There's nothing more
to worry about there than with any other open source project.

------
pdub1
I've noticed HackerNews has a lot of Clojure activists posting.

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...](https://www.reddit.com/r/Clojure/comments/a0pjq9/rich_hickey_open_source_is_not_about_you/)

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)

~~~
ken
"Practically closed source" is a funny way to say "open source".

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?

