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à.

Attenzione però! 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.