However, when an application is built as an SPA when it doesn’t need to be, bad things happen to good people.
Heh, I hope more people understand this. It’d make my life (and many others) easier.
I do not have much experience with SPA, but my observation is that angular and similar frameworks look like they encourage that kind of development.
Turbolinks seems like an interesting hack, but is it really a noticeable improvement in modern browsers? It seems like it’s an optimization that could be kind of done behind the scenes by the browser anyway, no?
It seems like it’s an optimization that could be kind of done behind the scenes by the browser anyway, no?
Browsers could never do this because it would break the web. Pretty much all websites assume that the JS VM is thrown away upon navigation. This means that they’re writing JS with non-idempotent transformations, which would break completely if you applied Turbolinks-style navigation to them.
Feels like it on every site I’ve used it on. The initial request is the same, yeah, but you avoid all other requests for js, css, fonts (even if cached), re-parsing it all, and running most of the JS meant to run on load. Maybe if you don’t have very much js and css and you have caching set up perfectly you wouldn’t notice much.
In short, adopting Turbolinks is the client-side mirror of switching from CGI to a persistent process on the server.
It prevents the user from looking at a white page while their content loads, but otherwise all of the overhead is still there since they’re using HTTP and are sending whole HTML pages around.
Not all the overhead - it doesn’t have to run scripts through the interpreter again, for example. In my experience content pages do seem snappier with turbolinks.
[Comment removed by author]
How else would you implement it without browser support? FWIW, Turbolinks degrades pretty gracefully. The player they have won’t work, but if you’re just making pages snappier it’ll just revert to normal page loads.