Passa a:
htmx: l'alleato inatteso del backend moderno

htmx: l'alleato inatteso del backend moderno

Da qualche anno una libreria si è fatta strada quasi in silenzio, rivoluzionando il modo in cui intendiamo l’interazione tra browser e server. Oggi il front-end web è dominato da framework come React, Angular, Vue, Svelte, ma c’è un nuovo attore ed è assolutamente protagonista, sopratutto per applicazioni di ultima generazione.

Si chiama htmx, ed è stata rilasciata nel 2020. Oggi conta oltre 45k stelle su GitHub e solo un paio di anni fa è stata classificata al secondo posto tra i framework front-end in più rapida ascesa. Ma cosa rende htmx così interessante, specialmente per chi sviluppa applicazioni serverless?

htmx è una libreria JavaScript che consente di sfruttare funzionalità moderne del browser direttamente da HTML, senza scrivere codice JavaScript. Si tratta di una sorta di ‘potenziamento’ del linguaggio di markup, che rimane al centro dell’architettura. E qui entra in gioco uno dei suoi aspetti più forti: l’aderenza al modello REST classico, in cui è l’HTML stesso a rappresentare lo stato dell’applicazione.

Con poche righe di codice, questa libreria permette di interagire con il server attraverso richieste HTTP dinamiche, utilizzando semplicemente attributi HTML. Senza scrivere JavaScript. Senza configurare un router client. Senza creare uno ‘state manager’. Solo HTML, ma potenziato.

In htmx qualsiasi elemento del DOM può inviare una richiesta, e qualsiasi evento può essere utilizzato come trigger. Non ci si limita ai classici click o submit. È possibile reagire a un mouse enter, a uno scroll, o impostare polling automatici. E non si è vincolati a GET o POST: si possono usare anche PUT, PATCH, DELETE.

L’idea di fondo è quella di estendere il comportamento ‘ipermediale’ dell’HTML, recuperando il concetto che il Web è nato con: ogni interazione è una transizione di stato guidata da ipertesti. Non si restituiscono dati JSON da interpretare; si restituisce direttamente HTML da inserire nella pagina.

Questa filosofia si sposa sorprendentemente bene con architetture serverless perché ogni endpoint è una funzione autonoma, spesso deployata su piattaforme come Vercel o AWS Lambda.

Poter costruire un’interfaccia utente interamente basata su pezzi di HTML significa ridurre la complessità infrastrutturale, migliorare i tempi di risposta e avere un’applicazione che può scalare linearmente con il traffico.

Vediamo un esempio: supponiamo di voler mostrare un elenco di eroi in seguito al click di un pulsante. Con htmx è sufficiente scrivere:


<button hx-get="/heroes" hx-target="#hero-list">Carica Eroi!</button>

<div id="hero-list"></div>

Quando l’utente clicca sul pulsante, viene inviata una richiesta GET, un fetch, all’endpoint /heroes. Il server risponde con un frammento HTML, come ad esempio:

<ul>
  <li>Ranieri</li>
  <li>Marco</li>
  <li>Hero 1</li>
  <li>Hero 2</li>
  <li>Hero n</li>
</ul>

htmx provvede a inserirlo automaticamente dentro il div con ID hero-list, sostituendo il contenuto precedente. L’effetto è immediato, reattivo, ed estremamente semplice da implementare. Non c’è bisogno di costruire il markup lato client: lo fa il server, che resta al centro dell’applicazione.

Chi arriva da React o Vue potrebbe chiedersi: e lo stato? E le animazioni? E il routing? Tutte cose possibili, ma che vanno affrontate da una prospettiva diversa. Ad esempio, htmx supporta transizioni CSS nativamente, sfruttando l’attributo hx-swap e un piccolo delay chiamato ‘settle’. Se un elemento sostituito mantiene lo stesso ID e cambia classe, si può ottenere una transizione fluida senza una riga di JS.

Un esempio più dinamico? Consideriamo un polling automatico che aggiorna ogni due secondi una sezione con le ultime notifiche:


<div hx-get="/notifications" hx-trigger="every 2s" hx-target="#alerts"></div>

<div id="alerts"></div>

In un contesto serverless, questo è oro puro.

Lato server si può restituire un frammento HTML aggiornato ogni volta che ci sono nuove notifiche, senza mantenere connessioni WebSocket e senza infrastrutture persistenti.

Inoltre, htmx supporta funzionalità come la gestione della cronologia del browser (hx-push-url), l’integrazione con eventi custom (hx-on:), indicatori di caricamento (htmx-indicator), sincronizzazione tra richieste (hx-sync), e selezione mirata di elementi (hx-select). Il tutto utilizzando solo attributi HTML, con una curva di apprendimento minima.

Un altro vantaggio, spesso sottovalutato, è l’accessibilità. Applicazioni costruite con htmx sono, di base, più accessibili. I link rimangono link e i form rimangono form. Con l’attributo hx-boost, si possono trasformare tutti i link e form in richieste AJAX, mantenendo però il comportamento tradizionale come fallback.

