PHP non è il problema

L'obbiettivo di questa meditazione è spiegare a persone senza background tecnico che PHP non è orrendo come viene talvolta dipinto da male informati.

Proveremo a rispondere ad alcune domande comuni, PHP ha una brutta reputazione dovuta a versioni ormai obsolete e all'esperienza di alcuni tecnici con il linguaggio quando erano ad inizio carriera.

Per farla breve, leggi la sezione TL;DR.

Incoraggia pratiche scorrette?

Non Particolarmente. In passato, molti sviluppatori che imparavano da libri e blog sono entrati in contatto con pessime pratiche, spesso la qualità del codice era particolarmente bassa. Si potevano fare in PHP cose abbastanza strane, viste con gli occhi di oggi, che erano dovute all'influenza di linguaggi preesistenti come C e Perl, cosa che rendeva facile aggiungere una montagna di codice, ma anche difficile da mantenere.

Questi non sono più problemi comuni. E' stato introdotto materiale didattico di qualità decisamente più alta, gli sviluppatori imparano fin da subito in modo più appropriato.

Molti developers junior scrivono codice difficile da mantenere perché non conoscono modi più corretti per organizzare la propria applicazione.

Con l'introduzione dei Frameworks, attorno ai primi anni 2000, la maggior parte del codice generico è gestito dal framework ed oggi ci si aspetta di dover lavorare prevalentemente sugli aspetti di business logic e front end.

Molte features sono state introdotte direttamente nel linguaggio, cosa che impedisce bad practeces che erano relativamente comuni.

Negli ultimi anni si è diffuso sia TDD che il controllo statico dei tipi (Psalm, Phan, PHPStan).

TL;DR Il linguaggio e i frameworks non incoraggiano più pratiche discutibili. PHP è evoluto molto per incorporare features presenti in altri linguaggi, purché effettivamente convenienti.

Ci sono problemi di sicurezza?

Nel passato, le applicazioni avevano più problemi di sicurezza a causa delle maggiori libertà del linguaggio, ma mi sento di affermare che la situazione sia radicalmente migliorata e ci sia molta più consapevolezza e attenzione da parte della comunità di sviluppatori.

  1. Remote and Local dinamic file inclusions, specie se basato su parametri dinamici, sono molto più rare con codice basato su frameworks e composer, perché normalmente si fa fare tutto all'autoloader.
  2. Attacchi Cross-Site Scripting, in cui un utente passa JavaScript a ciò che è mostrato ad un'altro utente, erano causati dal usare direttamente html nel template senza alcun filtro o trasformazione, sono mitigati dai template systems che automaticamente fanno escaping del contenuto dinamico.
  3. Atacchi SQL Injection, dove un utente può inviare extra SQL da eseguire in una query, erano causati dall'inutilizzo di prepared statements o dal mancato filtro di dei parametri in ingresso, anche questo aspetto è gestito automaticamente dagli ORM dei framework e anche questo è molto più comune oggi che tempo fa.
  4. Attacchi CSRF (Cross-Site Request Forgeries), consistono nel ingannare un utente, già loggato, facendolo autenticare, su links appositamemente costruiti per far scattare sull'applicazione azioni pericolose e non intenzionalmente desiderate dall'utente, tipicamente un password reset. Questo tipo di attacco è automaticamente mitigato dall'inclusione e validazione di un token "nonce"/CSRF, un meccanismo per assicurare che sia un click effettivamente prodotto sul sito e non dall'esterno.

TL;DR: Non più tanto.

  1. Files inclusions sono mitigate dagli autoloader e dalla pratica di non importare files da percorsi controllabili dall'utente.
  2. XSS sono mitigati dall'uso di un liguaggio di template, un framework frontend come React, o dall'uso di altra libreria che elimini input malevolo e codifichi l'output.
  3. SQL injection sono evitate usando ORM o Prepared Statements.
  4. Attacchi CSRF sono mitigate usando token nonce, una funzionalità supportata da tutte le librerie per form e dai framework principali.

Non è forse lento?

Dipende con cosa lo vai a confrontare. Se lo compari a Java, C# o Go, possibile. Sempre che il programmatore abbia fatto un buon lavoro con il design della sua applicazione e non è sempre il caso se ha usato bloatware, cosa molto frequente.

