> I can see that in terms of bandwidth, SPA can be more efficient then normal HTML page. But this makes a few assumption. First, that your JS package never changes. As soon as 1 character changes in your package, the cache is invalidated and the whole package needs to be downloaded.
Sure, but there's strategies against this, right? Generally, vendor and 3rd-party code doesn't change often, so minify and stick all that together. Then, you've got your core application code, which you attempt to keep as small and fast as possible.
I will say, I'm not as experienced as the author of this piece, but at the end of the day I feel like the author is making blanket-statements that honestly don't hold up to the reality of what users actually want. I think it also makes assumptions about your stack, and your resources- yes, if you've got incredibly fast, top of the line servers, server-side rendered pages are probably a better idea, as the time difference between a json payload and the page being rendered by the server is much smaller.
On the other hand, even a cheap rails(ie slow) server with a CDN handing off the client code can shove some JSON out no problem, and it can do it very fast, even the worst-off users usually only at 300ms for total receive time- a time which generally, is 100-200ms slower than your average server's render time of the page alone.
Furthermore, it lets you offload who is delivering said content- if a CDN is giving up all that Javascript, then the initial render times may actually not be that much slower than if it was server rendered.
----
I also get the feeling a lot of people are making the mistake right now of assuming that because there's been a lot of evolution in the frontend framework world in the past 2 years, that it also means we're hitting peak performance, which couldn't be further than the truth. Angular apparently(I'm going off of what I've seen many say about 1.0 in the post-2.0 world) completely bungled performance the first time around, but it'll be better next year. Ember is already well on its way to being fast, and by summer of next year is going to be blazing quick with all of the HTMLBars innovations.
I think we're barely getting started figuring out frontend frameworks. Even if right now it may not be the best idea for your personal use case, I'd check back once a year until the evolution slows down to make sure you don't end up regretting not jumping in.
Sure, but there's strategies against this, right? Generally, vendor and 3rd-party code doesn't change often, so minify and stick all that together. Then, you've got your core application code, which you attempt to keep as small and fast as possible.
I will say, I'm not as experienced as the author of this piece, but at the end of the day I feel like the author is making blanket-statements that honestly don't hold up to the reality of what users actually want. I think it also makes assumptions about your stack, and your resources- yes, if you've got incredibly fast, top of the line servers, server-side rendered pages are probably a better idea, as the time difference between a json payload and the page being rendered by the server is much smaller.
On the other hand, even a cheap rails(ie slow) server with a CDN handing off the client code can shove some JSON out no problem, and it can do it very fast, even the worst-off users usually only at 300ms for total receive time- a time which generally, is 100-200ms slower than your average server's render time of the page alone.
Furthermore, it lets you offload who is delivering said content- if a CDN is giving up all that Javascript, then the initial render times may actually not be that much slower than if it was server rendered.
----
I also get the feeling a lot of people are making the mistake right now of assuming that because there's been a lot of evolution in the frontend framework world in the past 2 years, that it also means we're hitting peak performance, which couldn't be further than the truth. Angular apparently(I'm going off of what I've seen many say about 1.0 in the post-2.0 world) completely bungled performance the first time around, but it'll be better next year. Ember is already well on its way to being fast, and by summer of next year is going to be blazing quick with all of the HTMLBars innovations.
I think we're barely getting started figuring out frontend frameworks. Even if right now it may not be the best idea for your personal use case, I'd check back once a year until the evolution slows down to make sure you don't end up regretting not jumping in.