Hacker News Reader

Comment by jack9 | Hacker News Reader

> 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.

View on HN

> 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.

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.

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.

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.

Reply on news.ycombinator.com