Native CSS transitions have quietly killed the strongest argument for client-side routing. Yet people keep building terrible apps instead of performant websites.
Because re-fetching data that the client already has is wasteful.
from your point of view. From the point of view of a user with a device with <2gb of memory I guarantee they think your app is being incredibly wasteful. For users that have a bunch of tabs open I guarantee they think your app is being incredibly wasteful. Multiply that by how many users you have and I guarantee you’re wasting much much much more energy than you’re saving, because you’ve now distributed your wasteful habits across all your users rather than your singular server or kubernetes cluster or whatever you’re running.
Nothing that goes over the wire is ever instantaneous. Even if I hit the cache, then I’d still have a round-trip to confirm that.
you can cache with localstorage, or cookies, or at the cdn layer, or a thousand different solutions. You’re thinking very narrowly.
For the apps I develop, latency is usually about 20ms. So you’re assuming that (given 1 million instructions per second, which is on the very low end) an SPA would need more than 20 million instructions to switch context?
latency is 20ms on your machine. A developer machine, most likely running on a fiber connection, maybe ethernet, not mobile or mobile hotspot.
It’s also probably running with that latency with next to 0 tabs open, likely measured with a profiler turned on that frees up memory from the rest of your tabs to make sure to run with clean measurement.
Because it is the frontend’s responsibility to display data, not the backend’s. The backend will, for instance, only store the customer’s birthday, but users might be interested in their age. It is not the backend’s responsibility to mangle the data and swap out the birthday for their age. …
this has nothing to do with being an SPA. You can do the same with simple javascript.
If I weren’t writing an SPA, then showing the expected cost for buying a product would require displaying a form (that was always there, but hidden via CSS) and having the user enter the product. Then they’d send off that form (refreshing the page in the process, which means downloading 90% unchanged HTML again for no reason). This refresh cannot even be sensibly cached or prefetched, because there are over 200 products to choose from. Confirming the booking would refresh the page again (though this time prefetching is an option).
no it wouldn’t. You’re confusing “SPA” with “no javascript”. You have plenty of options that do not require 50mb of javascript that still allow all of the features you’re listing here.
Also notice that the backend had to render a <select> with 200 options just in case the user wanted to book a product. How would you facilitate searching this on a static page? Refresh the page again each time the user presses a button?
yeah it’s very clear you have confused “static” with “no javascript”. My own personal website is static. It has javascript. “Static” != “no javascript” and “No SPA” != “static”.
If the user wants to go back to the customer list, pick a different customer, and do the same process again, we’re at 4 more requests that only download data the client should already have.
no it wouldn’t. Your browser already knows how to cache this, it occurs on almost every request you make every day on non-SPA websites.
The client downloads the instructions on how to draw the customer list, and the customer data. Then the client downloads the instructions on how to draw the customer details (without all the forms, because most of them won’t be needed, which saves bandwidth).
except you’ve now downloaded 50mb of data that the user isn’t using. They simply needed the customer data and for it to be displayed and selectable.
I am not really gonna respond to the rest of your message, because I read over it and it’s more misunderstanding what an SPA is and what a ‘normal’ website might do (hint: you can use all the normal web technologies and still not be an SPA, including things like WS, SSE, AJAX, whatever you want).
Thanks for the response though, it really did help me understand why so many developers continually choose SPAs over just building a normal website.
from your point of view. From the point of view of a user with a device with <2gb of memory I guarantee they think your app is being incredibly wasteful. For users that have a bunch of tabs open I guarantee they think your app is being incredibly wasteful. Multiply that by how many users you have and I guarantee you’re wasting much much much more energy than you’re saving, because you’ve now distributed your wasteful habits across all your users rather than your singular server or kubernetes cluster or whatever you’re running.
you can cache with localstorage, or cookies, or at the cdn layer, or a thousand different solutions. You’re thinking very narrowly.
latency is 20ms on your machine. A developer machine, most likely running on a fiber connection, maybe ethernet, not mobile or mobile hotspot.
It’s also probably running with that latency with next to 0 tabs open, likely measured with a profiler turned on that frees up memory from the rest of your tabs to make sure to run with clean measurement.
this has nothing to do with being an SPA. You can do the same with simple javascript.
no it wouldn’t. You’re confusing “SPA” with “no javascript”. You have plenty of options that do not require 50mb of javascript that still allow all of the features you’re listing here.
yeah it’s very clear you have confused “static” with “no javascript”. My own personal website is static. It has javascript. “Static” != “no javascript” and “No SPA” != “static”.
no it wouldn’t. Your browser already knows how to cache this, it occurs on almost every request you make every day on non-SPA websites.
except you’ve now downloaded 50mb of data that the user isn’t using. They simply needed the customer data and for it to be displayed and selectable.
I am not really gonna respond to the rest of your message, because I read over it and it’s more misunderstanding what an SPA is and what a ‘normal’ website might do (hint: you can use all the normal web technologies and still not be an SPA, including things like WS, SSE, AJAX, whatever you want).
Thanks for the response though, it really did help me understand why so many developers continually choose SPAs over just building a normal website.