5 ms·

> Its killer feature is that the same code can run on the client and the server It's a feature in search of a problem. Nobody is rushing to replicate this, bec

by jack9 11y ago

> Its killer feature is that the same code can run on the client and the server It's a feature in search of a problem. Nobody is rushing to replicate this, because it's difficult to leverage. There are few languages that do not have a way to parse json and are all easier to maintain.

plorkyeran 11y ago
Pre-rendering SPAs on the server is rather nice and there's several frameworks which cover the hard parts for you, but there's also no great downside to using node.js for just that and writing the rest of the backend in some other language.
- eropple 11y ago
  This is pretty much where I'm at. I've always rolled my eyes a bit at node.js, but a current client is using it to render SPAs and I don't think I mind that at all. For my own stuff I'd do the heavy lifting in Rails or on the JVM (depending on my needs), but I am truly sold on React/Webpack for that.
vectorpush 11y ago
> It's a feature in search of a problem I very much disagree. Using react and webpack I can render my views on the client and the server using the same code and using react-router I can even share the routing code unmodified on both ends. Having a fully powered SPA that cleanly falls back to server rendering for crawlers and no-script clients is pretty sweet, in my experience.
- verbin217 11y ago
  This has been my experience. To the extant that I'm trying to embed Javascript everywhere now. Many server-side operations are deterministic and only need to be executed on the server because it's a trusted environment. They can be executed "optimistically" on the client if you have the same information and a compatible runtime. It makes everything feel snappier and enables a practical programming model. A single state transition function for each "action" performs the immediate client update and triggers validated server persistence in parallel. Without a ubiquitous execution environment that's like four/five times as hard.
deleted 11y ago
[deleted]

by jack9 11y ago

plorkyeran 11y ago

Pre-rendering SPAs on the server is rather nice and there's several frameworks which cover the hard parts for you, but there's also no great downside to using node.js for just that and writing the rest of the backend in some other language.

eropple 11y ago
This is pretty much where I'm at. I've always rolled my eyes a bit at node.js, but a current client is using it to render SPAs and I don't think I mind that at all. For my own stuff I'd do the heavy lifting in Rails or on the JVM (depending on my needs), but I am truly sold on React/Webpack for that.

vectorpush 11y ago

> It's a feature in search of a problem I very much disagree. Using react and webpack I can render my views on the client and the server using the same code and using react-router I can even share the routing code unmodified on both ends. Having a fully powered SPA that cleanly falls back to server rendering for crawlers and no-script clients is pretty sweet, in my experience.

verbin217 11y ago
This has been my experience. To the extant that I'm trying to embed Javascript everywhere now. Many server-side operations are deterministic and only need to be executed on the server because it's a trusted environment. They can be executed "optimistically" on the client if you have the same information and a compatible runtime. It makes everything feel snappier and enables a practical programming model. A single state transition function for each "action" performs the immediate client update and triggers validated server persistence in parallel. Without a ubiquitous execution environment that's like four/five times as hard.

deleted 11y ago

[deleted]