5 ms·

The trends to and from SPA are driven by improvements in "edge" service to support dynamic content: In the old days, we built dynamic web content with "AJAX".

The trends to and from SPA are driven by improvements in "edge" service to support dynamic content: In the old days, we built dynamic web content with "AJAX". There was a lot of latency to for a request to reach your application server. It was also kind of hard to make the servers respond with low latency. So we added more client-side scripting. We had things like script.aculo.us, and settled into jQuery. This improved the responsiveness of some aspects, but split the user's front-end experience across different systems, written in different languages, possibly developed by different people. So the SPA unified things again. It maximized the part of the application delivered by the low-latency CDN. Only the essential dynamic data was transferred from the higher-latency back-end server. It fixed the cohesion of front-end development, by moving entirely into JavaScipt frameworks. So, done well, this improved responsiveness for the user of dynamic web content. On the other hand, maximizing the SPA resulted in a new problem: users get slow or inconsistent performance because of downloading a big JavaScript application. So this new kind of load time turns out to be pretty hard to optimize. Now in 2023, it's easier to build low-latency back-end servers. We have various options of "edge compute". It's not too hard to put a copy of your application server in each region around the world. So it makes sense to run the application in the server again, not that it's distributed. Moreover, our web development frameworks are helping to keep the web application design cohesive. So moving to SPA and now moving away from SPA are driven by the desire to have a low-latency experience for our users. Changes in the available infrastructure have changed the optimal balance of server-side and client-side execution of the application. And improvements in our development frameworks makes it easier to take advantage of the infrastructure improvements.

slowmovintarget 3y ago
Nice summary. Add to this the need for greater security for some elements of the application, which often necessitate server-side activity, and you have a recipe for the current web app SotA.
gregwebs 3y ago
That's great when your data to render actually exists at the edge. Most the apps I have dealt with need to pull data from a centrally located database for almost every request. This edge setup would actually increase user latency whenever there are multiple DB queries per request (this is true of all requests if you have to query a DB to validate the user or their permission, although that can be avoided with a signed token approach). There's some potential advantage in using the cloud provider network after the edge, but it's already a known pattern to stick just a network proxy at the edge to gain the advantage of sending the rest of the request over the cloud provider network rather than sending it over the internet. Cloudflare has a query cache tool so that you can set a TTL on database read queries and keep them at the edge to avoid the DB latency [1]. I think though that you could develop a way to do that at an edge network proxy working at the request/response level rather than the DB level. But perhaps SSR is superior for apps that can show users stale data. [1] https://developers.cloudflare.com/hyperdrive/learning/how-hyperdrive-works/ https://developers.cloudflare.com/hyperdrive/learning/how-hy...
dwaltrip 3y ago
Hasn’t the need for interactive web apps with highly polished UX been equally if not more important?

slowmovintarget 3y ago

Nice summary. Add to this the need for greater security for some elements of the application, which often necessitate server-side activity, and you have a recipe for the current web app SotA.

gregwebs 3y ago

That's great when your data to render actually exists at the edge. Most the apps I have dealt with need to pull data from a centrally located database for almost every request. This edge setup would actually increase user latency whenever there are multiple DB queries per request (this is true of all requests if you have to query a DB to validate the user or their permission, although that can be avoided with a signed token approach). There's some potential advantage in using the cloud provider network after the edge, but it's already a known pattern to stick just a network proxy at the edge to gain the advantage of sending the rest of the request over the cloud provider network rather than sending it over the internet. Cloudflare has a query cache tool so that you can set a TTL on database read queries and keep them at the edge to avoid the DB latency [1]. I think though that you could develop a way to do that at an edge network proxy working at the request/response level rather than the DB level. But perhaps SSR is superior for apps that can show users stale data. [1] https://developers.cloudflare.com/hyperdrive/learning/how-hyperdrive-works/ https://developers.cloudflare.com/hyperdrive/learning/how-hy...

dwaltrip 3y ago

Hasn’t the need for interactive web apps with highly polished UX been equally if not more important?