L'Approccio HTML-First: Perché htmx e i Framework Leggeri Stanno Rivoluzionando lo Sviluppo Web

Dec 11, 2025 · 19 min read

Per anni, quando si trattava di costruire qualcosa di “moderno” sul web, la scelta quasi automatica cadeva su React, Angular, Vue e l’intero ecosistema delle Single Page Application (SPA). Questi framework sono diventati la scelta sicura, quasi uno standard de facto. Ma ultimamente si sta verificando un cambiamento significativo nel panorama dello sviluppo front-end. Molti team — compresi alcuni di grandi dimensioni e con progetti enterprise — si stanno orientando verso framework HTML-first come htmx e altri strumenti che adottano un approccio più tradizionale, guidato dal server.

E onestamente, ha perfettamente senso. 🎯

Non tutte le applicazioni necessitano di un pesante motore client-side. In molti casi, il modello SPA aggiunge più complessità che valore. I framework HTML-first riportano in primo piano parte della semplicità e della velocità per cui il web era stato originariamente progettato, senza rinunciare all’interattività che gli utenti si aspettano.

In questo articolo esploreremo in profondità le ragioni di questa tendenza, supportate da dati e statistiche concrete.

Il Problema del JavaScript Bloat: I Numeri Parlano Chiaro 📊

Prima di analizzare i vantaggi dell’approccio HTML-first, è fondamentale comprendere l’entità del problema che stiamo affrontando.

La Crescita Esponenziale del JavaScript

I dati dell’HTTP Archive sono eloquenti: la quantità media di JavaScript trasferito per pagina è passata da 90 KB nel 2010 a 650 KB nel 2024. E questa tendenza non mostra segni di rallentamento.

Ma questi sono solo i valori medi. Un’analisi dettagliata del 2024 rivela casi ben più estremi:

Slack, un’applicazione di chat, carica 55 MB di JavaScript — praticamente le dimensioni dell’originale Quake 1 con tutte le risorse incluse
Jira, un software di gestione dei task, pesa quasi 50 MB
LinkedIn arriva a 31 MB
I semplici pulsanti “Like” dei social network richiedono tipicamente 12 MB di codice
Persino Google Maps, relativamente modesto per gli standard moderni, pesa 4.5 MB

Se assumiamo che una linea di codice media sia di circa 65 caratteri, stiamo parlando di spedire approssimativamente 150.000 righe di codice con ogni sito web, talvolta solo per mostrare contenuto statico!

💡 Ci hai mai pensato? Slack, un’app di messaggistica, richiede più spazio di un intero videogioco 3D degli anni ‘90. Per mandare messaggi di testo.

L’Impatto Sulle Performance

JavaScript è la risorsa computazionalmente più costosa che un browser deve gestire. È spesso il collo di bottiglia che determina se una pagina appare veloce o lenta, poiché un bundle sovradimensionato può bloccare il rendering e degradare le performance complessive.

Per chi utilizza un laptop di fascia alta con connessione in fibra, questo potrebbe essere solo un piccolo fastidio. Ma per chi naviga con un telefono di fascia bassa o una connessione instabile, può fare la differenza tra restare sul sito o abbandonarlo completamente.

Le Dimensioni dei Framework a Confronto

Ecco un confronto delle dimensioni dei principali framework JavaScript (versioni gzipped), secondo i dati di LogRocket e Strapi:

Framework	Dimensione Gzipped
Angular	~62.3 KB
React + ReactDOM	~44.5 KB
Vue	~34.7 KB
htmx	~14 KB

htmx pesa circa un terzo di Vue e meno di un quarto di Angular. E questi sono solo i framework core — le applicazioni reali tipicamente includono librerie per routing, state management, form handling, HTTP client e molto altro.

Costruire con HTML Invece di Combattere con Layer di JavaScript 🛠️

I tool HTML-first permettono di concentrarsi sulla struttura e sul comportamento reale dell’applicazione, invece di dover gestire alberi di componenti, hydration, reducer, context provider e tutto l’overhead che accompagna i framework SPA.

