Valerio Proietti è il creatore di MooTools, un framework che non ha bisogno di presentazioni. Lo abbiamo contattato per rivolgergli qualche domanda su MooTools, la sua visione di JavaScript e gli sviluppi di MooTools 2.0.
Qual è stata la principale fonte di ispirazione di MooTools?
Il latte, i biscotti e tutte le cose bellissime nell'ambito JavaScript che stavano sbocciando all'epoca. Un esempio sono le widgets della dashboard di Mac OSX, che erano una delle prime e sicuramente una delle più famose implementazioni di JavaScript al di fuori della finestra del browser. Questo è uno dei motivi per i quali ho deciso di creare un framework che fosse completamente modulare, in modo che l'utente potesse utilizzare MooTools sia nei browser che in qualsiasi altro environment.
Come si colloca la tua libreria nel panorama dei framework JavaScript?
MooTools è un framework piuttosto avanzato, e ci sono alcuni concetti con i quali bisogna essere familiari prima di poterlo utilizzare al meglio. Per questo motivo non gode della popolarità di altri framework più semplici da utilizzare per non-sviluppatori. Nonostante questo è sicuramente uno dei toolkit più utilizzati, non ti so dare numeri precisi ma rientra sicuramente nella top 3.
Quali sono i principi alla base del design di MooTools?
Modularity, Extensibility, DRYness (esiste?). Modularity perché, come si puo vedere dal downloader nel sito, MooTools è in realtà un insieme di componenti che possono o non possono essere inclusi. Se per esempio non ti servono le animazioni sugli elementi, puoi semplicemente non includere il componente relativo.
Extensibility è fare in modo che ogni componente che scriviamo sia facilmente estensibile da utenti o sviluppatori. Ad esempio, sempre sul modulo per gli elementi, è possibile aggiungere metodi, getters, setters, etc. DRYness è uno dei fondamenti che tutto il codice del mondo dovrebbe adottare come legge. Se hai già scritto codice per fare una cosa, non riscriverlo per fare una cosa simile, riusalo.
Parlami del tuo background come sviluppatore.
Ho cominciato a sviluppare una decina di anni fa, mentre lavoravo come tecnico in una piccola agenzia software. Le prime righe di codice che ho scritto erano VBScript per l'automatizzazione di installazioni e configurazioni. Da li mi sono interessato anche ad altri linguaggi, quali JavaScript, PHP, ASP, e ho cominciato ad ammirare la programmazione per il Web in generale. Qualche anno dopo mi sono messo in proprio, e tutt'ora lavoro come freelance.
Credi che si possa parlare di scuole di pensiero a proposito di JavaScript? Penso ad esempio a figure come John Resig, Douglas Crockford, il team di Yahoo, Dean Edwards e altri.
Senza dubbio. Io ad esempio, pur avendone il massimo rispetto, mi trovo quasi sempre in completo disaccordo con tutto quello che scrive Douglas Crockford. In quanto agli altri che hai menzionato, non sono abbastanza familiare con la loro visione del linguaggio per dare un opinione. Sicuramente c'è un discorso di differenza di pensiero su cosa debba o non debba fare un framework o una libreria JavaScript, differenze di target di utenti e di funzionalità , ma quello è interamente un altro discorso. Con MooTools vogliamo fare determinate cose e avere come target un determinato tipo di persone, gli altri toolkits hanno obiettivi completamente differenti.
In quasi tutti i libri in mio possesso c'è almeno una o più citazioni del tuo lavoro. Sei consapevole di aver portato l'Italia al centro dell'universo che ruota attorno a JavaScript?
Sono dell'opinione che la nazionalità del programmatore abbia una bassissima rilevanza in questi casi. Io sono nato, cresciuto e vivo in Italia, ma quasi tutto quello che ho imparato l'ho imparato sul Web da persone che hanno scritto codice per il Web. Nel team di MooTools ad esempio, come nel team di molti altri frameworks, sono presenti sviluppatori da tutte le parti del mondo, ma non ha nessuna importanza. Le cose che abbiamo imparato le abbiamo imparate tutti dalla stessa fonte, il Web. La nazione a cui appartiene il programmatore che scrive codice per il Web è il Web.
Cosa consiglieresti a un programmatore che ha un tradizionale background OOP e vuole adottare un approccio OOP con JavaScript?
Semplicemente di imparare il JavaScript. JavaScript, a discapito delle credenze popolari, è un potentissimo linguaggio ad oggetti. Librerie come MooTools rendono molti task meno ripetitivi e automatizzano e facilitano la scrittura di codice riutilizzabile, ma non sono assolutamente necessarie per utilizzare a pieno la potenza di JavaScript. Molti associano il JavaScript con il DOM, che non è nient'altro che una collezione di ogetti accessibili da JavaScript messi a disposizione dai vari Browser. Il mio consiglio per chi vuole imparare il linguaggio è tenersi lontano dai libri e articoli che menzionano browser e DOM, e andare su materiale più tecnico.
Tutti i framework JavaScript che conosco dedicano molto spazio all'appianamento delle differenze di interpretazione tra browser. Come vedi l'evoluzione del supporto a JavaScript nei browser alla luce di quanto la task force di ECMAScript sta proponendo?
Purtroppo ci saranno sempre discrepanze tra le varie implementazioni del DOM nei vari browser, quindi credo che la situazione non cambierà più di tanto, almeno nei prossimi anni. Ci saranno sempre browser con più funzionalità che i framework dovranno emulare per i browser meno fortunati, o browser con bug che andranno aggirati. La situazione è leggermente migliorata rispetto a cinque anni fa, ma non tanto da far presagire alcun cambiamento radicale. Basta pensare che si sviluppa ancora per Internet Explorer.
Pensi che JavaScript debba restare un linguaggio class free o implementare le parole chiave per la programmazione ad oggetti che al momento sono riservate a futuri usi in ECMAScript?
Implementare "class" in JavaScript sarebbe del tutto inutile e ridondante. JavaScript ha già "class", solo che in JavaScript si chiama "function". Una delle chiavi riservate che andrebbe decisamente implementata è invece "private". Sono dell'idea che JavaScript abbia un disperato bisogno di membri privati.
Cosa c'è nel futuro di Valerio Proietti e di MooTools?
MooTools 2.0 e ART sono i progetti a cui io e il team di MooTools stiamo lavorando. MooTools 2.0 vedrà un implementazione delle classi relative al DOM completamente diversa, più intuitiva e semplice da utilizzare, ma nello stesso tempo molto più estensibile e compatibile con i vari interpreti, specialmente quelli più datati. ART è invece una libreria per il disegno vettoriale per browser che supportano SVG o VML. Questa libreria sarà poi la base fondamentale per futuri progetti, del team di MooTools o di terzi, quali charting, componenti per interfacce, text replacement, e tutto quello che ha a che fare con grafica vettoriale & browser.