The web development world spent the better part of a decade convincing itself that the browser should do the heavy lifting. We started with documents and forms, then steadily migrated every conceivable operation to the client. Routing, state management, data fetching, rendering logic, even database query orchestration through GraphQL — it all moved into JavaScript bundles that grew heavier with each release. Frameworks multiplied, build pipelines deepened, and what began as a way to make apps feel snappy turned into an architecture where a page could not render a single meaningful pixel until megabytes of code had been downloaded, parsed, and executed.
That shift solved real problems. Server-rendered pages with a sprinkle of jQuery struggled to deliver the smooth, app-like transitions users expected. Single Page Applications gave us instant navigation, persistent state, and rich interactions. But the cost accumulated. Teams now manage complex client-side state stores, wrangle massive JavaScript bundles, maintain finicky data synchronization layers, and debug build pipelines that sometimes feel like their own full-time job. We traded one set of problems for another, and many developers are now asking whether every application needs to pay that tax.
Two developments are making that question easier to answer.
HTMX and the Return of Hypermedia
The first is HTMX. On the surface, it looks like a small library, but its architectural implication is large. HTMX treats HTML as the native format for application logic instead of treating it as a static shell that must be inflated by JavaScript.
Here is what changes in practice. Traditionally, when a user clicks a button to load more comments, the frontend fires a fetch request, receives a JSON payload, normalizes it into a client-side store, runs it through a component template, diffsthe virtual DOM, and finally patches the page. HTMX short-circuits that chain. The button itself contains attributes that tell the browser where to send the request and which page element to replace. The server returns an HTML fragment — just the new comments, wrapped in a div. The browser swaps it in. There is no JSON, no frontend state tree, no reconciliation algorithm, and no imperative JavaScript to keep the UI in sync with the server.
This is not a rejection of modern development. It is a rejection of unnecessary abstraction. HTMX proves that hypermedia, the architectural style that powered the early web, can still support sophisticated interfaces when paired with modern ergonomics. Any element can issue requests, not just forms and links. Any event can trigger an update. The server remains the source of truth for both data and presentation.
Chrome’s Declarative Partial Updates
The second shift is newer and lives inside the browser itself. Chrome is introducing Declarative Partial Updates, or DPU. This feature allows a browser to stream HTML and insert it directly into targeted parts of a page as the bytes arrive.
Before DPU, if you wanted to stream live data into a web page, you generally reached for WebSockets, Server-Sent Events, or long-polling paired with manual DOM manipulation. The frontend had to manage the connection, parse the payload, and decide exactly how and where to inject markup. DPU changes the equation by making the process declarative. The developer specifies a target container, and the browser handles the rest: receiving the stream, parsing the fragment, and placing it exactly where it belongs, even before the full response closes.
Think of a monitoring dashboard showing server logs or a support queue updating in real time. With DPU, the backend sends plain HTML chunks as they are generated. The browser streams them into a table body or a feed container without a single line of client-side streaming logic. The assembly happens natively.
The Server-First Model
Put HTMX and DPU together, and you get a coherent architecture where the server owns the state and generates the UI, while the browser handles display and user input. Backend frameworks like Rails, Laravel, Django, Go templates, or ASP.NET become the primary interface layer again. The frontend is not a separate application that consumes an API. It is the hypermedia interface the server produces.
Dieses Modell passt auf einen überraschend breiten Bereich von Software. Betrachten wir eine typische SaaS-Anwendung. Es sind Dashboards mit sortierbaren Tabellen. Es sind Admin-Panels mit Formularen und Filtern. Es sind interne Tools, die Datensätze von einem Zustand in einen anderen überführen. Es sind CRUD-Workflows, die eine Liste anzeigen, eine Detailansicht bereitstellen und es dem Benutzer ermöglichen, Felder zu bearbeiten. Es sind sogar KI-Schnittstellen, bei denen ein Sprachmodell Tokens an den Benutzer streamt und jedes Token oder jeder Absatz in HTML verpackt und an den Konversationsverlauf angehängt werden kann. Für all diese Fälle ist ein schwerfälliger JavaScript-Client oft übertrieben.
Die Vorteile sind unmittelbar und praktisch. Die ersten Seitenaufrufe sind schneller, da der „First Meaningful Paint“ als HTML ankommt und nicht erst, nachdem ein Hydrierungszyklus abgeschlossen wurde. Die JavaScript-Payloads schrumpfen, da kein virtuelles DOM, kein clientseitiger Router und keine State-Management-Library ausgeliefert werden muss. Suchmaschinen sehen den vollständigen Inhalt, ohne Bundles ausführen zu müssen, sodass SEO standardmäßig funktioniert. Die Komplexität sinkt, da eine einzige Codebasis das Routing, die Geschäftslogik und das Rendering übernimmt. Das Debugging wird einfacher. Wenn etwas falsch aussieht, inspiziert man den Network-Tab und sieht genau, welches HTML der Server gesendet hat. Es gibt kein undurchsichtiges clientseitiges State-Objekt, das man per Reverse Engineering entschlüsseln muss.
Was ist mit React und schweren Clients?
Nichts davon bedeutet, dass React tot ist oder dass SPAs ein Fehler sind. Komplexe Anwendungen auf Editor-Niveau benötigen nach wie vor einen Thick Client. Figma führt eine in WebAssembly kompilierte C++-Engine im Browser aus, da Server-Roundtrips das Zeichnen unmöglich machen würden. Canva manipuliert die Canvas mit sechzig Bildern pro Sekunde mittels clientseitiger Geometrie. Google Docs verwendet Operational Transforms, um Bearbeitungskonflikte in Millisekunden zu lösen. Diese Tools sind im Grunde Desktop-Anwendungen, die über einen Browser-Tab bereitgestellt werden. Sie werden nicht zu serverseitig gerenderten Formularen zurückkehren.
Aber die meisten Softwareanwendungen sind kein Figma. Die meisten Anwendungen sind keine Echtzeit-Grafikeditoren. Die meisten Anwendungen sind Reporting-Screens, Konfigurationspanels, Buchungsabläufe oder Content-Management-Formulare. Für diesen „Long Tail“ an Anwendungen hat es nie viel Sinn ergeben, hunderte Kilobyte an JavaScript-Framework auszuliefern, nur um ein Modal umzuschalten oder eine Liste von Datensätzen abzurufen. Die Wirtschaftlichkeit des Stacks verschiebt sich. Wir entdecken neu, dass der Server dank Edge Computing nah am Benutzer sein kann und dass der Browser selbst leistungsfähig genug geworden ist, um Fragmente zu aktualisieren, ohne dass ein Framework jeden einzelnen Byte vermittelt.
Das Pendel findet ein Gleichgewicht
Der Bogen der Web-Architektur schwingt zurück zur Einfachheit, aber es ist keine naive Rückkehr in die Neunzigerjahre. Der Browser wird intelligenter. Funktionen wie DPU ersetzen nicht den Einfallsreichtum der Entwickler; sie integrieren die Muster, die wir früher manuell implementiert haben – Streaming, partielle Updates, gezielte DOM-Einfügungen – direkt in die Plattform selbst. HTMX gibt uns das Vokabelvermögen, um diese Verhaltensweisen auszudrücken, ohne ein Miniatur-Betriebssystem im Frontend nachzubauen.
Man muss sich nicht mehr zwischen einer einfachen Architektur und einer reaktionsschnellen Benutzererfahrung entscheiden. Man kann beides haben. Der Server kann die Schnittstelle steuern, der Browser kann sie zusammenbauen, und das JavaScript, das Sie schreiben, kann sich auf echte Interaktivität konzentrieren, anstatt auf die reine Infrastruktur.
Für die nächste Generation von Dashboards, Admin-Tools und KI-gestützten Schnittstellen könnte der intelligenteste Client derjenige sein, der weniger tut.