La storia di Rasmus Lerdorf e PHP: come un piccolo insieme di script web si trasformò in una piattaforma ampiamente usata e perché PHP continua a alimentare molti siti oggi.
PHP non iniziò come una piattaforma grandiosa o un linguaggio pianificato con cura. È nato perché Rasmus Lerdorf voleva risolvere un problema concreto: gestire un sito personale senza fare lavori manuali ripetitivi.
Questo dettaglio è importante perché spiega molte cose sul perché PHP si comporta come si comporta—ancora oggi.
Lerdorf era uno sviluppatore che lavorava per il web dei primi anni, quando le pagine erano per lo più statiche e aggiornare qualsiasi cosa oltre il semplice HTML diventava rapidamente tedioso. Voleva script semplici che potessero tracciare i visitatori, riutilizzare parti comuni della pagina e generare contenuto in modo dinamico.
In altre parole: voleva strumenti che lo aiutassero a pubblicare cambiamenti più velocemente.
“Strumenti personali” non era un marchio—era una mentalità. I primi costruttori web spesso scrivevano piccole utility per automatizzare le parti noiose:
Le prime versioni di PHP furono plasmate da quell'approccio pratico e orientato al risultato.
Una volta conosciute le radici di PHP, molte delle sue caratteristiche hanno più senso: la tendenza a incorporare codice direttamente nell'HTML, la vasta libreria standard pensata per compiti web comuni e la preferenza per la praticità rispetto alla purezza accademica.
Queste scelte aiutarono PHP a diffondersi rapidamente, ma introdussero anche dei compromessi che esamineremo più avanti.
Questo articolo descrive come PHP sia cresciuto dagli script di Lerdorf a un linguaggio guidato dalla comunità, perché si adattò così bene all'hosting e allo stack LAMP, come ecosistemi come WordPress lo abbiano amplificato e cosa hanno introdotto PHP 7 e 8+—così potrai giudicare PHP oggi basandoti sulla realtà, non sulla nostalgia o sull'hype.
Il web di metà anni '90 era per lo più HTML statico. Se volevi qualcosa di dinamico—elaborare un form, mostrare un contatore, personalizzare una pagina per visitatore—di solito si ricorreva a script CGI, spesso scritti in Perl.
Questo funzionava, ma non era fluido.
I programmi CGI venivano eseguiti come processi separati per ogni richiesta. Per compiti semplici ciò significava molte parti: un file script con permessi accurati, configurazioni del server e un modello mentale che non sembrava affatto “scrivere una pagina web.” Non si mescolava solo un po' di logica nell'HTML; si costruiva un piccolo programma che emetteva HTML come testo.
Per siti hobbistici e piccole aziende, i bisogni comuni erano ripetitivi e pratici:
La maggior parte delle persone era su hosting condiviso con CPU e memoria limitate e poco controllo sulle impostazioni del server. Installare moduli personalizzati o servizi a lunga esecuzione non era realistico. Quello che si poteva fare era caricare file ed eseguire script semplici.
Questi vincoli spinsero verso uno strumento che:
Quel divario—tra pagine statiche e scripting pesante—era il problema quotidiano che PHP cercò di risolvere.
Rasmus Lerdorf non mirava a inventare un linguaggio di programmazione. Voleva qualcosa di molto più ordinario: un modo migliore di gestire il suo sito.
Il lavoro iniziale chiamato “PHP” era una raccolta di piccoli programmi in C che usava per tracciare le visite al suo curriculum online, più alcune utility per gestire compiti basilari del sito senza modificare continuamente le pagine a mano.
All'epoca sapere chi visitava il tuo sito (e quanto spesso) non era semplice come inserire uno snippet di analytics. Gli script di Lerdorf aiutavano a registrare e riassumere le richieste, rendendo più semplice capire i pattern di traffico.
Parallelamente costruì helper per compiti comuni — templating semplice, piccoli output dinamici e gestione dei form — così il sito poteva sembrare “vivo” senza diventare una applicazione completa.
Una volta che hai strumenti per tracciare le richieste, processare form e riutilizzare componenti di pagina, hai per sbaglio costruito qualcosa che altri possono usare.
Questo è il momento chiave: la funzionalità non era legata a un singolo layout o a una pagina. Era abbastanza generale perché altri proprietari di siti potessero immaginare di adottarla per i loro progetti.
Perché nacque come una cassetta degli attrezzi, l'ergonomia fu pratica: fai la cosa comune velocemente, non sovra-progettarla e mantieni bassa la barriera d'ingresso.
Quell'atteggiamento—utilità prima, rifinitura dopo—rese PHP da subito accessibile.
La lezione è semplice: le radici di PHP non erano accademiche o teoriche. Erano guidate dal problema, pensate per far funzionare un sito reale con meno attriti.
PHP non iniziò come un “linguaggio” nel senso moderno. La prima pietra pubblica fu PHP/FI, che stava per “Personal Home Page / Forms Interpreter.”
Quel nome è rivelatore: non cercava di essere tutto. Doveva aiutare a costruire pagine dinamiche e processare form senza scrivere un programma completo per ogni compito.
PHP/FI combinava alcune idee pratiche che insieme rendevano lo sviluppo web iniziale molto meno doloroso:
Non era rifinito, ma riduceva la quantità di codice di collegamento che le persone dovevano scrivere per far funzionare una pagina.
I siti iniziali raggiungevano un limite non appena si volevano feedback, guestbook, iscrizioni o ricerche: serviva accettare input dall'utente e farci qualcosa.
PHP/FI rese la gestione dei form un caso d'uso centrale. Invece di trattare i form come una feature avanzata, ci puntò—rendendo più semplice leggere i valori inviati e generare una pagina di risposta.
Questa attenzione corrispondeva a ciò che i proprietari di siti cercavano realmente di costruire.
Una delle idee più influenti di PHP/FI fu il suo stile di templating: mantenere l'HTML come documento principale e intrecciare piccoli pezzi di logica server.
<!-- HTML-first, with small dynamic pieces -->
<p>Hello, <?php echo $name; ?>!</p>
Per designer e sperimentatori, questo risultava naturale: si poteva modificare una pagina e aggiungere “giusto il necessario” di comportamento dinamico senza adottare un sistema completamente separato.
PHP/FI non era elegante né voleva esserlo. Le persone lo adottarono perché era:
Quelle caratteristiche “vincenti” non erano appariscenti—erano esattamente ciò di cui il web iniziale aveva bisogno.
Gli script iniziali di Rasmus Lerdorf servivano ai suoi bisogni: tracciare visitatori, riutilizzare componenti e evitare lavoro ripetitivo.
Ciò che trasformò quel piccolo insieme di utility in “PHP” come lo conosciamo non fu una singola riscrittura enorme—fu una progressiva adozione da parte di altri sviluppatori che volevano la stessa praticità per i loro siti.
Appena PHP fu reso pubblico, gli utenti iniziarono a inviare correzioni, piccole funzioni e idee. Questo ciclo di feedback fu cruciale: il progetto iniziò a riflettere i bisogni di molti webmaster invece che di un singolo sito.
La documentazione migliorò, i casi limite vennero sistemati e il linguaggio cominciò a sviluppare convenzioni che lo resero più semplice da apprendere e usare.
Un punto di svolta fu PHP 3, che riscrisse il motore centrale e introdusse il nome “PHP: Hypertext Preprocessor.” Non fu solo branding.
La riscrittura rese il linguaggio più coerente e più facile da estendere, permettendo a PHP di crescere senza trasformarsi in un ammasso ingovernabile di script uno‑a‑uno.
Una comunità più ampia spinse anche per integrazioni con gli strumenti che gli sviluppatori usavano. Apparvero estensioni che collegavano PHP a diversi database e servizi, così non si era vincolati a un'unica configurazione.
Piuttosto che “un tool che emette HTML,” PHP divenne un modo pratico per costruire siti guidati dai dati—guestbook, forum, cataloghi e primi e‑commerce.
Questo fu il salto chiave: i contributi della comunità non aggiunsero solo funzionalità; modificarono il ruolo di PHP da scatola di attrezzi a piattaforma condivisa su cui puntare progetti reali.
PHP non divenne la scelta predefinita per tanti siti solo perché era facile da imparare. Una parte importante della storia è che il “motore” sotto il cofano venne aggiornato seriamente—rendendo PHP più veloce, coerente e estendibile.
Zend (fondato da Andi Gutmans e Zeev Suraski) introdusse il Zend Engine come nuovo nucleo di PHP. Pensalo come cambiare il motore mantenendo lo stesso modello di auto.
Gli sviluppatori potevano ancora scrivere codice familiare, ma il runtime era meglio strutturato internamente.
Questa struttura permise:
PHP 4 (alimentato da Zend Engine 1) arrivò al momento giusto per il modello web basato su “affitta una parte di server”.
I provider di hosting condiviso poterono offrire PHP in modo economico e molti lo fecero. Questa disponibilità creò un circolo virtuoso: più host supportavano PHP, più persone lo usavano; più uso spingeva gli host a mantenerne il supporto.
In termini pratici, PHP 4 era “abbastanza buono, ovunque.” Quell'ubiquità contò tanto quanto qualsiasi caratteristica del linguaggio.
PHP 5 (Zend Engine 2) spinse PHP verso progetti più grandi. La novità principale fu la programmazione orientata agli oggetti più solida: gestione delle classi migliorata, regole di visibilità e una base per pattern più moderni.
Non si trattava di rendere PHP accademico—ma di facilitarne l'organizzazione di progetti reali, il riuso del codice e la manutenzione delle applicazioni nel tempo.
Con la diffusione di PHP emerse una nuova pressione: la gente iniziò a dare per scontato che il codice vecchio continuasse a funzionare. Provider di hosting, CMS e agenzie dipendevano da questa stabilità.
Da quel momento l'evoluzione di PHP non fu solo “aggiungi funzionalità”—fu anche “non rompere il web.”
PHP non vinse perché fosse il linguaggio più elegante sulla carta. Vinse perché rendeva la costruzione di pagine utili immediata.
Per i primi sviluppatori web—spesso designer, hobbisti o piccole imprese—PHP ridusse il tempo per arrivare al primo risultato funzionante più di quasi ogni alternativa.
Con PHP il ciclo di feedback era quasi senza attrito: carica un file, aggiorna la pagina, vedi il risultato. Può sembrare banale, ma plasmò una generazione di costruzione web.
Si poteva partire con una singola pagina dinamica (un form di contatto, un guestbook, un contatore) e crescere da lì.
I progetti web iniziali raramente avevano grandi reparti tecnici. C'era uno sviluppatore, forse due, e una pila di richieste urgenti.
PHP si adattava a questa realtà: riduceva la burocrazia intorno al deploy e rendeva facili le modifiche incrementali.
PHP cavalcò l'ondata degli hosting condivisi economici. Molti provider lo preinstallavano, quindi non serviva infrastruttura speciale o server costosi.
Distribuire spesso significava “copiare i file”, che era in linea con il modo in cui già si pubblicava l'HTML.
Con la diffusione di PHP, crebbe anche la memoria collettiva: tutorial, snippet, forum ed esempi copy‑paste erano ovunque.
Questa conoscenza comunitaria rese PHP accessibile—anche quando i problemi web sottostanti non lo erano affatto.
PHP non ebbe successo solo perché era facile da apprendere—ebbe successo perché aveva una “casa predefinita” nel web iniziale.
Quella casa era lo stack LAMP: Linux + Apache + MySQL + PHP. Per anni questa combinazione fu la ricetta standard per eseguire siti dinamici, specialmente per piccole aziende e progetti personali.
Linux e Apache erano ampiamente disponibili e economici da gestire. PHP si integrava perfettamente nel modello request/response di Apache: un visitatore richiedeva un URL, Apache passava la richiesta a PHP e PHP generava HTML al volo.
Non c'era un application server separato da gestire, il che manteneva deployment semplici ed economici.
MySQL completava il quadro. Le estensioni di accesso al database in PHP rendevano semplice connettersi a MySQL, eseguire query e rendere i risultati in una pagina.
Quell'integrazione stretta significò che una grande percentuale di siti “con database” poteva essere costruita con gli stessi strumenti familiari.
Un acceleratore importante fu l'hosting condiviso. Molti host offrivano account dove PHP e MySQL erano già configurati—nessuna amministrazione di sistema richiesta.
Con pannelli di controllo come cPanel gli utenti potevano creare un database MySQL, gestire tabelle con phpMyAdmin, caricare file PHP via FTP e andare online rapidamente.
Poi arrivarono gli installer con un click (spesso per WordPress, forum e carrelli). Questi normalizzarono l'idea che “un sito è un'app PHP + un database MySQL”, rendendo PHP la via più semplice per milioni di proprietari di siti.
Lo stack incoraggiò un flusso pratico: modifica un file .php, ricarica il browser, aggiusta SQL, ripeti.
Ha anche modellato pattern familiari—template e include, gestione dei form, sessioni e pagine CRUD—creando un modello mentale condiviso che durò ben oltre il picco di LAMP.
PHP non divenne “ovunque” solo per la sintassi. Divenne la scelta predefinita perché si formarono prodotti completi e installabili attorno ad esso—strumenti che risolvevano problemi reali con setup minimo.
I sistemi di gestione dei contenuti trasformarono PHP in una decisione da un click. Piattaforme come WordPress, Drupal e Joomla raggruppavano le parti difficili—pannelli di amministrazione, login, permessi, temi, plugin—così un proprietario di sito poteva pubblicare senza scrivere codice.
Questo creò una propria gravità: designer impararono a creare temi, le agenzie costruirono offerte ripetibili e i marketplace di plugin crebbero.
Una volta che il sito di un cliente dipendeva da quell'ecosistema, PHP veniva “scelto” di nuovo e di nuovo—talvolta senza che il cliente ne fosse consapevole.
Negozi online e siti di comunità furono elementi essenziali del web iniziale, e PHP si adattava alla realtà dell'hosting condiviso dell'epoca.
Software come Magento (e in seguito WooCommerce su WordPress), oltre a forum come phpBB, diedero soluzioni pronte per cataloghi, carrelli, account e moderazione.
Questi progetti normalizzarono anche il flusso dove installi un'app, la configuri via browser e la estendi con moduli—esattamente il tipo di sviluppo che fece prosperare PHP.
Non tutto il PHP è rivolto al pubblico. Molti team lo usano per dashboard interne, strumenti amministrativi e API semplici che collegano pagamenti, inventario, CRM o analytics.
Questi sistemi non compaiono negli scanner “che CMS usa questo sito?”, ma mantengono PHP nell'uso quotidiano.
Quando una grande fetta del web gira su pochi prodotti massivi (soprattutto WordPress), il linguaggio sottostante eredita quella diffusione.
La portata di PHP è, in larga parte, la portata degli ecosistemi costruiti sopra di esso—non solo una riflessione del linguaggio stesso.
Il successo di PHP è sempre stato legato al pragmatismo—e il pragmatismo spesso lascia dei margini grezzi.
Molte critiche nascono da una storia reale, ma non tutte riflettono come PHP viene usato (o scritto) oggi.
Una lamentela frequente è l'inconsistenza: nomi di funzione che seguono pattern diversi, parametri in ordine differente e API vecchie che convivono con quelle nuove.
Questo non è immaginario—è il risultato di una crescita rapida, aggiunta di funzionalità con l'evoluzione del web e della necessità di mantenere interfacce vecchie per milioni di siti esistenti.
PHP supporta anche stili di programmazione multipli. Puoi scrivere semplici script “fai che funzioni” o codice più strutturato e orientato agli oggetti.
I critici lo chiamano “paradigmi misti”; i sostenitori lo chiamano flessibilità. Il rovescio della medaglia è che i team possono finire con codice di qualità disomogenea se non stabiliscono standard.
“PHP è insicuro” è una semplificazione eccessiva. La maggior parte degli incidenti di sicurezza in PHP deriva da errori applicativi: fidarsi dell'input utente, costruire query SQL concatenando stringhe, configurare male l'upload di file o dimenticare controlli di accesso.
I default storici di PHP non sempre indirizzavano i principianti verso pratiche sicure, e la sua facilità d'uso fece sì che molti principianti mettessero in produzione codice pubblico.
Una lettura più accurata: PHP rende facile costruire app web, e le app web sono facili da sbagliare senza una buona igiene della sicurezza.
PHP ha avuto la grande responsabilità di non rompere il web.
Questa retrocompatibilità mantiene app in vita per anni, ma significa anche che il codice legacy resta spesso in giro—talvolta molto oltre la sua “data di scadenza”. Le aziende possono quindi spendere più energie a mantenere vecchi pattern che ad adottare pratiche migliori.
Critica giusta: inconsistenza, API legacy e codebase disomogenee sono reali.
Critica datata: assumere che i progetti PHP moderni debbano assomigliare al PHP dei primi anni 2000 o che il linguaggio sia la principale debolezza di sicurezza.
In pratica, la differenza è quasi sempre nelle pratiche del team, non nello strumento.
La reputazione di PHP è spesso legata a codice scritto anni fa: HTML e logica nello stesso file, stili incoerenti e “funziona sul mio server” come abitudine.
PHP 7 e 8+ non hanno introdotto solo feature—hanno spinto l'ecosistema verso lavori più puliti, veloci e mantenibili.
PHP 7 portò miglioramenti di performance significativi ridisegnando parti critiche delle internals.
In termini pratici: la stessa app poteva servire più richieste con la stessa macchina, o costare meno per lo stesso traffico.
Questo fu importante per hosting condiviso, siti WordPress molto trafficati e qualsiasi attività che misurasse il tempo di caricamento in vendite perse. Resuscitò anche la percezione che PHP fosse competitivo rispetto a opzioni server-side più nuove.
PHP 8 introdusse caratteristiche che rendono più semplice ragionare su codebase grandi:
int|string). Questo riduce incertezza e migliora il supporto degli strumenti.I progetti PHP moderni di solito si basano su Composer, il gestore di dipendenze standard.
Invece di copiare librerie a mano, i team dichiarano dipendenze in un file, installano versioni prevedibili e usano l'autoloading. Questo è uno dei motivi per cui il PHP contemporaneo sembra molto più “professionale” rispetto all'era del copia‑incolla.
Il vecchio PHP significava spesso script ad hoc; il PHP moderno tende a significare dipendenze versionate, framework, codice tipizzato, test automatizzati e performance adeguate al traffico reale.
PHP non è una scelta nostalgica—è uno strumento pratico che ancora si adatta molto bene a molti lavori web.
La chiave è abbinarlo ai vincoli del progetto, non all'ideologia.
PHP brilla quando stai costruendo o gestendo:
Se il tuo progetto beneficia del “molti sviluppatori già lo conoscono e l'hosting è ovunque”, PHP può ridurre gli attriti.
Considera alternative se ti servono:
Può anche valere la pena scegliere un altro stack se stai costruendo un prodotto nuovo e vuoi default forti per architetture moderne (API tipizzate, servizi strutturati e separazione chiara delle responsabilità).
Fatti queste domande prima di scegliere:
Una lezione dalla storia di PHP rimane: gli strumenti vincenti accorciano il divario tra idea e software funzionante.
Se stai valutando se continuare a investire in PHP o costruire un nuovo servizio parallelo (per esempio un frontend React con un'API in Go), un prototipo rapido può risolvere molti dubbi. Piattaforme come Koder.ai sono pensate per quel flusso “ship-first”: puoi descrivere un'app in chat, generare un progetto web o backend funzionante (React + Go con PostgreSQL) e iterare rapidamente con funzioni come modalità di pianificazione, snapshot e rollback—poi esportare il codice sorgente quando sei pronto.
Per guide pratiche, consulta /blog. Se stai confrontando opzioni di deployment o servizio, /pricing può aiutare a inquadrare i costi.
Rasmus Lerdorf costruì una serie di piccoli strumenti in C per mantenere il suo sito personale: tracciare i visitatori, riutilizzare parti di pagina e gestire semplici output dinamici.
Poiché l'obiettivo era eliminare i compiti web ripetitivi (non progettare un linguaggio “perfetto”), PHP mantenne un approccio pratico: rapido da distribuire, facile da integrare in HTML e ricco di helper focalizzati sul web.
A metà degli anni '90 la maggior parte delle pagine era HTML statico. Qualsiasi elemento dinamico (form, contatori, contenuti personalizzati) richiedeva spesso script CGI—spesso in Perl.
Questo funzionava, ma risultava scomodo per gli aggiornamenti quotidiani: normalmente si scriveva un programma separato che stampava HTML, invece di modificare una pagina HTML con piccole parti di logica lato server.
I programmi CGI solitamente venivano eseguiti come processi separati per ogni richiesta e richiedevano più configurazione (permessi, impostazioni del server e un modello mentale diverso).
PHP avvicinò l'output dinamico al concetto di “modificare una pagina web”: scrivi HTML, aggiungi piccoli frammenti lato server, carichi e aggiorni la pagina.
PHP/FI stava per “Personal Home Page / Forms Interpreter”. Era una prima versione pubblica incentrata sulla creazione di pagine dinamiche e sull'elaborazione dei form.
La sua idea chiave era poter inserire codice lato server direttamente nelle pagine offrendo allo stesso tempo comodità per i compiti web comuni (soprattutto la gestione dei form e l'accesso di base al database).
Abbassò la soglia per i non specialisti: si poteva mantenere l'HTML come documento principale e inserire piccoli pezzi dinamici (per esempio stampare un nome o iterare sui risultati).
Questo approccio era coerente con lo sviluppo su hosting condiviso: si lavorava in modo incrementale senza adottare subito un sistema di templating completamente diverso.
Non appena PHP fu condiviso pubblicamente, altri sviluppatori iniziarono a inviare correzioni, funzionalità e integrazioni.
Questo cambiò PHP da “cassetta degli attrezzi personale” a progetto guidato dalla comunità, dove i bisogni reali dei webmaster (database, estensioni, portabilità) orientarono l'evoluzione del linguaggio.
PHP 3 fu una riscrittura importante che rese PHP più coerente e facile da estendere, e introdusse il nome “PHP: Hypertext Preprocessor”.
Di fatto segnò il momento in cui PHP divenne una piattaforma più stabile ed estendibile invece di un insieme di script improvvisati.
Il Zend Engine (sviluppato da Andi Gutmans e Zeev Suraski) migliorò le internals del runtime—struttura migliore, performance superiori e una base chiara per le estensioni.
Questo permise ai provider di hosting di offrire PHP in modo più efficiente e agli sviluppatori di costruire codebase più grandi con comportamenti più prevedibili.
LAMP (Linux, Apache, MySQL, PHP) divenne la ricetta standard per siti dinamici, in particolare su hosting condiviso.
PHP si adattava bene al modello request/response di Apache e, con il supporto a MySQL, costruire pagine basate su database risultava semplice—per questo milioni di siti adottarono lo stesso stack e flusso di lavoro.
Il PHP moderno (7 e 8+) ha portato consistenti miglioramenti di performance e funzionalità che rendono il linguaggio più mantenibile, mentre Composer ha standardizzato la gestione delle dipendenze.
Valuta PHP in base ai tuoi vincoli:
Se estendi un sistema PHP esistente, modernizzarlo in modo incrementale spesso costa meno di una riscrittura completa.