Con htmx, ad esempio, si invia semplicemente HTML dal server, e la libreria sostituisce le parti giuste nella pagina. Niente cartelle con 20 file per un singolo componente React. Niente librerie di state management client-side. Niente over-engineering.

È un approccio che risulta sorprendentemente diretto e lineare.

Un Esempio Pratico

Consideriamo un semplice pulsante che carica contenuto dinamico.

Approccio tradizionale SPA (React):

// useState, useEffect, fetch API, loading state management,
// error handling, conditional rendering...
function LoadDataButton() {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);

  const handleClick = async () => {
    setLoading(true);
    try {
      const response = await fetch('/api/data');
      const json = await response.json();
      setData(json);
    } catch (e) {
      setError(e);
    } finally {
      setLoading(false);
    }
  };

  return (
    <div>
      <button onClick={handleClick} disabled={loading}>
        {loading ? 'Loading...' : 'Load Data'}
      </button>
      {error && <div className="error">{error.message}</div>}
      {data && <DataDisplay data={data} />}
    </div>
  );
}

Approccio HTML-first con htmx:

<button hx-get="/data"
        hx-target="#result"
        hx-indicator="#loading">
  Load Data
</button>
<span id="loading" class="htmx-indicator">Loading...</span>
<div id="result"></div>

Il server restituisce direttamente l’HTML pronto da visualizzare. Fine della storia.

✨ La differenza è evidente: 30+ righe di codice React vs 5 righe di HTML con htmx. Stesso risultato, complessità radicalmente diversa.

Le Performance Migliorano Quasi Automaticamente ⚡

Le SPA inviano tonnellate di JavaScript al browser — e il browser paga questo prezzo ogni volta: parsing, esecuzione, hydration, diffing del virtual DOM, e così via.

I framework HTML-first funzionano nel modo opposto. Caricano velocemente perché il browser fa ciò che sa fare meglio: renderizzare HTML. L’interattività viene aggiunta in piccoli pezzi mirati invece di spedire un intero runtime.

I Dati Confermano

Secondo uno studio del 2024:

Il Time to Interactive (TTI) mediano per le SPA era di 2.9 secondi, contro 1.8 secondi per i siti SSR
Il Time to First Byte (TTFB) mediano era di 0.6 secondi per le SPA, contro 0.2 secondi per SSR

Gli utenti — specialmente quelli mobile — avvertono immediatamente la differenza.

Perché il Server-Side Rendering è Più Veloce per il Content

Il vantaggio dell’SSR risiede principalmente nel tempo più rapido per visualizzare il contenuto, che diventa più evidente su connessioni Internet lente o dispositivi poco potenti. Il markup renderizzato dal server non deve attendere che tutto il JavaScript sia stato scaricato ed eseguito per essere visualizzato, quindi gli utenti vedono una pagina completamente renderizzata prima.

Questo si traduce generalmente in metriche Core Web Vitals migliori, user experience superiore, e può essere critico per le applicazioni dove il tempo di visualizzazione del contenuto è direttamente associato al tasso di conversione.

La UI Guidata dal Server è Più Pulita per la Maggior Parte delle Applicazioni Business 🏢

La maggior parte della logica reale — validazione, regole di business, controllo degli accessi — risiede comunque sul server. I framework HTML-first non costringono a duplicarla su entrambi i lati.

Invece di creare un endpoint API, trasformarlo, consumarlo e sincronizzare tutto nel client… si renderizza semplicemente HTML con lo stato aggiornato.

Semplice. Prevedibile. Facile da comprendere e debuggare.

Un Solo Routing, Una Sola Fonte di Verità

Uno degli aspetti più sottovalutati dell’approccio HTML-first è l’eliminazione della duplicazione del routing. Nelle SPA tradizionali, si finisce inevitabilmente con due sistemi di routing paralleli: uno sul server (per le API e il rendering iniziale) e uno sul client (per la navigazione interna). Questo significa doppia configurazione, doppia manutenzione e, spesso, inconsistenze difficili da debuggare.

