I think we missed the boat -- the focus on fancy rendering rather than on the actual data/content set us back years in functionality and helped create free and for-pay walled gardens where actionable data stays server-side and rendering is forced upon us, rather than just having reasonable defaults and then having rendering (incl. multi-modal interaction, etc.) further guided by user-defined settings and heuristics. Even if data happens to be rendered client-side in an SPA, it's done though application-specific means. I suppose deep-learning based data-extraction from free-form pre- and post-rendered content will eventually make up for this, but at least part of that road may have been avoided -- and of course we're probably going to have to pay someone (one way or another) for the privilege of having the content un-rendered back into actionable data at scale...
That's not going to happen. It's much easier to open a model or sidesheet than use server side rendering. I imagine in future generations of frameworks and browsers, we will be able to do SPAs without the issues we currently see.
It had some good ideas, but that was the extent of it. Every iteration of the solution since then has agreed that streaming all application UI is always going to be janky and needless. It's a lot better to host the data on the server side and let the client handle visual rendering by itself.
I'm sure the data that FB and Google are delivering is far more expensive than rendering HTML would be. I am skeptical that server side rendering was a big enough bottleneck for them for that to be their primary motivation. I'm also skeptical that SPA frameworks would have been widely adopted by developers all over the world if they were just some conspiratorial plot by tech companies to save on CPU cycles.
It's a powerful argument. Defending client-side rendering here (or SPAs) is almost no-true-Scotsmanish. It is technically possible to do a good job, but it's almost never done. Yours and sangnoir's teams may care about performance and do actual software engineering - but it doesn't help me much when my bank doesn't do it, the places I shop don't do this, big sites like Reddit don't do this, and seemingly none of the SPAs I've visited in the past 5 years do it.
Yeah, I mean my point was that this is an article that is the first glimmer into the future: server side browser rendering. I hope that's not our future :(
He also doesn't cover the high interaction problems of server-side rendering. If you have a website that isn't a SPA but has a really complex form (for let's say a good reason). Making that server side can be incredibly complex for only fractions of a second in gains.
This is why you have to measure what your users actually experience and understand how they want to use your app. If you do, you learn that browser caching does not have the dramatic impact thick client proponents often assume and connections are similarly slower and less reliable. That produces unsatisfying experiences which are more memorable than the times where your app loads quickly.
> Having a client that could re-render based on dynamic data was vastly better than trying to find portals of HTML to re-render & send.
This can be true but again measurements will show it isn’t true far more than claimed in the SPA marketing materials. This is due to the reasons I mentioned in my original comment: if your SPA has to make a number of network calls to update the view with a modest amount of visible data, it’s probably going to lose compared to the same code running on a faster processor in a data center with a network path to the data which has greater bandwidth and 1-2 orders of magnitude lower latency.
The break-even point is going to depend on the type of application you have, how much data you need to touch, how well that can be cached locally or on a CDN, and where you run servers and their performance characteristics, and the usage patterns of your users.
This is why the hybrid approaches end up being most commonly successful: if you’re dogmatic about using one approach exclusively you’ll miss out on the optimizations which make sense for your users by trying to follow an approach designed for someone else in a different business.
Historically client-side rendering has been a big headache. Not sure if it's improved recently, but avid math bloggers and blog readers will remember the problems of the past decade.
I'm really curious why you say that? Certainly it seems to me there's enough downsides to client side rendering still that I can't see how it's that clear cut.
reply