Negli ultimi anni ho realizzato diversi progetti con tecnologie moderne. Ho sviluppato un e-commerce headless con Next.js che funziona perfettamente e ha dimostrato tutto il suo valore. Forte di questa esperienza positiva, ho deciso di sperimentare anche con il mio sito personale: perché non convertire l'intero progetto da PHP/MySQL a Next.js/Strapi?
L'esperimento è stato istruttivo. Molto istruttivo. Ma non nel modo che mi aspettavo.
La promessa del moderno stack JavaScript
Quando ho iniziato la conversione, ero entusiasta. Next.js promette rendering velocissimo, ottimizzazione automatica delle immagini, code splitting intelligente. Strapi offre un'interfaccia amministrativa elegante e un'API GraphQL pronta all'uso. Sulla carta, sembrava la combinazione perfetta per un sito orientato ai contenuti come il mio sito che include anche un magazine tecnico.
Ho investito giorni nel progetto. Ho configurato Strapi, definito i content types, migrato i contenuti dal database MySQL. Ho costruito i componenti Next.js, implementato la generazione statica delle pagine, ottimizzato le route. Il risultato finale funzionava. Funzionava anche bene, dal punto di vista dell'utente finale.
Ma quando ho iniziato ad analizzare i numeri reali, alcuni aspetti mi hanno fatto riflettere.
I numeri che raccontano una storia diversa
Il peso del progetto è stata la prima sorpresa. La mia installazione PHP/MySQL occupa meno di 30 MB sul server. Il progetto Next.js/Strapi, con tutte le sue dipendenze, node_modules, e file di build, aveva superato 1 GB. Per un sito che fondamentalmente serve articoli tecnici e qualche immagine ottimizzata.
Pensavo: "Vabbè, lo spazio su disco costa poco". Ma non era solo quello.
I tempi di deployment erano diventati un problema concreto. Modifico spesso i contenuti: correggo un refuso, aggiungo una precisazione, aggiorno un esempio di codice. Con PHP, modifico il file e il cambiamento è istantaneamente visibile. Con Next.js, ogni modifica richiede:
- Rebuild del progetto
- Deploy della nuova build
- Sito offline durante il deploy
Cinque minuti di downtime per correggere un refuso mi sembravano eccessivi.
Performance: quando il vecchio batte il nuovo
Qui arriva il punto che potrebbe sorprendere molti: un sito PHP ben ottimizzato può essere incredibilmente veloce. Parlo di tempi di risposta del server in millisecondi, non in secondi.
Sul mio server, con una configurazione PHP 8.3 ottimizzata (cache abilitata, query SQL indicizzate correttamente), le pagine del mio sito si caricano con tempi TTFB (Time To First Byte) di 59 ms. Un dato eccezionale.
La lezione? Le performance non dipendono principalmente dal linguaggio, ma dall'implementazione. Un PHP scritto male è lento. Un Next.js configurato male è altrettanto lento. La differenza sta nell'ottimizzazione, non nel framework.
I costi nascosti dei framework moderni
Oltre ai costi di hosting - uno spazio per un sito PHP/MySQL parte da pochi euro al mese, mentre una soluzione Node.js richiede VPS o servizi specializzati che possono costare dieci volte tanto - ci sono altri costi meno evidenti.
La manutenzione costante
I framework JavaScript si evolvono rapidamente. Troppo rapidamente. Next.js rilascia major update con breaking changes ogni anno circa. Le dipendenze del progetto richiedono aggiornamenti continui:
npm audit
# 47 vulnerabilities (12 moderate, 35 high)
Ogni settimana passavo tempo ad aggiornare pacchetti per questioni di sicurezza. Con PHP, gli aggiornamenti sono meno frequenti e più stabili. Il codice scritto oggi funzionerà identico per anni.
Il carico cognitivo delle dipendenze
Il mio progetto Next.js aveva 9 dipendenze tra dirette e transitive. Poche rispetto a progetti più complessi ma sono pacchetti sviluppati da persone diverse, con policy di sicurezza diverse, con cicli di vita diversi. Ogni dipendenza è un potenziale punto di rottura.
Con PHP, le dipendenze sono drasticamente ridotte. Per il mio sito uso:
- PHP stesso
- MySQL
- 1 libreria PHP solida e continuamente supportata
- librerie JS sviluppate da me stesso
Finito.
La volatilità dell'ecosistema JavaScript
PHP esiste dal 1995. Viene dichiarato morto da vent'anni, eppure alimenta ancora oltre il 75% dei siti web. WordPress, il CMS più diffuso al mondo, è scritto in PHP. Laravel, uno dei framework più apprezzati, è PHP. Questo linguaggio ha dimostrato una stabilità straordinaria.
I framework JavaScript, invece, seguono cicli di popolarità molto più brevi. Ricordate Backbone.js? Angular.js (non Angular, l'Angular vecchio)? Meteor? Ember? Tutti erano "il futuro" del web. Tutti sono oggi progetti legacy difficili da mantenere.
Non sto dicendo che Next.js farà la stessa fine. Ma l'ecosistema JavaScript tende a reinventarsi ciclicamente, spesso seguendo mode più che necessità tecniche concrete. Investire pesantemente in un framework significa scommettere sulla sua longevità.
Quando scegliere cosa: la tecnologia giusta per il problema giusto
La mia esperienza mi ha insegnato che non esiste la tecnologia migliore in assoluto, ma solo la tecnologia più appropriata per uno specifico contesto.
Quando Next.js/Strapi (o stack simili) hanno senso:
- Applicazioni complesse con forte interattività lato client
- Team grandi con ruoli separati (frontend/backend)
- Necessità di scalabilità estrema con architetture distribuite
- Budget adeguato per hosting e manutenzione
- Progetti enterprise con cicli di release pianificati
Per il mio e-commerce headless, Next.js è stata la scelta giusta. L'interfaccia è complessa, interattiva, con aggiornamenti real-time del carrello, filtri dinamici, checkout multi-step. Il rendering lato client ha senso.
Quando PHP/MySQL rimane imbattibile:
- Siti orientati ai contenuti (blog, magazine, portfolio)
- Progetti dove la semplicità è un valore
- Budget limitati ma con esigenze di performance
- Necessità di intervenire rapidamente sui contenuti
- Autonomia completa senza dipendenze esterne critiche
- Longevità del progetto come priorità
Per il mio sito personale, PHP era oggettivamente la scelta più razionale.
Il costo opportunità: la metrica dimenticata
C'è un ultimo aspetto che raramente viene considerato: il tempo è la risorsa più scarsa per un professionista. Ogni ora che dedico a:
- Aggiornare dipendenze
- Risolvere breaking changes dopo un update
- Debuggare problemi di build
- Ottimizzare configurazioni Webpack
È un'ora che non dedico ai progetti dei clienti o a scrivere contenuti di valore per il mio magazine. Per un freelance o una piccola agenzia, questo costo opportunità può essere devastante.
Con PHP, la manutenzione ordinaria del mio sito richiede forse un'ora al mese. Con Next.js/Strapi, stimavo almeno quattro-cinque ore al mese solo per tenere il progetto aggiornato e funzionante.
La trappola del "bisogna stare al passo"
Nel nostro settore c'è una pressione costante a utilizzare le tecnologie più recenti. Non usare l'ultimo framework JavaScript può sembrare un segnale di arretratezza tecnica. Ma questa mentalità è pericolosa.
La competenza tecnica non si misura dalla tecnologia utilizzata, ma dalla capacità di scegliere lo strumento giusto per il problema specifico. Conoscere Next.js e PHP, capire quando usare l'uno o l'altro, è più prezioso che conoscere solo l'ultimo framework di moda.
Ai miei clienti non interessa se uso PHP o Node.js. Gli interessa che il loro sito:
- Sia veloce
- Costi poco da mantenere
- Non richieda interventi continui
- Rimanga stabile negli anni
PHP mi consente di garantire tutti questi punti.
La mia esperienza con Next.js è stata preziosa. Mi ha insegnato molto sui pattern moderni di sviluppo, sul rendering lato server, sull'ottimizzazione delle performance. E continuerò a usare Next.js per progetti dove ha senso.
Ma mi ha anche insegnato l'umiltà tecnologica: riconoscere che una tecnologia "vecchia" può essere la scelta più moderna per uno specifico contesto. PHP non è sexy, non genera articoli su Hacker News, non fa CV impressionanti. Ma funziona. Funziona maledettamente bene.
Nel 2026, mentre l'industria continua a inseguire il prossimo grande framework, io servo tranquillamente i miei articoli tecnici in 200 millisecondi con una soluzione che esiste da trent'anni. E ai miei lettori, onestamente, non importa se sotto il cofano c'è PHP o JavaScript.
La tecnologia migliore è quella che risolve il problema nel modo più efficiente possibile. A volte quella tecnologia ha trent'anni. E va benissimo così.