It perplexes me how every modern web framework that supports server side rendering couples itself to a node runtime. The reality is most companies cannot simply add a node runtime to their production environment.

Why not? I’ve never heard this

I’m super curious. Maybe a gap in realizing _all_ server runtimes could in theory be used to piece together the output - and just starting from “our framework is JS so in order to SSR evaluate it you need to evaluate JS using our framework”?

> most companies cannot simply add a node runtime to their production environment. A lot of companies are already running Node so the integration is trivial. I think you're extrapolating to big companies though with complicated release processes.

Also there's nothing in (at least React's) server-side renderer that requires a Node runtime. You could run it in any JavaScript engine.

I assume the original tweet means not just Node but s/node/server-side JavaScript environment/. If your whole server stack is in Java or C++ or whatever it's probably nontrivial to add some JS engine into the mix

☝️

Sounds like Google should show us all how it's done and open-source their JS front-end framework with a runtime-agnostic (or just Java) render backend then 😉

Sounds like a great idea Calling @cramforce 🍍

I think that running JavaScript on the server for server side rendering is the right approach.

Yeah, it seems unavoidable unless you want multiple rendering implementations which doesn’t seem very desirable. Also impossible to pick a single language that everyone runs on the backend. JS seems close enough.

The common way is to use a more reduced language that can be executed in multiple environments like

The "Why?" section returns a 404 😅 developers.google.com/closure/templa…

The gap between right and practical is not something that can be bridged in many cases. :)

Maybe many as in absolute but not many as in most. Those many will need to helps themselves. Mostly banks and other legacy corps. Companies like Google and Facebook can just run JavaScript.

*cough* Dockerfile with Rendertron *cough*

That sounds like it would use a lot of electricity but sounds reasonable if you can't link to C++. I'd run a V8 that supports gRPC as it's only IO.

Worse Is Better (TM) (or so I've been told)

I read just your tweet and thought, "how does Bitcoin provide an alternative to C++?"

The React SSR API works fine in Java Nashorn last I checked. It probably works on any of a number of JS-on-.NET CLR implementations, too.

Totally

Is something like this what you had in mind github.com/google/closure… ?

Node uses C++ engine (i.e. v8), so adding C++ JS runtime to a C++ project shouldn't be an issue. Java used to have Nashorn (deprecated in JDK 11, though), and I guess the current way to go in Java would be GraalVM+graaljs.

What's the alternative?

I have the same question. Are frameworks supposed to provide reference implementations in other languages to allow SSR?

My best guess: Build it in another language and compile to WASM... ...and then run it on Node?

You can server render Vue on other envs, though it requires a bit more work. ssr.vuejs.org/guide/non-node…

TIL looks awesome!!

Glad you find it useful! I also saw github.com/samtgarson/vue…, although it relies on node, it still lets you build rails apps and just enhance it with Vue, while having full server-side rendering. Could potentially also use a Ruby JS interpreter like therubyracer.

Well, most companies think innovation is an afterthought. Which their failure to adapt their business to new technologies only create more opportunities for their competition to capitalize. These aren't restrictions, it's leadership failure.

Same.

One simply does not just add a node runtime to their production environment.

A path that could be considered is a component model where only the template is required to render on the server - which then can be translated to any language. And the actual JS component code attaches itself on the client. Otherwise you need some JS engine on the server.

Angular is in a better position to do this but still requires a change in how developers think of components.

What would be the benefits?

You can render HTML in any way you see fit on the server and then let the front end rebuild the virtual DOM from that. I've done it with Vue, and I imagine it's perfectly possible with React and other libraries.

Oh man tell to me about the perils of trying to do SSR in Nashorn... Lot of teams hesitate to put in an additional layer just to do SSR... An idea I've been trying to propose is explore using cloud functions to at least reduce infra headache

Every modern framework that supports server side rendering offers using the one language to define components and their logic as a feature. No need to redo the components twice like it was done before Node (e.g. server PHP + browser JS).

And even if they could they may not want to. Debugging a production node instance is a hell of a lot harder than something in Java or .NET due to lacking tooling.

yes 🙌🙌🙌🙌🙌🙌

[one cannot simply meme gif]

I don't see why they can't simply add a node runtime to their production environment unless they don't own it or something. But I'd be interested in the performance boost (or lack thereof) of doing SSR in a compiled language vs Node.

The web, node.js and frameworks: some of the best things in life! In other words, enjoy your evening, and or day, or evening, or day, Man! Day 3, of #100DaysOfCode,#100xcode 'Taking a break. Tweeting with people online. ,#javascript,#html,#css,#definitive,#codenewbie,#coding,

So I recently tried out Nuxtjs and generate static HTML ahead of time. Then serve the rendered stuff with a CDN. That gave me a pretty good lighthouse score. I think doing something like that is a good starting point.

You don't need to "run" node to serve pages