PHP non è morto: cosa ci ha lasciato il PHPDay 2026

Alla fine di ogni edizione del PHPDay c’è un rituale che si ripete: qualcuno, da qualche parte, sta scrivendo l’ennesimo necrologio del linguaggio. E ogni volta torniamo a casa con la stessa convinzione, nemmeno questa volta PHP è morto. Non è una battuta consolatoria. È quello che si è visto sul palco dell’edizione 2026: un processo di rilascio governato con disciplina, framework agentici in piena competizione, real-time spinto fino a QUIC, e una community che decide consapevolmente quando rompere il proprio passato.

La narrazione del declino di PHP rispetto a Python e Node.js si trascina da anni. È comoda, perché si appoggia ai ranking di popolarità, e fragile, perché confonde la moda con la maturità. La vitalità di un linguaggio non si misura su quante nuove leve lo scelgono per il primo progetto, ma sulla qualità del processo con cui evolve e sulla solidità degli strumenti che lo circondano.

Il PHPDay 2026¹ è stato esattamente questo: una fotografia di un ecosistema adulto. Attraversiamo i talk che lo raccontano meglio, partendo dalla domanda più scomoda di tutte: come decide di evolvere un linguaggio vivo?

Un linguaggio che evolve è un linguaggio che decide come rompere il proprio passato

La prima prova di maturità non è una feature. È un processo.

In “Shipping PHP 8.5”, Volker, release manager di PHP 8.5², ha fatto una cosa rara per un talk tecnico: ha parlato meno delle novità del linguaggio e più del come si decide cosa entra in una release e come la si “spedisce”. La nuova estensione nativa per la gestione degli URI conforme a RFC 3986³, per esempio, non nasce da una scelta individuale ma da un percorso pubblico di proposta, discussione e voto. Capire questo meccanismo conta più di memorizzare la singola funzione: dice che PHP non viene “gestito” da un vendor, ma deliberato da una comunità.

Quel meccanismo è diventato palpabile nel “Panel: the future of PHP”, dove Volker, Gary, Gina, Derick e Sara hanno discusso proposte ancora aperte: i generics con type erasure, le scope functions e il pattern matching. Si può essere d’accordo o meno con ogni singola RFC, ma il messaggio del panel era inequivocabile: PHP evolve grazie alla sua community, e l’invito a iscriversi alla mailing list e contribuire non era retorica, era una richiesta operativa.

Il keynote di chiusura di Gina, “Progress lies within Backwards Compatibility breaks”, ha messo a fuoco la verità che spesso preferiamo ignorare: rompere la backwards compatibility è il prezzo necessario e inevitabile del progresso. Gina ha usato analogie con altri settori, il trasporto ferroviario, l’elettricità, che a volte ricostruiscono intere infrastrutture per semplificare le integrazioni e ridurre i costi di manutenzione nel lungo periodo. Trattare le breaking changes come incidenti significa condannarsi al debito tecnico; trattarle come investimenti significa progettare per durare.

Chi gestisce PHP in produzione conosce bene questa dinamica. Quando Drupal 10⁴ è uscito il 14 dicembre 2022 adottando Symfony 6⁵ e alzando il requisito minimo a PHP 8.1⁶, l’intero ecosistema ha dovuto adeguarsi. È un caso reale di come l’evoluzione del linguaggio si propaghi sui grandi CMS, un tema che approfondiamo parlando della nuova era del content management con Drupal CMS. E proprio qui sta la differenza tra subire una breaking change e governarla: strumenti come Rector per il refactoring automatico, PHPStan e Psalm per l’analisi statica permettono di individuare il codice deprecato prima della migrazione, trasformando un salto traumatico in un percorso pianificato.

Un linguaggio che si riprogetta non lo fa nel vuoto. Lo fa per stare sui fronti più caldi del software contemporaneo.

PHP sulle nuove frontiere: AI agentica e comunicazione real-time

L’ecosistema PHP si muove rapidamente sul terreno dei framework agentici. Un framework agentico, per chi non lavora con l’AI quotidianamente, è l’infrastruttura che permette a un Large Language Model di non limitarsi a rispondere, ma di compiere azioni: invocare strumenti, consultare fonti, orchestrare passaggi multipli verso un obiettivo.

