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.
-
-
Replying to @samccone
> 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.
3 replies 0 retweets 29 likes -
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.
2 replies 0 retweets 11 likes -
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
3 replies 0 retweets 16 likes -
-
Replying to @samccone @joshuaisgross
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
4 replies 0 retweets 27 likes -
Replying to @sebmck @joshuaisgross
Sounds like a great idea Calling
@cramforce
1 reply 0 retweets 4 likes -
I think that running JavaScript on the server for server side rendering is the right approach.
2 replies 0 retweets 18 likes
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 likehttps://developers.google.com/closure/templates/ …
1 reply 0 retweets 3 likes - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
he/him 