Con htmx e l’approccio server-driven, esiste un solo routing: quello del server. Le URL corrispondono direttamente alle risorse, il browser gestisce la navigazione in modo nativo, e lo sviluppatore ha un’unica fonte di verità da mantenere.

Validazione: Solo Dove Conta Davvero

Lo stesso principio si applica ai controlli formali e alla validazione dei dati. Nelle architetture SPA, gli sviluppatori si trovano spesso a implementare la stessa logica di validazione due volte: sul client (per fornire feedback immediato e migliorare la UX) e sul server (dove i controlli DEVONO sempre risiedere per ragioni di sicurezza).

Con l’approccio HTML-first, la validazione rimane dove deve stare: sul server. E grazie alla velocità delle risposte HTML parziali, il feedback all’utente è comunque quasi istantaneo. Il server valida i dati e restituisce direttamente l’HTML con eventuali messaggi di errore già renderizzati. Niente duplicazione di logica, niente rischio di inconsistenze tra le regole client e server, niente possibilità che un utente malintenzionato bypasse i controlli client-side.

E se per evitare di fare troppe richieste al server si vuole implementare un controllo anche lato client? Si può sempre fare senza problemi! La differenza fondamentale è che non si è obbligati a implementare la validazione due volte — si può scegliere di farlo solo quando ha senso per la UX, sapendo che la validazione server-side è già garantita.

🔐 Nota sulla sicurezza: La validazione client-side è sempre bypassabile. Un utente malintenzionato può semplicemente disabilitare JavaScript o modificare le richieste HTTP. La validazione server-side non è opzionale — è l’unica che conta davvero per la sicurezza.

Il Pattern HATEOAS Rivive

L’approccio HTML-first è in linea con il principio architetturale HATEOAS (Hypermedia as the Engine of Application State), uno dei vincoli REST originali spesso ignorati nelle moderne API JSON.

Ma cosa dice esattamente questo principio? HATEOAS stabilisce che un client deve poter interagire con un’applicazione interamente attraverso le risposte hypermedia fornite dinamicamente dal server. In altre parole, il client non deve avere conoscenza a priori di come interagire con il server oltre a un punto di ingresso iniziale — tutte le azioni possibili devono essere scoperte dinamicamente attraverso i link e i controlli presenti nella risposta stessa.

Pensateci: quando il server restituisce HTML, restituisce automaticamente i link alle pagine correlate, i form per le azioni disponibili, i pulsanti per le operazioni consentite. L’interfaccia è l’API. Il browser sa già come navigare i link e sottomettere i form — non serve alcuna logica client-side per “interpretare” la risposta e decidere cosa fare dopo.

Le tue JSON-API possono farlo? Nella stragrande maggioranza dei casi, no. Le API JSON restituiscono dati grezzi che il client deve interpretare, e la logica di navigazione e interazione deve essere implementata separatamente nel codice front-end. Il client deve “sapere” a priori quali endpoint chiamare, come costruire le richieste, e come interpretare le risposte — violando di fatto il principio HATEOAS.

Facciamo un esempio concreto: una lista di clienti che al click mostra il dettaglio del singolo cliente.

Con una JSON-API tradizionale:

{
  "customers": [
    {"id": 1, "name": "Mario Rossi", "email": "mario@example.com"},
    {"id": 2, "name": "Luigi Verdi", "email": "luigi@example.com"}
  ]
}

Il client riceve questi dati e deve sapere a priori che per ottenere il dettaglio deve chiamare /api/customers/{id}. Questa conoscenza è hardcoded nel codice JavaScript del front-end. Se l’URL cambia, il client si rompe. Se ci sono regole di accesso che impediscono di vedere certi clienti, il client non lo sa finché non prova a chiamare l’endpoint e riceve un errore.

Con htmx e l’approccio HTML-first:

<ul>
  <li>
    <a hx-get="/customers/1" hx-target="#detail">Mario Rossi</a>
  </li>
  <li>
    <a hx-get="/customers/2" hx-target="#detail">Luigi Verdi</a>
  </li>