Nel talk “The PHP AI Battleground: Choosing Your Agentic Framework”, il nostro Luca Lusso, lead developer di SparkFabrik, ha confrontato tre framework PHP promettenti per i workflow agentici: Laravel AI, Symfony AI e Neuron AI. Ognuno ha pro e contro, e nessuno è la risposta universale. Laravel AI si integra naturalmente con chi vive già nell’ecosistema Laravel; Symfony AI porta il rigore architetturale di Symfony nel dominio degli agenti; Neuron AI nasce più snello e focalizzato. La scelta dipende dallo stack già in uso e dai requisiti del workflow. (Approfondiamo il framework Neuron AI nel nostro webinar dedicato “Costruire agenti AI in PHP con Neuron AI”)

C’è chi legge questa pluralità come frammentazione. Noi la leggiamo all’opposto: tre framework concorrenti sono il segnale di un ecosistema in fermento, che sta scegliendo la propria direzione invece di subirla. Il punto critico arriva nella fase successiva: portare un agente in produzione significa governare un sistema probabilistico, e questo richiede pratiche di osservabilità dedicate, come quelle che descriviamo parlando di AgentOps, dal monitoraggio del consumo di token al rilevamento delle allucinazioni.

La stessa vitalità si è vista sul real-time. In “PHP’s Real-time Toolkit: All the Ways to Notify Clients”, Grzegorz ha ripercorso tutte le strade per spingere dati dal server al client: dal vecchio polling fino ai pattern moderni come WebSocket e Server-Sent Events (SSE), indicando come futuro il WebTransport basato su QUIC⁷ su HTTP/3. Nel suo intervento ha citato Mercure, presentato come soluzione basata sul meccanismo dei Server-Sent Events, e due alternative più strutturate:

• Centrifugo: una piattaforma che supporta molti protocolli, scala bene e gestisce fallback automatici, al prezzo di dover far girare un server separato.

• Nchan: un modulo Nginx concettualmente simile a Centrifugo, ma decisamente più scalabile.

Anche qui, la varietà non è dispersione. È un ecosistema che offre lo strumento giusto per ogni vincolo di scala e infrastruttura.

L’innovazione senza solidità resta fragile. La vera maturità di PHP nel 2026 si vede nei dettagli ingegneristici meno appariscenti.

La maturità sta nei dettagli: dati, serializzazione e resilienza

Ciò che rende un linguaggio adatto alla produzione non sono le feature di facciata. È la capacità di gestire dati a volume, performance ed errori con disciplina. Il PHPDay 2026 ha dedicato a questi temi alcuni dei talk più densi, proprio quelli che non finiscono mai sui titoli.

Si parte dal dato grezzo. In “Data Processing in PHP”, Norbert ha mostrato come estrarre e processare grandi volumi di dati in modo efficiente ed economico, partendo dalle funzioni native di PHP per gestire un semplice file CSV fino a processi ETL completi costruiti con flow-php, lo strumento che ha sviluppato. Il messaggio: PHP regge carichi di dati seri, se sai come strutturare il flusso.

Poi c’è il problema della velocità. Michelle, in “Advanced Serializing in PHP: Speed it up!”, ha confrontato diverse tecniche di serializzazione partendo da un dato controintuitivo: il Symfony Serializer è il più potente ma anche il più lento, perché usa la reflection per accedere allo stato degli oggetti a runtime. La soluzione è spostare la complessità al code time, generando codice PHP veloce, prima con liip/serializer e oggi con il suo successore rebuy-oss/serializer. Il team di Michelle è andato oltre, costruendo un convertitore da PHP a Go per eseguire la fase di serializzazione in Go e spremere ulteriore velocità. È il tipo di ingegneria che si fa solo quando un linguaggio è già in produzione su sistemi che contano.

Infine, la resilienza. In “Mastering Failures: Building Resilient PHP/Symfony Apps with Domain-Driven Exceptions”, Stephane ha insegnato i pattern corretti per le eccezioni di dominio in architetture Domain-Driven Design: non lanciare eccezioni generiche, non fare il parsing dei messaggi di errore per capire cosa è successo, definire un’eccezione specifica per ogni problema reale del dominio. Il suo consiglio più tagliente:

