Il mondo dello sviluppo web ha trascorso gran parte di un decennio a convincersi che il browser dovesse occuparsi del lavoro pesante. Siamo partiti da documenti e moduli, per poi migrare costantemente ogni operazione immaginabile verso il client. Routing, gestione dello stato, data fetching, logica di rendering, persino l'orchestrazione delle query al database tramite GraphQL — tutto si è spostato in bundle JavaScript che diventavano sempre più pesanti a ogni rilascio. I framework si sono moltiplicati, le pipeline di build si sono complicate e ciò che era iniziato come un modo per rendere le app più reattive si è trasformato in un'architettura in cui una pagina non poteva renderizzare un singolo pixel significativo finché megabyte di codice non fossero stati scaricati, analizzati ed eseguiti.
Quel cambiamento ha risolto problemi reali. Le pagine renderizzate sul server con un pizzico di jQuery facevano fatica a offrire le transizioni fluide e simili a un'app che gli utenti si aspettavano. Le Single Page Application ci hanno dato navigazione istantanea, stato persistente e interazioni ricche. Ma il costo si è accumulato. Oggi i team gestiscono complessi store di stato lato client, lottano con enormi bundle JavaScript, mantengono delicati livelli di sincronizzazione dei dati e effettuano il debug di pipeline di build che a volte sembrano un lavoro a tempo pieno a sé stante. Abbiamo scambiato un set di problemi con un altro, e molti sviluppatori si stanno chiedendo se ogni applicazione debba effettivamente pagare quella tassa.
Due sviluppi stanno rendendo questa domanda più facile da rispondere.
HTMX e il ritorno dell'hypermedia
Il primo è HTMX. In superficie sembra una piccola libreria, ma le sue implicazioni architettoniche sono enormi. HTMX tratta l'HTML come il formato nativo per la logica applicativa, invece di considerarlo come un guscio statico che deve essere "gonfiato" da JavaScript.
Ecco cosa cambia in pratica. Tradizionalmente, quando un utente clicca su un pulsante per caricare altri commenti, il frontend invia una richiesta fetch, riceve un payload JSON, lo normalizza in uno store lato client, lo passa attraverso un template di un componente, esegue il diff del virtual DOM e infine applica le modifiche alla pagina. HTMX interrompe questa catena. Il pulsante stesso contiene attributi che dicono al browser dove inviare la richiesta e quale elemento della pagina sostituire. Il server restituisce un frammento HTML — solo i nuovi commenti, racchiusi in un div. Il browser lo sostituisce. Non c'è JSON, non c'è un albero di stato del frontend, non c'è un algoritmo di riconciliazione e non c'è JavaScript imperativo per mantenere l'interfaccia utente sincronizzata con il server.
Questo non è un rifiuto dello sviluppo moderno. È un rifiuto dell'astrazione non necessaria. HTMX dimostra che l'hypermedia, lo stile architettonico che ha alimentato il web delle origini, può ancora supportare interfacce sofisticate se abbinato a un'ergonomia moderna. Qualsiasi elemento può emettere richieste, non solo moduli e link. Qualsiasi evento può innescare un aggiornamento. Il server rimane la fonte di verità sia per i dati che per la presentazione.
Gli aggiornamenti parziali dichiarativi di Chrome
Il secondo cambiamento è più recente e risiede all'interno del browser stesso. Chrome sta introducendo gli "Declarative Partial Updates", o DPU. Questa funzionalità consente al browser di ricevere in streaming l'HTML e di inserirlo direttamente nelle parti mirate di una pagina man mano che arrivano i byte.
Prima di DPU, se si voleva trasmettere dati in tempo reale in una pagina web, si ricorreva generalmente a WebSockets, Server-Sent Events o long-polling abbinati alla manipolazione manuale del DOM. Il frontend doveva gestire la connessione, analizzare il payload e decidere esattamente come e dove iniettare il markup. DPU cambia l'equazione rendendo il processo dichiarativo. Lo sviluppatore specifica un contenitore di destinazione e il browser si occupa del resto: ricevere lo stream, analizzare il frammento e posizionarlo esattamente dove deve stare, anche prima che la risposta completa venga chiusa.
Pensate a una dashboard di monitoraggio che mostra i log del server o a una coda di supporto che si aggiorna in tempo reale. Con DPU, il backend invia frammenti di HTML semplice man mano che vengono generati. Il browser li trasmette in un corpo tabella o in un contenitore di feed senza una singola riga di logica di streaming lato client. L'assemblaggio avviene nativamente.
Il modello Server-First
Mettendo insieme HTMX e DPU, si ottiene un'architettura coerente in cui il server possiede lo stato e genera l'interfaccia utente, mentre il browser gestisce la visualizzazione e l'input dell'utente. I framework backend come Rails, Laravel, Django, i template Go o ASP.NET tornano a essere lo strato di interfaccia primario. Il frontend non è un'applicazione separata che consuma un'API. È l'interfaccia hypermedia prodotta dal server.
This model fits a surprisingly wide slice of software. Consider the typical SaaS application. It is dashboards with sortable tables. It is admin panels with forms and filters. It is internal tools that move records from one state to another. It is CRUD workflows that show a list, expose a detail view, and let the user edit fields. It is even AI interfaces where a language model streams tokens back to the user, and each token or paragraph can be wrapped in HTML and appended to the conversation thread. For all of these, a thick JavaScript client is often overkill.
The benefits are immediate and practical. Initial page loads are faster because the first meaningful paint arrives as HTML, not after a hydration cycle completes. JavaScript payloads shrink because there is no virtual DOM, no client-side router, and no state management library to ship. Search engines see complete content without executing bundles, so SEO works by default. Complexity drops because one codebase handles routing, business logic, and rendering. Debugging gets easier. When something looks wrong, you inspect the Network tab and see exactly what HTML the server sent. There is no opaque client-side state object to reverse-engineer.
What About React and Heavy Clients?
None of this means React is dead, or that SPAs are a mistake. Complex, editor-grade applications still need a thick client. Figma runs a C++ engine compiled to WebAssembly inside the browser because server round-trips would make drawing impossible. Canva manipulates the canvas at sixty frames per second with client-side geometry. Google Docs uses operational transforms to resolve editing conflicts in milliseconds. These tools are essentially desktop applications delivered through a browser tab. They are not going back to server-rendered forms.
But most software is not Figma. Most software is not a real-time graphics editor. Most software is a reporting screen, a configuration panel, a booking flow, or a content management form. For that long tail of applications, shipping hundreds of kilobytes of JavaScript framework just to toggle a modal or fetch a list of records never made much sense. The economics of the stack are shifting. We are rediscovering that the server can be close to the user thanks to the edge, and that the browser itself has grown capable enough to update fragments without a framework intermediating every byte.
The Pendulum Finds a Balance
The arc of web architecture is swinging back toward simplicity, but it is not a naive return to the nineties. The browser is becoming smarter. Features like DPU do not replace developer ingenuity; they absorb the patterns we used to implement by hand — streaming, partial updates, targeted DOM insertion — into the platform itself. HTMX gives us the vocabulary to express those behaviors without reconstructing a miniature operating system in the frontend.
You no longer have to choose between a simple architecture and a responsive user experience. You can have both. The server can drive the interface, the browser can assemble it, and the JavaScript you write can focus on genuine interactivity rather than plumbing.
For the next generation of dashboards, admin tools, and AI-powered interfaces, the smartest client might be the one that does less.