</ul>
<div id="detail"></div>

Il server restituisce direttamente l’HTML con i link già incorporati. Il client non deve “sapere” nulla — segue semplicemente i link presenti nella risposta. Se un utente non ha accesso a un certo cliente, il server semplicemente non include quel link nella lista. Se l’URL cambia, il server genera i nuovi link e il client continua a funzionare senza modifiche.

Quale dei due approcci rispetta HATEOAS? Solo il secondo. L’HTML è hypermedia per definizione — è stato progettato esattamente per questo scopo.

Per essere precisi, una JSON-API ben progettata dovrebbe includere una proprietà links per il discovery delle risorse correlate:

{
  "customers": [
    {
      "id": 1,
      "name": "Mario Rossi",
      "email": "mario@example.com",
      "links": {
        "self": "/api/customers/1",
        "orders": "/api/customers/1/orders"
      }
    }
  ],
  "links": {
    "self": "/api/customers",
    "next": "/api/customers?page=2"
  }
}

Ma siamo onesti: la stragrande maggioranza delle JSON-API in produzione non implementa questi link. E anche quando lo fa, il problema non è risolto: il client deve comunque avere una UI già pronta e capace di interpretare quei dati e mostrarli in modo appropriato. I link JSON dicono dove andare, ma non come presentare ciò che si trova. Il client deve ancora “sapere” che un customer ha un nome, un’email, e che gli ordini vanno mostrati in una tabella con certe colonne.

Con l’HTML, invece, la rappresentazione è già inclusa nella risposta. Non serve alcuna logica di rendering client-side.

Con htmx, il server non restituisce solo dati, ma restituisce rappresentazioni complete dell’interfaccia utente con i link e le azioni disponibili già incorporate. Questo elimina un’intera categoria di problemi legati alla sincronizzazione dello stato tra client e server.

Meno Codice e Meno Dipendenze 📦

Uno dei benefici più grandi è semplicemente un codebase più piccolo:

Nessun bundle enorme da ottimizzare e debuggare
Nessuna pipeline di build complicata (webpack, babel, typescript config, etc.)
Meno parti mobili che possono rompersi
Onboarding più facile per i nuovi membri del team
Meno problemi di upgrade delle versioni

Questo si traduce anche in meno bug e manutenzione più veloce nel lungo periodo.

Il Costo Nascosto della Complessità

Ogni libreria JavaScript che aggiungi al progetto porta con sé un costo che va ben oltre i kilobyte del download iniziale.

Prendiamo un esempio tipico: vuoi formattare una data. Installi moment.js (o un’alternativa moderna). Ma quella libreria ha le sue dipendenze, che a loro volta ne hanno altre. Improvvisamente, per formattare “2025-01-15” in “15 Gennaio 2025”, hai aggiunto centinaia di kilobyte al tuo bundle.

E non finisce qui. Ogni libreria:

Ha un suo ciclo di rilascio con breaking changes
Può avere vulnerabilità di sicurezza che richiedono aggiornamenti urgenti
Deve essere compatibile con tutte le altre librerie del progetto
Aggiunge tempo al build e al deploy

Molti sviluppatori installano librerie come lodash, axios o moment solo per usare una singola funzione. È come comprare un’intera cassetta degli attrezzi per usare solo il cacciavite.

⚠️ Attenzione: Ogni dipendenza è un potenziale punto di rottura. Gli incidenti nella supply chain JavaScript continuano a verificarsi regolarmente — da pacchetti compromessi a maintainer che abbandonano progetti critici. Meno dipendenze = meno rischi.

Con l’approccio HTML-first, gran parte di questa complessità semplicemente scompare. La formattazione delle date avviene sul server (dove hai il pieno controllo del formato), le richieste HTTP sono gestite da htmx con poche righe di attributi, e il DOM viene aggiornato automaticamente con l’HTML ricevuto. Non serve reinventare la ruota con 200 KB di JavaScript.

Progressive Enhancement: Evoluzione, Non Riscrittura 🔄