Ma comapri PHP con linguaggi interpretati come Python, Ruby, Node etc. no, non è lento. Nella sua classe di linguaggi è piuttosto performante e migliora di release in release, solo Node può essere più veloce se utilizzato correttamente, cosa che non è da dare per scontato.

Il più delle volte l'applicazione è lenta perché

queste sono cause indipendenti dal linguaggio.

TL;DR PHP è relativamente lento confrontato a linguaggi compilati ma relativamente veloce rispetto ad altri linguaggi di scripting.

Se correttamente progettata difficilemente è la parte applicativa in php ad essere il collo di bottiglia, più probabilemnte il problema sarà sul database.

Non scala

In realtà qualunque linguaggio può scalare, è piuttosto una questione economica. Vero che linguaggi compilati tipo Go, Java, o C# possono scalare con meno server rispetto a un linguaggio di scripting come PHP. Ma allora costerà di più lo sviluppo e la manutenzione.

Però, questi non sono fatti per lo stesso tipo di applicazione, PHP è progettato per fare bene solo applicazioni web. Puoi scalare applicazioni fatte con ciascuno di questi usando abbastanza server. PHP consuma anche meno risorse(CPU, RAM) di altri linguaggi di scripting per cui alla fine può scalare con meno server totali.

Inoltre per scalare una applicazione il collo di bottiglia inevitabilmente sarà il database. Il database è più difficile da scalare degli application server.

TL;DR Scalare non è una questione di linguaggi, tutti scalano. Il problema principale è scalare il database, non il linguaggio applicativo. Se puoi scalare il database scalerà anche l'applicazione.

Posso usarlo per tutto?

No. Ogni linguaggio moderno è progettato per fare bene in una nicchia applicativa. PHP è molto valido per fare applicazioni web, API e CLI.

  1. Se stai realizzando una system application dove conta ogni ms che puoi spremere, Rust e C/C++ sono probabilmente la scelta migliore.
  2. Se stati realizzando una applicazione AI, Python è una buona selta.
  3. Se stati realizzando una applicazione Andropid, Kotlin o Dart sono una buona opzione.
  4. Se stai realizzando una apllicazione multipiattaforma, Java è una buona opzione.
  5. Se stati realizzando una applicazione web, PHP è una opzione difficile da battere.

TL;DR No, ogni linguaggio ha la sua nicchia. La nicchia di PHP sono le applicazioni web.

Conclusione

Molte delle leggende che circolano su PHP sono obsolete di 10 anni almeno.

E' mia opinione che se qualcuno ripete opinioni superate da così tanto tempo in qualunque campo, non sia un gran che come consigliere tecnico.

PHP è perfettamente in pari con la concorrenza per la realizzazione di applicazioni web e credo sia una ottima scelta per questa nicchia applicativa.

TL;DR La maggior parte delle valutazioni che sono ripetute acriticamente nel web sono superate da almeno 10 anni. PHP è a mia opinione oggi, sommato tutto, sia aspetti tecnici che economici, lo strumento più efficace per scrivere applicazioni web.


Tags:
PHP

Blog Disclaimer:

Le opinioni espresse nel mio blog sono solo questo: mie opinioni.

In nessun modo rappresento le opinioni dei miei clienti in questa sede.


Notice: Undefined variable: browserName in /var/www/taziomirandola.it/lib/Visitors.php on line 86

Notice: Undefined variable: browserName in /var/www/taziomirandola.it/lib/Visitors.php on line 96

Deprecated: strripos(): Non-string needles will be interpreted as strings in the future. Use an explicit chr() call to preserve the current behavior in /var/www/taziomirandola.it/lib/Visitors.php on line 96

Notice: Undefined index: HTTP_ACCEPT_LANGUAGE in /var/www/taziomirandola.it/lib/Visitors.php on line 39

Fatal error: Uncaught TypeError: Argument 1 passed to safe_text() must be of the type string, null given, called in /var/www/taziomirandola.it/lib/Visitors.php on line 39 and defined in /var/www/taziomirandola.it/lib/Visitors.php:162 Stack trace: #0 /var/www/taziomirandola.it/lib/Visitors.php(39): safe_text() #1 /var/www/taziomirandola.it/lib/Visitors.php(124): Visitors::getData() #2 [internal function]: Visitors::log() #3 {main} thrown in /var/www/taziomirandola.it/lib/Visitors.php on line 162