Ovviamente non è lo strumento giusto per ogni progetto. Se serve un’interfaccia iperinterattiva, con gestione intensiva dello stato lato client, componenti complessi e aggiornamenti in tempo reale su larga scala, probabilmente è meglio rivolgersi ad altro. Ma se il cuore dell’applicazione è server-centrico, e ciò che serve è un frontend dinamico, ma lineare, htmx può ridurre drasticamente la complessità.

Vale la pena chiarire però che htmx non è un framework SSR.

Il SSR (Server-Side Rendering) indica un meccanismo in cui l’intera pagina (o una sua parte) viene generata dal server e poi inviata al browser, tipicamente in risposta a una richiesta iniziale o a una navigazione. htmx non genera HTML di per sé, né si occupa del rendering lato server. È piuttosto un meccanismo di orchestrazione HTML lato client: permette al client di inviare richieste HTTP tramite attributi HTML, e di inserire frammenti HTML restituiti dal server direttamente nel DOM. htmx si appoggia a un back-end che genera HTML, quindi usa risposte SSR (frammenti HTML generati dal server) invece di API REST/JSON. L’architettura tipica con htmx è server-driven: il client (htmx) chiede, il server risponde con markup pronto da iniettare. Questo è molto simile all’SSR, ma avviene in modo incrementale e dinamico, senza ricaricare l’intera pagina. htmx non è un motore di rendering SSR come può essere Next.js, ma è complementare a un back-end SSR.

In definitiva, htmx offre una possibilità rara nel panorama attuale: costruire web app moderne senza rinunciare alla semplicità originaria del Web.

E per chi sviluppa in ambienti serverless, è un’opportunità concreta di fare molto di più, ma con meno.

Ranieri Vannozzi

L'autore

Ranieri Vannozzi

Sviluppatore e consulente software freelance

Scrivo codice dal 2008 e lavoro su sviluppo enterprise, architetture cloud-native e leadership tecnica. Su HeroHubs racconto quello che incontro ogni giorno nei progetti, tra codice, architetture e intelligenza artificiale.

Articolo scritto con il supporto dell'AI e rivisto dall'autore.

Post Correlati

Performant npm: il gestore di pacchetti che ripensa node_modules

Sviluppo

Settembre 2026

Performant npm: il gestore di pacchetti che ripensa node_modules

Performant npm non è soltanto un npm più veloce. Lo store globale con hard link e la struttura rigida di node_modules cambiano il modo in cui un progetto JavaScript dichiara e usa le proprie dipendenze.

Conventional Commits: il messaggio di commit come documento tecnico

Sviluppo

Giugno 2026

Conventional Commits: il messaggio di commit come documento tecnico

Scrivere i messaggi di commit in modo libero è una convenzione che si forma per inerzia. Conventional Commits la sostituisce con una struttura che genera valore automaticamente.

Brute force protection: l'autenticazione che non cede

Sviluppo

Giugno 2026

Brute force protection: l'autenticazione che non cede

Un attacco brute force non è sofisticato ma è persistente. Costruire una difesa solida è una questione architetturale prima ancora che di configurazione.

Perché ignorare il package-lock è un suicidio architettonico?

Sviluppo

Maggio 2026

Perché ignorare il package-lock è un suicidio architettonico?

Molti sviluppatori considerano il lock file un rumore di fondo nei commit. In realtà, è l'unica cosa che separa il tuo codice da un crash improvviso in produzione.

Biome: la toolchain moderna che semplifica lo sviluppo web

Sviluppo

Ottobre 2025

Biome: la toolchain moderna che semplifica lo sviluppo web

Scopri Biome: la toolchain unificata per linting, formatting e analisi del codice JavaScript/TypeScript. Vantaggi, integrazione e produttività per sviluppatori moderni.

Test Driven Development: un alleato silenzioso per gli eroi del software

Sviluppo

Ottobre 2025

Test Driven Development: un alleato silenzioso per gli eroi del software

Scopri il Test Driven Development (TDD): vantaggi, ciclo Red-Green-Refactor, esempi pratici e differenze con BDD per migliorare la qualità e la manutenibilità del software.

Astro: architettura a isole e rendering ibrido per contenuti performanti

Sviluppo

Ottobre 2025

Astro: architettura a isole e rendering ibrido per contenuti performanti

Guida ad Astro: framework moderno per siti statici e ibridi, architettura a isole, rendering server-first, SEO, performance e integrazione con React, Vue e Svelte.

Feature Flags: la chiave per rilasci sicuri, controllati e continui

Sviluppo

Ottobre 2025

Feature Flags: la chiave per rilasci sicuri, controllati e continui

Scopri come le feature flags rivoluzionano il rilascio software: gestione graduale delle funzionalità, rollback istantanei, test A/B e best practice per DevOps e CI/CD.

Hono: semplicità e potenza per applicazioni web moderne

Sviluppo

Settembre 2025

Hono: semplicità e potenza per applicazioni web moderne

Guida a Hono: framework web minimalista per JavaScript, vantaggi, esempi pratici e come costruire applicazioni moderne, leggere e performanti.