Si può aggiungere htmx a quasi qualsiasi backend esistente senza stravolgere l’intera struttura del progetto.

Serve una tabella dinamica? Si migliora quella sezione.

Servono interazioni modali senza una SPA completa? Si inserisce l’HTML al volo.

Non è una decisione “tutto o niente” — si migliora l’interfaccia passo dopo passo.

I Tre Livelli del Progressive Enhancement

Il progressive enhancement è basato su tre principi fondamentali:

Content First: Al cuore di ogni sito web c’è il suo contenuto. Il progressive enhancement assicura che il contenuto sia accessibile a tutti gli utenti, anche se hanno browser molto basilari o connessioni Internet lente. Questo significa partire da una solida fondazione HTML.
Funzionalità di Base: Garantire che le funzionalità core funzionino senza JavaScript avanzato. Con htmx questo è possibile se si progetta con attenzione: i link possono avere un href standard come fallback, i form possono funzionare con un normale submit. htmx migliora il comportamento standard dell’HTML. Tuttavia, è importante notare che funzionalità basate su pulsanti con hx-get o hx-post (che non siano submit di form) richiedono JavaScript — sta allo sviluppatore decidere dove il graceful degradation è importante e progettare di conseguenza.
Esperienze Migliorate: Aggiungere progressivamente funzionalità avanzate per browser e dispositivi che le supportano.

Wikipedia, alimentata da MediaWiki, è un esempio perfetto: è leggibile, navigabile e persino editabile usando l’interfaccia HTML base senza styling o script, ma viene migliorata quando questi sono disponibili.

SEO, Accessibilità e Comportamento del Browser Funzionano Nativamente 🌐

Quando l’applicazione usa HTML reale invece di un Virtual DOM, si evitano molti problemi accidentali che le SPA introducono. Il pulsante indietro, il deep linking, gli strumenti di accessibilità e la SEO funzionano tutti naturalmente.

Nessun hack richiesto.

I Vantaggi per la SEO

Poiché il contenuto di base è sempre accessibile agli spider dei motori di ricerca, le pagine costruite con metodi di progressive enhancement evitano i problemi che possono ostacolare l’indicizzazione, mentre dover renderizzare il contenuto base della pagina attraverso l’esecuzione di JavaScript rende il crawling lento e inefficiente.

Questa strategia accelera il caricamento e facilita il crawling da parte dei motori di ricerca, poiché il testo sulla pagina viene caricato immediatamente attraverso il codice sorgente HTML piuttosto che dover aspettare che JavaScript si inizializzi e carichi il contenuto successivamente.

I motori di ricerca danno priorità ai contenuti accessibili e facili da leggere. Partendo da una struttura HTML pulita e assicurando che il contenuto sia disponibile a tutti gli utenti, si migliorano le possibilità di posizionarsi bene nei risultati di ricerca.

Pronti per l’Era della Ricerca AI

C’è un aspetto che molti sviluppatori non stanno ancora considerando: l’ascesa dei motori di ricerca basati su intelligenza artificiale. Strumenti come ChatGPT Search, Perplexity, Google AI Overviews e altri stanno cambiando radicalmente il modo in cui gli utenti trovano informazioni online.

Questi sistemi AI hanno bisogno di contenuto chiaro, strutturato e immediatamente accessibile. Anche se alcuni crawler moderni possono eseguire JavaScript, l’esecuzione è spesso limitata, ritardata o incompleta. Una SPA che carica il contenuto dinamicamente via JavaScript rischia di essere indicizzata in modo parziale, impreciso, o con significativi ritardi rispetto ai siti con contenuto HTML immediato.

Con l’approccio HTML-first, il contenuto è già presente nel documento HTML servito dal server. I crawler AI (così come i tradizionali spider dei motori di ricerca) possono immediatamente accedere, comprendere e indicizzare tutto il contenuto. Nessuna attesa per l’esecuzione di JavaScript, nessun rischio che parti della pagina non vengano viste.

