Express.js vs Next.js: la scelta giusta per la tua PMI nel 2026
Per fondatori, manager e agenzie italiane: quando conviene Express.js, quando Next.js e come evitare costosi cambi di rotta a metà progetto.
Cosa è successo
A inizio giugno 2026 Netguru — software house polacca con oltre 2.500 progetti consegnati — ha pubblicato un aggiornamento della sua guida comparativa Express.js vs Next.js: Which framework should you choose? (https://www.netguru.com/blog/express-js-vs-next-js). Il punto centrale non è una classifica dei framework, ma una distinzione architetturale che molti team sottovalutano: Express.js e Next.js non sono due alternative allo stesso problema, ma due layer diversi dello stack tecnologico.
Secondo Netguru, Express.js "possiede" la pipeline middleware HTTP: è un framework Node.js minimale, non opinionato, pensato per costruire server custom, API REST, WebSocket e streaming. Next.js, invece, "possiede" il rendering layer: è un framework full-stack per React che offre server-side rendering (SSR), static site generation (SSG), routing file-based e deploy ottimizzato su Vercel. La trappola più comune che i team commettono è scegliere il framework pensando solo al "percorso felice" del prototipo, senza considerare cosa succede quando il progetto cresce. Risultato: migrazioni costose, ritardi e debito tecnico che avrebbero potuto essere evitati con una scelta più lucida in fase di discovery.
La novità non sta nei nomi dei due framework, che sono noti da anni, ma nella chiarezza della matrice decisionale proposta: scegliere tra Express e Next.js significa valutare due assi — quanto è complesso il backend e quanto il progetto dipende dal rendering lato server — e accettare i trade-off connessi. Una lettura utile per chi, come noi, lavora ogni giorno con PMI e startup italiane che devono decidere il proprio stack con budget e tempi stretti.
Perché è importante
La scelta del framework non è un dettaglio tecnico da delegare al primo sviluppatore disponibile: è una scelta strategica che condiziona velocità di sviluppo, costi di manutenzione, SEO, latenza percepita dagli utenti e capacità di integrarsi con sistemi esistenti. Sbagliare significa pagare una "migration tax" che, nella nostra esperienza con aziende del Sud Italia e del Centro-Nord, può tradursi facilmente in 3-4 settimane di lavoro aggiuntivo e un sovraccosto del 15-20% sul budget iniziale.
Il fattore più sottovalutato è la latenza da cold start. Netguru cita un benchmark di OpenStatus relativo al 2024: su Vercel Serverless Functions, il cold start mediano (p50) per un endpoint Node.js semplice è stato di 859 ms a livello globale. Per un'azienda B2B italiana, dove il primo login della mattina o la prima chiamata API del commercialista non può impiegare quasi un secondo in più, questo è un problema concreto. Dall'altro lato, Vercel ha risposto con Fluid Compute, che secondo i dati ufficiali elimina il 99,37% dei cold start: una soluzione potente, ma non sempre attivata di default e non applicabile se si sceglie di self-hostare o di usare altri provider.
In sintesi: non esiste un vincitore assoluto. Esiste però una scelta coerente con il modello di business. E questa coerenza è ciò che separa un progetto che scala da uno che, dopo sei mesi, deve essere riscritto.
Cosa cambia per te
Se sei un founder, un responsabile IT di una PMI o gestisci un'agenzia che sviluppa progetti per clienti italiani, la domanda giusta non è "Express o Next.js?", ma "Cosa deve fare il mio prodotto tra 12 mesi?". Ecco tre scenazi concreti che incontriamo regolarmente.
Scenario 1: sito corporate, e-commerce di piccole dimensioni, landing page o SaaS con forte esigenza SEO. In questo caso Next.js è quasi sempre la scelta più efficiente. Pensiamo a un'azienda di abbigliamento con 20 dipendenti a Caserta o a uno studio professionale a Bologna: hanno bisogno di pagine veloci, social-share preview, contenuti indicizzabili e un'esperienza utente fluida. Next.js, magari deployato su Vercel, permette di ottenere tutto questo senza dover gestire un'infrastruttura complessa. Il team si concentra sui contenuti e sulle conversioni, non sui server.
Scenario 2: API condivisa, integrazioni ERP, WebSocket, streaming o backend che serve più frontend. Qui Express.js (o un framework strutturato come Nest.js, che gira sopra Express) è la scelta più solida. Immaginiamo una piccola manifattura in Veneto che vuole collegare il gestionale, un'app per gli agenti sul campo e una dashboard per il reparto produzione. Questo backend non deve fare rendering di pagine HTML: deve ricevere richieste, autenticare utenti, orchestrare dati e garantire bassa latenza. Metterlo dentro Next.js API Routes significa accettare vincoli come il limite di 250 MB sul bundle serverless e il timeout di 10 secondi, oltre all'impossibilità di gestire WebSocket in modo nativo. Con Express su un container o una VPS, il processo è persistente, caldo e sotto controllo.
Scenario 3: full-stack JavaScript con backend leggero. Molte startup B2B italiane partono con un'idea semplice: form di contatto, autenticazione, webhook da un servizio esterno, dashboard React. In questa fase Next.js con le API Routes può essere sufficiente e velocizza il time-to-market. La regola pratica che usiamo in AD Next Lab è: se entro i primi 6 mesi non emergono WebSocket, streaming o necessità di condividere l'API con altri client, Next.js resta. Se una di queste condizioni si presenta, è il momento di separare il backend in un servizio Express autonomo.
Un'ultima nota per le PMI italiane: evitate il "custom server" di Next.js a meno che non sia strettamente necessario. Far girare Express dentro Next.js per sfruttare il middleware sembra una soluzione ibrida intelligente, ma come ricorda la documentazione ufficiale di Next.js disabilita l'ottimizzazione statica automatica e vi espelle dai vantaggi edge di Vercel. Se volete Express, usatelo come servizio separato. Il costo operativo iniziale è leggermente superiore, ma la flessibilità futura è molto maggiore.
Come prepararsi
Ecco la checklist che usiamo con i nostri clienti prima di decidere lo stack. Non richiede competenze tecniche approfondite, ma solo una conversazione onesta su obiettivi, team e vincoli.
-
Disegna i due assi. Prendi un foglio e traccia: asse X = "quanto il progetto ha bisogno di rendering lato server / SEO"; asse Y = "quanto il backend è complesso (API, WebSocket, integrazioni, middleware)". Se sei in alto a sinistra, scegli Next.js. Se sei in basso a destra, scegli Express. Se sei al centro, valuta Next.js + API Routes con un piano B per separare il backend.
-
Fai l'inventario delle competenze del team. Se il tuo team conosce bene React ma ha poca esperienza server, Next.js riduce la curva di apprendimento. Se hai uno sviluppatore Node.js senior e il frontend è secondario, Express ti dà più controllo. Non scegliere un framework che nessuno poi riesce a mantenere.
-
Prototipa entrambe le opzioni per una settimana. Non serve un POC completo. Costruisci una pagina SSR con Next.js e un endpoint API con Express. Misura i tempi di risposta, la facilità di deploy e la leggibilità del codice. Spende una settimana ora ti fa risparmiare mesi dopo.
-
Decidi il target di deploy prima di scegliere il framework. Se vuoi zero configurazione e traffico variabile, Vercel + Next.js è comodo. Se hai flussi B2B con latenza critica, traffico prevedibile o vincoli di sovranità dei dati, un container su AWS, GCP o un provider italiano con Express è più sicuro.
-
Monitora i cold start fin dal primo giorno di produzione. Se usi Next.js API Routes su Vercel, configura strumenti che ti mostrino p50, p95 e p99 dei tempi di risposta. Se vedi picchi sopra i 600-800 ms su endpoint critici, è un segnale che stai forzando Next.js oltre i suoi confini naturali.
-
Pianifica un'architettura ibrida, non un frankenstein. Separare frontend Next.js e backend Express non è un fallimento: è una scelta matura. Se oggi puoi far tutto con Next.js, benissimo. Ma scrivi fin da subito i confini dei servizi in modo che, se domani serve spostare un'API, lo fai senza stravolgere l'applicazione.
La mia opinione
In AD Next Lab usiamo entrambi i framework: Next.js per i frontend, le landing page e i progetti dove SEO e velocità di sviluppo contano; Express (e spesso Nest.js sopra Express) per le API, gli agenti AI, i webhook e i sistemi che devono dialogare con più client. Non ho una religione tecnologica: ho una metrica — quanto la scelta rende il cliente indipendente e il prodotto manutenibile.
Quello che vedo troppe volte, soprattutto tra le PMI italiane, è la tentazione di appiattire tutto su un'unica tecnologia per risparmiare. Si sceglie Next.js perché "fa tutto" e si finisce a reinventare middleware e gestione stato server. Oppure si sceglie Express perché "più libero" e si scopre che il team non ha le competenze per gestire autenticazione, deploy e monitoraggio in produzione. La verità è che la semplicità non sta nell'usare un solo strumento, ma nel mettere ogni responsabilità nello strumento giusto.
La notizia di Netguru serve a ricordarci un principio antico dell'ingegneria del software: decidere lo stack non è un atto di fede, ma un atto di responsabilità. Per un founder italiano che deve portare a casa risultati con un budget contenuto, questo significa non inseguire l'hype, ma fare domande precise: che tipo di traffico avrò? Di quali integrazioni ho bisogno? Chi manterrà il codice tra un anno? Solo dopo si apre il terminale.
Conclusione
Express.js e Next.js sono entrambi eccellenti, ma rispondono a domande diverse. Per la maggior parte delle PMI italiane la scelta si gioca su tre variabili: SEO, complessità del backend e competenze interne. Valutale con calma, prototipa senza fretta e non aver paura di un'architettura ibrida se il progetto lo richiede.
Se oggi non sai da che parte iniziare o vuoi una seconda opinione prima di bloccare lo stack del tuo prossimo progetto, puoi fare un passo indietro e partire dalla diagnosi: su /diagnosi-automazione ti aiutiamo a mappare processi, vincoli e opportunità in modo da scegliere la tecnologia giusta per il tuo modello di business, non per la moda del momento.