3 ms·
A proper fully clientside rendered website gives a much better user experience. Yes you need a strong clientside framework able to render components, maintain s
by holoduke 6y ago
A proper fully clientside rendered website gives a much better user experience. Yes you need a strong clientside framework able to render components, maintain state, history etc. Once the application is loaded, the only data communication between server and client is JSON or some other format. Much more efficient in bandwidth and speed.
Another plus is that you can actually have multi platform versions of the application with the look and feel of the target platform. Good luck to get that feeling with a 800ms delay serverside rendered page.
The main reason why you shouldn't do it, is because of SEO. Dynamic sites are considered weak in SEO. Very challenging to get them properly indexed by Google etc.
You also got still a lot of engineers who somehow favour the serverside rendering.
For inhouse internal apps or b2b apps I would always prefer a clientside app.
- satyrnein 6y agoFor internal and b2b apps, what matters most is development velocity to be able to churn through a million unmet needs the fastest way possible, much more do than shaving off a few hundred milliseconds off the response time. On this metric, I don't think SPAs win.
- Spivak 6y agoThe problem with this take is that browsers are really good and downloading and displaying static (to the browser) content which is the basis of server-side hydration. SSR is almost always going to be faster but it will beat the crap out of your servers depending on how dynamic the pages are.
- rcxdude 6y agoI agree in theory but in practice SPAs chug on initial loading and they chug on loading new content (and they often even chug when scrolling this content!). the experience of using many websites increased drastically with javascript disabled. Something is clearly wrong with current SPA practice if this is the consistent result that users see.