In un mondo dove sempre più traffico arriverà dalle risposte generate dall’AI, avere contenuti facilmente accessibili e ben strutturati non è più solo una best practice — è una necessità competitiva.

🤖 Preparati al futuro: I crawler AI stanno diventando sempre più importanti. Un sito invisibile all’AI è un sito che perde opportunità. L’HTML-first ti mette in pole position.

I Vantaggi per l’Accessibilità

Uno dei benefici più significativi del progressive enhancement è l’accessibilità migliorata. Partendo da una solida fondazione HTML, si assicura che il contenuto sia accessibile a tutti gli utenti, inclusi quelli con disabilità.

Gli screen reader e altre tecnologie assistive funzionano nativamente con HTML semantico. Le SPA, d’altra parte, spesso richiedono implementazioni ARIA complesse e testing specializzato per raggiungere lo stesso livello di accessibilità.

htmx: La Star Emergente ⭐

htmx sta vivendo una crescita impressionante. Secondo JavaScript Rising Stars 2024, htmx ha ottenuto più stelle GitHub annuali rispetto a librerie più consolidate come Vue e Angular (nota: questo si riferisce alla crescita annuale delle stelle, non al totale).

I Numeri del Successo

Nel Stack Overflow Developer Survey 2024, htmx è il 22° framework web più usato con il 3.3% degli sviluppatori che lo utilizzano
In termini di soddisfazione, htmx è il 2° framework web più “ammirato” con il 72.9% nel sondaggio Stack Overflow 2024, secondo solo al framework Phoenix di Elixir (83.7%)
Nel Django Developers Survey, l’uso di htmx è passato dal 5% nel 2021 al 16% nel 2022 — una crescita del 220%
htmx 2.0.0 è stato rilasciato il 17 giugno 2024, segnando un importante traguardo di maturità
htmx è stato ammesso al GitHub Accelerator nel 2023, un programma che seleziona i progetti open source più promettenti

Cosa Rende htmx Speciale

htmx è piccolo (~14-16 KB min.gz), senza dipendenze, estensibile e, secondo i report, ha ridotto le dimensioni del codice del 67% rispetto a React in progetti comparabili.

htmx non riduce solo la dimensione del bundle — elimina la necessità del diffing del Virtual DOM, dei cicli di vita dei componenti e dell’orchestrazione dello stato client-side. Il risultato sono caricamenti pagina più veloci, meno codice da debuggare e un modello mentale più leggero per costruire interfacce utente.

Ideale per App Enterprise, Dashboard e Portali 💼

Non tutte le applicazioni sono strumenti di design altamente interattivi. Molti dei sistemi che le aziende costruiscono — piattaforme di prenotazione, dashboard, strumenti di amministrazione, form, portali interni — si adattano perfettamente a questo modello.

Non hanno bisogno di 500 KB di JavaScript per gestire interazioni di base.

I framework HTML-first trovano un buon equilibrio tra interattività e manutenibilità.

Casi d’Uso Perfetti per HTML-First

Dashboard amministrative: Tabelle con paginazione, filtri, azioni CRUD
Portali interni: Gestione documenti, workflow approval, reportistica
E-commerce backend: Gestione ordini, inventario, clienti
Form complessi multi-step: Wizard di registrazione, configuratori di prodotto
Sistemi di booking: Calendari, prenotazioni, gestione slot
CRM e ERP: Gestione contatti, pipeline vendite, fatturazione
Applicazioni data-entry: Import/export dati, bulk editing

htmx e Delphi: Una Combinazione Vincente 🚀

Per gli sviluppatori Delphi, l’approccio HTML-first con htmx rappresenta un’opportunità particolarmente interessante. DelphiMVCFramework offre un supporto eccellente per questo paradigma, permettendo di sfruttare la potenza e l’affidabilità del backend Delphi con un front-end moderno e leggero.

I Vantaggi per gli Sviluppatori Delphi

