Other Ways to SPAs

That rhymed, indeed!

Recently, I suggested on a podcast that WordPress could benefit from integrating Turbolinks. The concept is straightforward:

1. Leverage server-side rendering for the initial site build.
2. Turbolinks intercepts clicks on same-origin links.
3. It employs AJAX to fetch the HTML for new pages, replacing the current content without a full page reload.

Essentially, this transforms a server-rendered application into a Single Page Application (SPA) with minimal added complexity.

The advantage? Improved speed. Full page refreshes can be noticeably slower than SPA interactions. While Turbolinks is a relatively mature technology, it remains highly effective. Starr Horne's recent blog post on Honeybadger's migration to Turbolinks highlights this:

Honeybadger isn't an SPA, and likely never will be. SPAs don't align with our technical needs. Consider these factors:

• Our application primarily displays static information.
• We process significant data to generate individual error reports.
• Our small team of four developers prioritizes a concise, simple codebase.

... We've used a successful approach for years that offers SPA-like performance without the JavaScript overhead... the key is achieving SPA speed without the full SPA complexity.

This mirrors my point about WordPress. Its server-rendered default is excellent, but a simple enhancement like Turbolinks could boost performance. However, adding it remains optional.

Sticking solely with server-side rendering isn't inherently flawed. Lightweight pages and effective caching can mitigate performance issues.

Chrome's recent innovations are also relevant:

• "Paint Holding" minimizes the blank screen flash between page loads.
• The "Portal" element facilitates smoother transitions between pages without reloads. Accessibility considerations are crucial here.

This approach—server-side rendering enhanced with SPA-like features—likely contributed to the popularity of frameworks like Next.js and Gatsby.

However, let's not overlook the power of true SPAs. Network latency is often the primary website performance bottleneck. If an application is designed to transfer small data packets (instead of large HTML chunks), and efficiently re-renders minimal DOM elements, performance gains are significant. The caveat is that JavaScript itself can become a bottleneck.

The challenge lies in the trade-offs. A full SPA often eliminates server-side rendering, while "hydrating" a server-rendered app with SPA features can overload the main thread with JavaScript.

Fortunately, a range of rendering options allows for flexible architectural choices.

The above is the detailed content of Other Ways to SPAs. For more information, please follow other related articles on the PHP Chinese website!