Non lanciare NotFoundHttpException dentro un dominio, perché lo stesso codice potrebbe girare anche in un’applicazione CLI.

È un dettaglio che separa un progetto giocattolo da un sistema enterprise, lo stesso rigore di disaccoppiamento che ritroviamo nelle scelte tra monolite e microservizi. Questi sono i temi su cui si misura se una community è adulta. E PHP, qui, lo è.

Ma PHP non è in declino rispetto a Python e Node? Il fattore che le classifiche ignorano

Affrontiamo l’obiezione più forte senza scappare. È vero: la percezione pubblica vede PHP in declino. I nuovi sviluppatori gravitano verso JavaScript e Python, l’AI e la data science hanno reso Python lo stack di default per intere categorie di progetti, e i ranking di popolarità raccontano una parabola discendente. Ignorarlo sarebbe disonesto.

Eppure le classifiche misurano la moda, non la maturità. I numeri raccontano un’altra storia: PHP resta il linguaggio server-side di circa il 77% dei siti web con un backend rilevabile, e da solo WordPress⁸ alimenta oltre il 43% del web. Aggiungendo Magento nell’e-commerce, Symfony e Laravel nell’enterprise, Drupal nei portali complessi, la presunta fine assume contorni piuttosto vivaci.

Il punto vero non sono nemmeno questi numeri. Sono i fondamentali.

In “Packets, Protocols and PHP: Networking Fundamentals for Developers”, Jessica ha guidato un tour dei layer di rete, dall’Application al Physical del modello OSI, con la verità che ogni sysadmin conosce: “it’s always DNS (or BGP, or more often, both)”. I fondamentali di rete non passano di moda e prescindono dal linguaggio. Chi li padroneggia è un ingegnere migliore, qualunque stack scelga.

La solidità di un ecosistema si legge nel suo tooling. Derick, creatore di Xdebug, in “Better Debugging With Xdebug” ha mostrato dal vivo le novità di Xdebug 3.5⁹: Native Path Mapping, out of band signalling, automatic line discovery e altro, come dettagliato nell’annuncio ufficiale. Un tool di debug così curato è la prova di una community che investe sulla qualità, non solo sulle feature. È lo stesso impegno che come Drupal Certified Partner Gold portiamo nel mantenimento di WebProfiler, il modulo di debug per Drupal con oltre 1.000 installazioni attive.

Il giudizio fa la differenza. Gary, in “It Depends”, ha condotto una sessione interattiva sulle decisioni critiche che ogni sviluppatore affronta ogni giorno: monolite o microservizi, codice scritto a mano o generato dall’AI, framework opinionated o non opinionated. La conclusione, onesta e disarmante, è il titolo stesso: alla fine, it depends. La maturità non è un dogma, è giudizio contestuale.

Infine, le persone. Carolina, psicologa, ha tenuto “Communication for devs: explaining complex ideas simply”, un keynote interattivo in cui abbiamo provato a migliorare la nostra capacità di spiegare: raccontare una storia al vicino di posto, usare un’analogia, inquadrare le idee dalla prospettiva di chi ascolta. Il segreto più importante, ha detto, è respirare.

Le classifiche misurano la popolarità. Un linguaggio adulto si misura sui fondamentali, sul tooling e sulle persone. Ed è esattamente su questi assi che PHP, nel 2026, è solidissimo.

Cosa resta del PHPDay 2026

“PHP non è morto” non è una rassicurazione difensiva. È la constatazione di un fatto: un linguaggio capace di rompere consapevolmente il proprio passato per progredire, come ha argomentato Gina, di competere sui framework agentici e sul real-time, e al tempo stesso di coltivare con disciplina i propri fondamentali, è un linguaggio profondamente vivo.

Il vero rischio non è la fine di PHP. È che la community smetta di partecipare. L’invito emerso dal panel, iscriversi alla mailing list, discutere le RFC, contribuire, non era un dettaglio cerimoniale: è il motore stesso che tiene il linguaggio in vita.

Dalla nostra esperienza su codebase PHP enterprise in produzione, questa lettura è la stessa che vediamo confermata ogni giorno sul campo. La domanda giusta, uscendo dal PHPDay 2026, non è “PHP è morto?”. È: abbiamo la maturità tecnica e umana per usarlo come merita?

Note e fonti