2 ms·
> how much interactivity there is on the page Yes, and also how much interactivity is better served by a thick browser-based client than by a round-trip to the
by runako 4y ago
> how much interactivity there is on the page
Yes, and also how much interactivity is better served by a thick browser-based client than by a round-trip to the datacenter. In practice, many Web applications we encounter daily have relatively low interactivity (where something like Google Maps or the Spotify Web player score as "high"). And then they are implemented using thick frameworks that are frequently slower than a round-trip to a server for re-rendering the entire page was even as far back as 10 or 20 years ago.
Your extreme examples, plus applications like Figma, are absolutely places where I would expect to see thick client-side Javascript. However, most Web applications that we encounter frequently are more like e-commerce, blogs, recipe websites, brochureware sites, landing pages and the like that absolutely are primarily about presenting information. Using thick browser clients is a sub-optimization for most of those Web uses.
- nicoburns 4y ago> However, most Web applications that we encounter frequently are more like e-commerce, blogs, recipe websites, brochureware sites, landing pages and the like that absolutely are primarily about presenting information. Using thick browser clients is a sub-optimization for most of those Web uses. I mean sure (although I'd probably make a distinction in the terminology and call those websites as opposed to web applications). I don't see many of those kind of websites using client side rendering though. I think the grey area is sites like Gmail which do have quite a bit of interactivity but would also be workable with SSR. Personally I think they're generally better using CSR. If done badly as the current gmail is then it makes things slow, but if done well (like the older gmail!) then it's faster.