Streaming Efficiency: SSE Compression

Real-time AI chat relies on Server-Sent Events (SSE) for token-by-token streaming. The two architectures differ not just in compression, but in the fundamental connection model: Hypermedia keeps a single persistent SSE stream open for the whole session, while the SPA opens a new streaming POST for every message turn. That difference compounds dramatically over a conversation: after 10 turns, Brotli on a persistent stream achieves a 58.5× compression ratio—turning a 29× raw-data disadvantage into a 2× transferred-data advantage.

Single Turn (Claude 4.5 Haiku, same prompt)

Multi-Turn Conversation (10 turns, identical prompts)

Worth being honest about what our PHP implementation actually does: every time the AI outputs a new word, it re-streams the entire message HTML fragment from scratch—not just the new token. Each chunk replaces the previous one in full. This is a deliberate simplicity choice, not a Datastar requirement: write the naive thing until you have a reason not to. It explains the 29× raw data gap. Despite that self-imposed inefficiency, the combination of Brotli on a persistent connection beats the SPA over 10 turns. The compression more than compensates for the naïve implementation.

The single-turn advantage (2.4×) already holds: Brotli’s 18.7× compression ratio turns a 7.8× raw-size disadvantage into a net win. The multi-turn advantage grows further: a persistent stream lets Brotli compress all turns together, exploiting the cross-turn repetition in the chat HTML that builds up as the conversation grows. After 10 turns Hypermedia transfers half the data of the SPA—even starting from an implementation that wastes 29× more bandwidth before compression.

² Next.js streaming POST responses (/chat) have no Content-Encoding header. Enabling compression middleware on the streaming route would partially close this gap, but the per-connection overhead and inability to share a Brotli dictionary across turns would remain.

The Economics of Simplicity

Technical metrics are interesting, but what do they mean for the business? Architecture decisions compound over time, affecting not just performance but development velocity, operational costs, and team productivity.

Features vs. Maintenance: Where Does Time Go?

Consider what 799 production dependencies mean in practice. Each dependency is a potential source of security vulnerabilities that need patching, breaking changes that need addressing, and compatibility issues that need debugging. With the JavaScript ecosystem’s rapid release cycles, a significant portion of development time goes to keeping the dependency tree healthy rather than building features.

The Hidden Cost of Complexity

Complex architectures don’t just slow down the application—they slow down the team. Every architectural layer adds cognitive load: developers must understand React’s reconciliation, Next.js’s rendering modes, the Vercel deployment model, and the interaction between client and server state. This knowledge takes time to acquire and maintain.

In contrast, a server-authoritative hypermedia architecture has one source of truth (the server), one rendering location (the server), and one deployment target (a simple process). New team members can become productive faster, and debugging follows a straightforward request-response model rather than tracing state through multiple layers.

When Simplicity Pays Off

The economic case for reduced complexity is strongest wherever time and money are finite—which is most projects. A small team without a dedicated DevOps engineer or front-end specialist simply cannot afford to babysit a 799-dependency graph. When a transitive package ships a breaking change, it isn’t an abstract inconvenience; it’s a half-day of unplanned work that displaces a feature. The leaner the dependency tree, the fewer of those interruptions accumulate.

For applications expected to live years rather than months, this dynamic becomes even more pronounced. Initial development costs are a one-time investment, but maintenance compounds indefinitely. Every major framework upgrade, every deprecated API, every shift in the JavaScript ecosystem adds to the running total. Fewer dependencies and a simpler mental model keep that cost manageable—and institutional knowledge stays relevant longer.

Hosting economics follow the same logic. Usage-based pricing can absorb a modest traffic spike and return a billing surprise that forces an architecture review you didn’t plan for. A predictable $20/year VPS doesn’t do that. The cost is known in advance, scales to the team’s budget, and keeps the focus on the product rather than on cloud spending dashboards.

Finally, there’s the audience itself. The total elimination of blocking time (0ms vs 780ms) and the 7.5× improvement in Time to Interactive aren’t benchmark curiosities—they determine whether a user on a mid-range phone with a patchy connection actually gets to use the product, or abandons it in the first ten seconds.

When to Choose What

Architecture decisions should be driven by requirements, not trends. Here’s a framework for thinking about the tradeoffs:

Many applications don’t need the complexity of a full SPA. The question isn’t “which is better” but “which tradeoffs match your constraints.”