HTMX: semplicità apparente, complessità reale

Pubblicato da

  

Negli ultimi anni il mondo del web development sembra oscillare come un pendolo: prima SPA ovunque, poi il ritorno al server-side rendering, ora una nuova promessa di semplicità chiamata HTMX. C'è chi lo considera una piccola rivoluzione, chi lo vede come il modo "giusto" di fare web nel 2025. Io? Io sono più scettico. Molto più scettico.

In questo articolo vedremo cos'è HTMX, a cosa serve, come si usa, qualche esempio pratico, e infine — inevitabilmente — spiegherò perché, pur riconoscendone i meriti, non sono d'accordo con questo approccio per costruire software davvero solido e manutenibile.

🔗 Ti piace Techelopment? Dai un'occhiata al sito per tutti i dettagli!

Cos'è HTMX

HTMX è una libreria (e non un framework!) JavaScript che permette di estendere l'HTML con attributi speciali (hx-*) per effettuare richieste HTTP (AJAX, fetch, WebSocket, SSE) e aggiornare porzioni della pagina senza scrivere JavaScript esplicito.

In altre parole: torniamo a scrivere HTML "intelligente" che parla direttamente con il server.

Esempio minimale:

<button hx-get="/saluto" hx-target="#output">
  Cliccami
</button>

<div id="output"></div>

Quando l'utente clicca il bottone, HTMX fa una richiesta GET a /saluto e inserisce la risposta HTML nel div#output.

Semplice. Molto semplice.


A cosa serve HTMX

HTMX nasce per risolvere un problema reale: la complessità eccessiva delle SPA moderne.

Per molti progetti:

  • React / Vue / Angular sono sovradimensionati
  • Il boilerplate è enorme
  • Il bundle JS cresce
  • La logica è sparsa tra frontend e backend

HTMX propone una filosofia diversa:

  • Il server torna ad essere il centro della logica
  • Il frontend è (quasi) solo HTML
  • Le interazioni dinamiche avvengono tramite frammenti HTML restituiti dal backend

È particolarmente apprezzato in combinazione con:

  • Backend MVC classici (Django, Rails, Laravel)
  • Linguaggi server-side tipizzati
  • Progetti CRUD, dashboard, backoffice

Come si usa HTMX

L'uso di HTMX ruota attorno agli attributi hx-*. I principali sono:

  • hx-get, hx-post, hx-put, hx-delete
  • hx-target: dove inserire la risposta
  • hx-swap: come inserire la risposta
  • hx-trigger: quando scatenare la richiesta

Esempio con form:

<form hx-post="/login" hx-target="#messaggio" hx-swap="innerHTML">
  <input name="username">
  <input type="password" name="password">
  <button>Login</button>
</form>

<div id="messaggio"></div>

Nessun JavaScript. Nessun fetch. Nessun framework.

Ed è qui che molti iniziano ad innamorarsi.


Esempi pratici

Caricamento parziale di una lista

<button hx-get="/utenti" hx-target="#lista">
  Carica utenti
</button>

<ul id="lista"></ul>

Il server restituisce:

<li>Mario</li>
<li>Luigi</li>
<li>Pietro</li>

Infinite scroll

<div hx-get="/feed?page=2"
     hx-trigger="revealed"
     hx-swap="afterend">
</div>

Funziona. È elegante. È veloce da scrivere.

Ed è proprio questo il problema.


La parte scomoda: perché non mi convince

Arriviamo al punto. HTMX funziona. Non lo nego. Ma la mia critica non riguarda il "funziona o no", bensì che tipo di software ti spinge a costruire.

1. Accoppiamento fortissimo tra frontend e backend

Con HTMX il backend restituisce HTML pronto. Questo significa che:

  • Il server conosce i dettagli della UI
  • Il markup diventa un contratto implicito
  • Cambiare una vista implica cambiare logica server

Stiamo fondendo presentazione e controllo come se MVC non ci avesse insegnato nulla negli ultimi 20 anni.

2. Logica distribuita negli attributi HTML

Quando il comportamento dell'applicazione è nascosto in attributi hx-* sparsi nel markup:

  • È difficile fare refactoring
  • È difficile cercare flussi logici
  • È difficile fare debugging

Il codice "non è dove te lo aspetti".

3. Scalabilità cognitiva discutibile

All'inizio il progetto è piccolo:

"Guarda com'è pulito! Solo HTML!"

Dopo qualche mese:

  • Condizioni lato server per decidere che HTML restituire
  • Frammenti duplicati
  • Endpoint creati solo per aggiornare pezzi di DOM

La complessità non scompare, viene solo spostata.

4. Testabilità più debole

Testare:

  • API JSON ben definite → facile
  • Componenti frontend isolati → possibile
  • Endpoint che restituiscono HTML parziale con logica embedded → molto meno

HTMX rende più difficile separare i livelli e testare in modo mirato.

5. È un ritorno al passato (con una mano di vernice)

Diciamolo chiaramente: HTMX è una versione raffinata di quello che facevamo con:

  • jQuery
  • .load()
  • partial view

Il fatto che oggi sia più elegante non lo rende automaticamente un progresso architetturale.


Quando può avere senso

Nonostante la vena polemica, HTMX non è il male assoluto.

Può avere senso se:

  • Il progetto è piccolo o medio
  • Il team è ridotto
  • La UI è semplice
  • Il backend è già MVC
  • La durata prevista del progetto è limitata

In questi casi, HTMX può essere pragmatico.

Ma non chiamiamolo "il modo corretto" di fare frontend moderno.


Conclusione

HTMX promette semplicità, e la mantiene… nel breve periodo.

Ma lo sviluppo software non è una demo, è una maratona. E nella maratona contano:

  • Separazione delle responsabilità
  • Architettura chiara
  • Testabilità
  • Manutenibilità nel tempo

HTMX è uno strumento. Usarlo ovunque come risposta universale è, a mio avviso, un errore.

Perché sì, puoi evitare JavaScript oggi.
Ma stai solo rimandando una complessità che domani tornerà a presentarti il conto, con gli interessi.

E no, non basterà un altro attributo hx-* per pagarla.



Follow me #techelopment

Official site: www.techelopment.it
facebook: Techelopment
instagram: @techelopment
X: techelopment
Bluesky: @techelopment
telegram: @techelopment_channel
whatsapp: Techelopment
youtube: @techelopment