3 ms·
> SPAs are always heavier than their response/query counterparts Heavier by what metric? Initial load size? Sure. But the static assets will be cached after th
by RussianCow 9y ago
> SPAs are always heavier than their response/query counterparts
Heavier by what metric? Initial load size? Sure. But the static assets will be cached after the first page load, after which an SPA should definitely be faster than a traditional server-side web app given that a) less data is sent over the wire for each page load (you don't need to re-send headers/footers, JSON is usually smaller than HTML, you can implement intelligent caching strategies, etc), and b) only a part of the page is re-rendered, rather than the entire thing every time. So "heavier" really depends on what you're optimizing for.
- reaperducer 9y ago> Heavier by what metric? I measure by the amount of data sent to the client to accomplish a task. I keep a very close eye on this because it's part of my POP (proof of performance) reports each month. Don't forget that plain query/response caches many static assets, too.
- RussianCow 9y agoSure, but what about responsiveness and other metrics? Reducing the absolute amount of data sent over the wire may be what you are optimizing for, but it's not by any means the absolute metric of performance. Personally, as a user, for many web apps I would rather see a longer initial page load but have all subsequent actions appear instantaneous (a la Gmail), than spread the load times out across every action. My point isn't that SPAs are better than traditional web apps or anything like that, just that these decisions depend entirely on what you are optimizing for and what your priorities are. If initial page load time is your priority, then an SPA may not be the way to go; however, if your goal is to maximize responsiveness or interactivity, then the extra 2MB of JS will likely pay off.