You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've had a proper node renderer for quite some time for React on Rails Pro.
It's becoming increasingly useful to use NodeJS and not ExecJS for server-side rendering. Here are a few reasons:
loadable-components and CSS in JS Emotionjust work when using a proper node server and a build target of node (and not web). I suspect many other libraries are the same in this regard.
Better for memory management
Maybe better performance (and certainly if your Ruby process is running out of memory due to JS leaks)
Options to debug using the Chrome dev tools.
Ability to have SSR code read the file system, make asynch calls, and really anything a proper node program can do.
If there was sufficient interest, I could look into a port of the renderer that worked for react-rails.
The text was updated successfully, but these errors were encountered:
I would like to see a proper node renderer for react-rails. For my own project's SSR engine, I've forked https://github.com/jhawthorn/execjs-fastnode (which runs node as an external process but doesn't launch a new process on each render like the default exec-js node renderer) and added some more error handling / logging / integration with react-rails, but I would certainly welcome a more supported node runtime rather than the one I hacked together 😝.
Generally I've seen way better performance using miniracer than NodeJS as an ExecJS backend.
I'd be curious to see a benchmark for using NodeJS direct rather than ExecJS as I'm unclear what effect that would have. I'd imagine it would be more similar to when you run the webpack dev server.
Primarily I suspect 1 and 5 would be the most interesting use cases for other folks as some issues are because people coming from pure Node don't have clear paths to making things compatible. 2 and 3 are less interesting I think as I've never personally had issues with memory even on larger deployments of React-Rails.
If you're willing to put in the work it could be interesting.
I've had a proper node renderer for quite some time for React on Rails Pro.
It's becoming increasingly useful to use NodeJS and not ExecJS for server-side rendering. Here are a few reasons:
node
(and notweb
). I suspect many other libraries are the same in this regard.If there was sufficient interest, I could look into a port of the renderer that worked for react-rails.
The text was updated successfully, but these errors were encountered: