Java 8 Nashorn for server-side rendering of react components?

(Maxime Najim) #1

Is anyone doing server-side rendering of react components in Java using the Java8 Nashorn JavaScript engine in production today? The general approach is outlines here:

(Mark Finger) #2

I don’t have any experience using React with Java/Nashorn, but similar principles apply to using it with any non-JS languages. You can run the renderer in a more stripped back JS engine (nashorn in this case), but you’ll hit a lot of integration issues (no commonjs support) and you’ll have to roll a lot of things yourself.

A standalone node process is a good starting point. If/when you hit perf issues, node’s cluster module gives you an escape hatch as you can spawn a worker farm that listens from a single address.

The little server that I usually dump into dev boxes is

(Maxime Najim) #3

Thank you @markfinger for the insight and for pointing us towards a valuable solution. We’ve come up with three options for doing server-side rendering of reactJS components in our Java front-end servers:

  1. Delegate execution of react to an external process running Node
  2. Have Node run as a smart-proxy in front of Java
  3. Run react on the JVM with Nashorn

The drawback of 1 and 2 is a more complicated deployment and a performance overhead of interacting with another nodeJS process from the JVM (extra request hop). As you mentioned, since Nashorn is only an implementation of the ECMAScript spec it will require extending the environment for doing things like isomorphic fetching, using promises, etc. for example:

I wanted to get a sense of how many folks have actually done option 3 (as opposed to running a standalone node process).

Thanks again.

(sthzg) #4

@maximenajim I also started searching for this in the past days and am currently experimenting to come up with a Spring Boot - React Starter Kit. Would you care sharing information in this thread if you find something interesting?

One of the biggest questions I have right now is about performance. Basically, a catch-all controller has to pass routing to react-router inside Nashorn. Router will then reply with the status code as well as the rendered body and the java controller will send the response. The initial state for flux stores is another concern that might be populated by both Java and Javascript.

Now in first tests that works, but it’s currently too slow (will look into that before going on with other issues). From what I’ve read one of the problems is that Nashorn is not thread-safe and thus the pre-compiled react can’t easily be shared across multiple threads (some ideas about perf in the link you’ve also posted).

[Update: as mentioned in the linked post once all workers have warmed up performance is good. With a small pooling solution the warmup-run should not affect end-users.]

FWIW, some of the links I find interesting in that context:

(Shendepu) #5

I successfully run react server-side rendering on Nashorn and performance is good for me. 40 requests per second on a Macbook Pro 4 core, SSD, JVM memory usage is around 1GB.

Check out more details on

(Bowling X) #6

I created for play-framework and scala Users.
The Library allows to render react on the server (including async render results). It also provides an sbt plugin with a convenient way to load assets.