3 ms·
The "holy grail" architecture whereby the first request sends a fully formed HTML response which is then immediately hydrated with a JS frontend app that takes
by Wintamute 11y ago
The "holy grail" architecture whereby the first request sends a fully formed HTML response which is then immediately hydrated with a JS frontend app that takes over routing and data gathering is now pretty technically feasible. It's the best of all worlds ... fast static content for the first load, and then fast frontend routing thereafter. If you ward your clients away from this path you're doing them a disservice. With this stack JS web apps no longer need to be app-like, they're well suited to content-heavy sites too. They even work with JS turned off :)
- madeofpalk 11y ago> pretty technically feasible Not only feasible, it's extremely easy to do these days with things like React (+Redux). We're about to launch a fairly large project for an Australian broadcaster using this approach and it's been incredibly simple to do. And there's nothing ~magic~ that React does to make this possible - it would be quite trivial to 'roll your own' framework for this. Best of all, you could start with doing it just server-side and then roll out the JS to 'the other side' later on.
- sotojuan 11y agoSeems like Ember is working towards this: https://github.com/tildeio/ember-cli-fastboot https://github.com/tildeio/ember-cli-fastboot
- terda12 11y agoYeah, the cool thing about React is that its fairly pluggable. So stuff like server side rendering is not "React" specific but more so Node specific.
- terda12 11y agoSeems like its what Redux/React is doing at the moment with server side rendering http://rackt.org/redux/docs/recipes/ServerRendering.html http://rackt.org/redux/docs/recipes/ServerRendering.html On server request, render the first snapshot of a React app into pure HTML and send it out, and then that HTML snapshot uses a script tag to get the actual JS file of the react app.