Backend robusto: La solidità e le performance di Delphi sul server
Template engine potenti: TemplatePro o WebStencils per generare HTML dinamico
Semplicità di deployment: Un singolo eseguibile senza dipendenze node.js
Nessun build JavaScript: Addio a webpack, npm, e tool chain complesse
Competenze riutilizzabili: Gli sviluppatori Delphi possono essere produttivi immediatamente

I progetti quickstart disponibili su GitHub (TemplatePro + htmx e WebStencils + htmx) offrono un punto di partenza ideale per iniziare.

💡 Suggerimento: Se sei uno sviluppatore Delphi e vuoi iniziare con htmx, clona uno dei progetti quickstart e avrai un’applicazione funzionante in pochi minuti. Nessuna configurazione npm, nessun webpack, nessun node_modules da 500 MB.

Quando NON Usare l’Approccio HTML-First ⚖️

È importante essere onesti: l’approccio HTML-first non è la soluzione per tutto. Ecco quando le SPA tradizionali rimangono la scelta migliore:

Applicazioni altamente interattive in tempo reale: Editor grafici, strumenti di collaborazione come Google Docs, applicazioni di video editing
Applicazioni offline-first: Quando l’applicazione deve funzionare significativamente senza connessione
Giochi e applicazioni 3D: Dove il rendering client-side intensivo è necessario
Applicazioni con stato client complesso: Dove lo stato dell’interfaccia è significativamente diverso dallo stato del server

Per queste tipologie di applicazioni, le SPA offrono vantaggi concreti: gestione sofisticata dello stato locale, transizioni fluide tra viste complesse, e la possibilità di funzionare offline con service worker.

Il Futuro: Un Approccio Ibrido 🔮

La tendenza che stiamo osservando non è un ritorno al passato, ma un’evoluzione verso un approccio più pragmatico. I migliori sviluppatori stanno imparando a scegliere lo strumento giusto per il problema specifico.

Il Paradigma Islands Architecture

Un trend emergente è la “Islands Architecture”, dove la maggior parte della pagina è HTML statico o server-rendered, con “isole” di interattività JavaScript solo dove necessario. Framework come Astro.js (con un impressionante 94% di utenti che lo userebbero di nuovo secondo lo State of JavaScript 2024) stanno esplorando questo territorio.

htmx si inserisce perfettamente in questo paradigma, permettendo di aggiungere interattività dove serve senza richiedere un’architettura completamente client-side.

Conclusioni 🎯

React e Angular hanno assolutamente il loro posto, e sono ottimi quando si ha veramente bisogno di un’applicazione client-side complessa. Ma per molti progetti, l’approccio HTML-first è più veloce da costruire, più facile da mantenere e più leggero per il browser.

Non è un passo indietro — è un promemoria che il web ci fornisce già tutto ciò di cui abbiamo bisogno per costruire applicazioni potenti e reattive senza il peso aggiuntivo.

Con htmx che ora conta oltre il 72% di soddisfazione tra gli sviluppatori, una crescita esplosiva delle stelle GitHub, e l’adozione da parte di team sempre più grandi, è chiaro che questo non è solo un trend passeggero. È una riscoperta dei principi fondamentali del web, potenziata da strumenti moderni che rendono l’esperienza di sviluppo fluida e piacevole.

La prossima volta che iniziate un nuovo progetto web, prima di raggiungere automaticamente React o Vue, chiedetevi: “Ho davvero bisogno di tutto questo?” La risposta potrebbe sorprendervi.

🚀 Pronto a provare? Inizia con un piccolo progetto o migliora una sezione di un’applicazione esistente. htmx non richiede una riscrittura completa — puoi adottarlo gradualmente e vedere i benefici immediatamente.

Risorse per Approfondire 📚

🎓 Vuoi approfondire con un corso? bit Time Professionals offre corsi dedicati su htmx e sull’integrazione DelphiMVCFramework + TemplatePro + htmx. Seguire un corso strutturato ti permette di essere produttivo da subito, con applicazioni pratiche, esempi reali, pattern architetturali collaudati e best practice apprese in anni di esperienza sul campo. I corsi sono disponibili in italiano, inglese e spagnolo.