That rhymed lolz.
I mentioned on a podcast the other day that I sorta think WordPress should ship with Turbolinks. It’s a rather simple premise:
Build a server-rendered site.
Turbolinks intercepts clicks on same-origin links.
It uses AJAX for the HTML of the new page and replaces the current page with the new one.
In other words, turning a server-rendered app into “Single Page App” (SPA) by way of adding this library.
Why bother? It can be a little quicker. Full page refreshes can feel slow compared to an SPA. Turbolinks is kinda “old” technology, but it’s still perfectly useful. In fact, Starr Horne recently wrote a great blog post about migrating to it at Honeybadger:
Honeybadger isn’t a single page app, and it probably won’t ever be. SPAs just don’t make sense for our technical requirements. Take a look:
Our app is mostly about displaying pages of static information.
We crunch a lot of data to generate a single error report page.
We have a very small team of four developers, and so we want to keep our codebase as small and simple as possible.
That’s what I mean about WordPress. It’s very good that it’s server-rendered by default, but it could also benefit from SPA stuff with a simple approach like Turbolinks. You could always add it on your own though.
Just leaving your server-rendered site isn’t a terrible thing. If you keep the pages light and resources cached, you’re probably fine.
Chrome has started some new ideas:
“Paint Holding” reduces the white flash between page loads.
The “Portal” element will help transition from page-to-page without reload. Note the accessibility issues.
I don’t doubt this server-rendered but enhance-into-SPA is what has helped popularize approaches like Next and Gatsby.
Damned if you do. Damned if you don’t.
Fortunately, there is a spectrum of rendering choices for choosing an appropriate architecture.
That rhymed lolz.