> Suddenly, sharing libraries and UI components between server and client went from science experiment to mainstream. You could have apps that were mostly serv

> Suddenly, sharing libraries and UI components between server and client went from science experiment to mainstream. You could have apps that were mostly server-rendered, but then that same code could instantly update the UI at runtime in the browser. Or apps that were mostly client-rendered, but later moved piecemeal to the server to improve performance. The holy grail of a unified codebase is now possible. Remember Meteor[0]? > ...but sometimes people ask, “What do you even need client-side rendering for nowadays?” I think it matters most for products where folks are actively getting work done, where you want things like optimistic updates, offline mode, rapid workflows, realtime collaboration, and lovely little animations that warm your users’ hearts The reality is that SPA is mostly a bane for the first three, unnecessary for the last one, and there's rarely need for realtime collaboration apart from a few specific workflow. Today the recommendation is to start as a monolith first, I'd love for people to start with server-rendered UI first. Not loading several libraries just to reimplement (badly) already existing browser features. It's disheartening when you see simple blog can't even show text without javascript. [0]: https://www.meteor.com/ https://www.meteor.com/