> Multi-page applications are slow to load and navigate.
A bit tired to see this...
No it's not. We do this all the time. It's as simple as using proper HTTP headers for your css/js/pictures/whatever. You can even have smooth page transitions now.
A bit tired to see this...
No it's not. We do this all the time. It's as simple as using proper HTTP headers for your css/js/pictures/whatever. You can even have smooth page transitions now.
Multi-page applications are slow if you load in 20 libraries from 10 different CDNs, a page tracking system, a click tracking system, a "performance metrics" system, a chat bot overlay, an advertising platform, all the crap loaded by the ad intermediate, all the crap loaded by the ad itself, an ad "traffic quality" montor, a Stripe.com thing (even though this isn't a payment page), something from Facebook, something else from fbcdn...
The author is reinforcing the false dichotomy between using front end frameworks and hand-rolled JS, as if rendering data from JSON APIs is the only way to display information from the server.
Almost as an aside, he says
> Server Side Rendering is also no better, because while they can do certain things in more straightforward way, they break browser behaviour [...]
but he provides no examples or supporting evidence, so it's difficult to know what browser behaviour he's referencing. "SSR" is just how the web has worked since the beginning and it works very well. Maybe he's specifically talking about SSR as provided by Next? I've never used it, so I'm not sure what browser behaviour it might be breaking.
But yes the web has evolved since then and the HTTP protocol has newer versions and most apps don't serve as many users as Facebook.