Php, Python, Ruby per lo sviluppo web. Un’analisi.

Pochi giorni fa ho pubblicato un video confronto, a mio parere molto interessante, tra J2EE, Ruby On Rails, Zope, Turbogears e Django. I linguaggi utilizzati da queste piattaforme di sviluppo sono Java, Ruby e Python, manca il linguaggio di programmazione per il web più conosciuto, sicuramente quello più utilizzato dagli utenti che con la programmazione hanno meno a che fare: PHP.

No, non preoccupatevi, non intendo scrivere l’ennesimo articolo che mette a confronto le peculiarità ed i punti di forza di tutti questi linguaggi di programmazione cercando poi di nominare un vincitore assoluto, vorrei invece concentrarmi su aspetti che a volte sono ritenuti secondari ma che invece molto spesso sono alla base del successo di molte tecnologie.

A scanso di equivoci vi dico subito che tra questi tre linguaggi il mio preferito è Python: mi piace la sintassi elegante, la disponibilità di librerie, la maggiore disponibilità di documentazione (esistono ad esempio molti libri e fonti per Wxpython quasi nulla di corrispondente per Ruby). In generale è una questione di “comfort”, ed io mi trovo bene con Python, tuttavia ritengo che Ruby abbia alcune caratteristiche che lo rendono altrettanto interessante, non ultima il fatto che sia un linguaggio completamente ad oggetti ed un paio di cose riguardo l’eleganza della sintassi. Tuttavia l’unico linguaggio che effettivamente utilizzo in ambienti di produzione per lo sviluppo di applicazioni web è il PHP.

Il problema base di Python e Ruby e di tutti i framework e template engine disponibili per questi linguaggi è uno solo: facilità di distribuzione.



Mi spiego meglio: se io volessi realizzare un servizio web come twitter e reddit molto probabilmente punterei ad una qualche soluzione basata su Python o Ruby, magari un framework come Django o Ruby On Rails. Probabilmente, per una mera questione di flessibilità, di libertà e di pieno controllo dell’applicativo, avendo tempo e denaro cercherei di sviluppare una soluzione tagliata specificamente per le mie esigenze.

Ma farei la stessa scelta se dovessi sviluppare una piattaforma di blogging che faccia concorrenza a Wordpress, un cms che contrasti Joomla o Drupal, una piattaforma per forum come Phpbb o un programma in grado di gestire una galleria di immagini come Gallery? Probabilmente no.

La forza di applicativi come wordpress è dovuta non soltanto all’enorme disponibilità di plugin ed estensioni, facilitata anche dall’enorme numero di sviluppatori con competenze in php (aspetto da non sottovalutare) ma soprattutto dalla facilità con cui anche un utente con conoscenze quasi nulle di informatica è in grado di portare a termine l’installazione e la configurazione di wordpress su di uno spazio web personale (il famoso 5 minutes install, senza considerare che molti hosting provider forniscono script automatici di installazione per wordpress ed altre piattaforme sviluppate in php).



Provate a fare lo stesso con Django e Ruby On Rails, per i quali sono disponibili interi how-to di deployment pensati non per l’utente alle prime armi ma per lo sviluppatore che vuole installare la sua applicazione su un sito web! Se io sviluppassi un software con Django o con Ruby On Rails mi divertirei molto di più e risparmierei un sacco di tempo, ma il mio applicativo faticherebbe a diffondersi proprio perché l’installazione della mia creazione sarebbe un’operazione molto meno banale rispetto ad un qualsiasi software sviluppato in PHP, scritto male, pieno di include e con il codice mischiato all’html.

Questo non dipende soltanto dalla disponibilità di hosting a basso costo per php ma anche dalle caratteristiche più deprecate dai puristi della programmazione: la possibilità di embeddare codice in pagine web e di inserire il codice dell’applicativo all’interno delle pagine servite dal web server.

Infatti, se volessi risparmiare tempo ed avere un bel po’ di classi già scritte, potrei decidere di utilizzare un framework per PHP, come ad esempio Cake PHP, ed anche in questo caso per il deployment basterebbe copiare tutte le cartelle sul server e configurare un db, magari con uno scriptino ad hoc. La mia applicazione sarebbe sviluppata con il supporto di un framework, con tutti i vantaggi che questo comporta, ma la sua distribuzione sarebbe comunque molto più semplice di una controparte scritta in Django o Rails.

Questi limiti non sono certo secondari, ed infatti non esiste nessun prodotto sviluppato in Django e RoR in grado di competere, per diffusione, completezza, facilità di utilizzo e di installazione, con le controparti sviluppate (magari anche male) in PHP.



Non è un problema da poco e credo che sia sentito anche dagli sviluppatori di framework come Django e Rails, non a caso David Heinemeir Hansson, nel capitolo 22 del libro “Sviluppare Applicazioni Web con Rails” scrive:

WEBrick può d’altra parte essere considerato una piattaforma ottimale per applicazioni ad ampia diffusione: per esempio il clone di Wiki, Instiki, è riuscito a diventare l’applicazione Ruby più scaricata da RubyForge soprattutto grazie alle promesse di No Step Three.

La selta di WEBrick come server web ha permesso a Instiki di essere distribuito con una procedura d’installazione molto semplice; addirittura, la versione per Mac OS X, è fornita con lo stesso linguaggio Ruby e, quindi, è sufficiente un doppio clic sul file .app per attivare il vostro Wiki personale.

Certo, WEBrick perde rapidamente il suo fascino quando si prendono in considerazioni applicazioni diverse da quelle ad uso interno o personale, ma questo non deve impedirvi di iniziare ad utilizzarlo. Un’applicazione sviluppata per WEBrick non richiede alcuna modifica per funzionare con Apache e lighttpd. Potete persino valutare di continuare a sviluppare localmente con WEBrick, mentre l’applicazione è in produzione su uno degli altri due server, basati su C.

La mia speranza è che in un futuro prossimo la situazione cambi in meglio. I mezzi ci sono: eRuby, Cheetah, Mako, ma mod_python e mod_ruby non sono ancora affidabili e diffusi come mod_php. Fatta l’integrazione naturalmente bisognerà fare i programmatori, ma credo che pian piano anche gli sviluppatori php si stiano abituando all’idea di utilizzare template engine e di sviluppare utilizzando un paradigma object orientend.

Autore: Doxaliber