Intervista a Valerio Proietti, il creatore di MooTools
Mercoledì 1 Dicembre 2010 - 10:20
di Gabriele Romanato
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.
Categoria: Scripting | Permalink
Commenti
1
MooTools FTW!
# - postato da William Ghelfi - 01 Dicembre 2010 - 11:17
2
Scusa, ma se con JS non ci lavori con il DOM cosa ci fai? Uno normalmente quando studia (mi riferisco alle risorse su cui studiare citate) cerca di studiare qualcosa che gli servirà ed oggi è richiesto che JS sia in qualche modo collegato al DOM. Quali altri sono i “ricchi” contesti in cui può essere usato JS (AIR a parte)? Sono anche in disaccordo sulle classi e non vedo l’ora che le introducano, assieme a private, extends e tante altre cosette utili.
# - postato da Pino - 01 Dicembre 2010 - 11:24
3
Mooo! :E
4
Caro Pino, non vorrei far partire una flame war, ma c’è bisogno di un paio di commenti.
1) Ovviamente conoscere il DOM è fondamentale per utilizzare JS nel browser. Quello a cui si riferisce Valerio è l’esistenza di un sacco di risorse per imparare che sono così confuse da mescolare il linguaggio con le API come il DOM. Il risultato è che chi impara da lì si fa un’idea sbagliata di cosa sia JS, figuriamoci di come usarlo bene.
2) In JS si possono mimare costrutti simili alle classi - con tanto di ereditarietà, membri privati ecc. - con poche righe di codice. Suggerire di inserire le classi significa stravolgere la natura prototipale del linguaggio. Se conosci a fondo come funzionano gli oggetti in Javascript, come possono essere usati per ottenere l’ereditarietà in tanti modi diversi, e come è facile riprodurre tutti i maggiori pattern di programmazione in JavaScript, non ti mancheranno certo le classi! Altrimenti… beh, è una buona occasione per imparare i costrutti tipici di questo linguaggio, che magari è diverso da quelli a cui sei abituato (senza offesa, non ho idea di quale sia il tuo livello). Posso consigliarti Javascript Patterns, l’ultimo libro di Stefanov (ma anche il suo libro precedente).
# - postato da Andrea - 01 Dicembre 2010 - 13:21
5
@Andrea:
nessuna offesa, ma ti rammento che se non fosse stato per MS (che affossò Tamarin e la proposta del nuovo ECMAScript al W3C), oggi JS sarebbe identico ad AS, che -nella mia più che modesta opinione- è nettamente più robusto. Non mi piacciono i prototype, non ci posso fare niente: non è un fatto di pattern o altro: è un fatto di gusto e comodità nella programmazione (e programmare JS non mi piace granché). E’ un fatto personale, non assoluto :-)
# - postato da Pino - 01 Dicembre 2010 - 14:04
6
@Pino:
Javascript esiste in molte forme, non solo strettamente legato al web, per esempio, V8 di google è un motore javascript molto potente che è facilmente “embeddabile” all’ interno di un applicazione c++, rendendo di fatto “scriptabile” un applicazione, altrimenti, senza andare a scomodar c++,
posso elencarti diverse implementazione di javascript lato server.A cominciare dal vecchio Rhino, o V8 stesso, che stà anche avendo un discreto successo utilizzato con node.js,
senza contare la versione di microsoft jscript.# - postato da Carlesso Cristian - 01 Dicembre 2010 - 18:56
7
D’accordo sul fatto che Javascript non sia solo semplice manipolazione della DOM e pertanto andrebbe studiato come linguaggio aldilà del suo utilizzo con le pagine web.
Il mio dubbio però riguarda il modo di utilizzare Javascript ad esempio in un sorgente C++, come suggerito da qualcuno, è vero è un linguaggio di scripting ed è quindi notoriamente più veloce, ma non vedo perché dovrebbe essere preferito ad esempio allo stesso linguaggio C++, tanto comunque va ricompilato il sorgente nel caso di modifica..
Qualcuno di voi più pratico mi potrebbe indicare qualche vantaggio nell’utilizzare Javascript con C++ piuttosto che con Java? Forse per una chiamata Ajax con XMLRequest?# - postato da CarloS - 01 Dicembre 2010 - 19:58
8
@CarloS:
Allora, intanto è l’ esatto opposto, un linguaggio compilato, di norma, è più veloce di uno interpretato (JIT a parte), ovviamente il js viene compilato assieme al sorgente, viene interpretato quando necessario ;)L’esempio più illuminante di ciò che si può fare con un linguaggio di scripting: i plugin di firefox.
Se hai giocato a qualche gioco recente l’ AI viene spesso “scriptata” (anche se anzichè JS si usa spesso LUA).
Questo permette di creare un astrazione più ad alto livello, e può fornire uno strumento, ad esempio, per evolvere il codice in futuro (vedi Add-on per i giochi) senza dover per forza cambiare l’ eseguibile.
Ci sono già tanti esempi di eseguibili già oggi scriptabili usando JS, vedi editor di testo (Notepad++, Ultraedit) che espongono delle routine che poi possono essere utilizzate dal linguaggio di script che essi stessi interpretano.
Insomma la potenza di JS è ben più grande di quel che la maggior parte della gente possa pensare.
# - postato da Carlesso Cristian - 01 Dicembre 2010 - 23:19
9
correzione al commento sopra:
ovviamente il js *NON* viene compilato assieme al sorgente.
Ps. Giusto per rimarcare il concetto, intendo dire che lo script javascript viene caricato a runtime ;)
# - postato da Carlesso Cristian - 01 Dicembre 2010 - 23:23
10
ciao Valerio,
sono d’accordo con te anche io mi trovo in disaccordo con crockford. Soprattutto quando parla dell’eval# - postato da sasuke - 02 Dicembre 2010 - 01:04
11
@Carlesso
Il pricipale uso che si fa di JS è un uso su web: che poi esista un JS dentro Acrobat, uno dentro FF, una versione JS di Lingo, una versione JS di Unity, una versione server side per il Flash Communication Server e tante altre cosette è per me ancora più sbalorditivo perché -sempre nella mia più che modesta opinione- si vanno a costruire palazzine usando stuzzicadenti.
JS è per me un linguaggio precario che in anni di età si è evoluto poco o nulla e adesso dovrebbe essere quantomeno rimaneggiato.
Poi, dai, chi userebbe seriamente SSJS?
# - postato da Pino - 02 Dicembre 2010 - 08:08
12
@Pino. conosci node.js? hai presente quanti moduli stanno uscendo per lui?
# - postato da sasuke - 02 Dicembre 2010 - 10:38
13
@sasuke
Io non critico il fatto che si realizzino dei progetti: in questo contesto, la mia finirebbe per passare per una critica a chi ha realizzato MooTools (non è questa la mia intezione). Io dico -ribadisco la cosa con molta umiltà- che dal mio punto di vista questo linguaggio è vecchio e carente e che progetti (belli e importanti) come MooTools (ed altri) potrebbero largamente beneficiare se JS venisse migliorato e portato ad assomigliare maggiormente ad AS, dove class, extends, implements, private e “tool” affini sono il minimo.
Non è mia intenzione nemmeno quella di alimentare flames: volevo dire la mia e l’ho detta con diverse parole già troppo. :-)
# - postato da Pino - 02 Dicembre 2010 - 12:11
14
Ciao Pino,
neanche io volevo accendere Flame. Javascript è un linguaggio che fin dalle sue origini nasce come prototipale e non è stato pensato per gestire delle classi.Infatti il suo progenitore è self un dialetto di smalltalk nato per utilizzare i prototipi rispetto alle classi.
Invece ad esempio ruby eredita il modello a oggetti di smalltalk dove si fa un largo uso di classi e metaclassi.
# - postato da sasuke - 02 Dicembre 2010 - 15:07
15
@sasuke
Volevo solo specificare che i miei toni erano pacifici, non aggressivi ;-)
Per quello che doveva fare Mocha (poi LiveWire, poi JavaScript) dieci anni fa, i prototipi andavano bene. Adesso che l’idea non è più quella di fare dei semplici script ma delle applicazioni, forse il modello a prototipi è meno adeguato di un tempo.
# - postato da Pino - 02 Dicembre 2010 - 17:06
16
@Pino:
Guarda, io stavo semplicemente rispondendo alla tua domanda:
“Scusa, ma se con JS non ci lavori con il DOM cosa ci fai”
Come ti ho elencato ci son varie alternative che non usano necessariamente il DOM;
Dalle tue risposte si è capito che per tua preferenza di stile, hai detto di javascript “vecchio” e “carente”, ma tu inconsciamente commetti un errore perché lo paragoni ad un linguaggio ad oggetti classico quale java o c# che son due ottimi linguaggi, (e io adoro in particolar modo il secondo), ma non son linguaggi funzionali.
Comunque c’è da dire che il paragone viene naturale perchè tutti e tre son linguaggi c-like, ma ognuno di questi ha i suoi lati positivi o meno.La potenza di javascript stà proprio nella flessibilità della sua sintassi, la possibilità di estendere, o addirittura riscrivere parte del codice di base.
Gli oggetti ci sono e c’è la possibilità di usare i paradigmi della programmazione ad oggetti.
Perciò, c’é esattamente tutto quel che serve per avere un ottimo linguaggio con, torno a dire, i suoi pro e i suoi contro, il resto è tutta una questione di preferenze e opinioni.Per finire:
“Poi, dai, chi userebbe seriamente SSJS?”
Ti assicuro che viene usato anche da grosse ditte del ramo bancario/assicurativo da anni assieme a java, che poi io preferisca usare C# è un’ altra questione ;)# - postato da Carlesso Cristian - 02 Dicembre 2010 - 20:58
17
@Carlesso
Il mio pensiero è concentrato nel post 15, non penso di poter aggiungere altro: io trovo JS vecchio, carente e scomodo per l’anno 2010. Che poi qualcuno ci abbia trovato flessibilità e altre caratteristiche che io non ci trovo, non ci sono dubbi (non sarebbero nati tutti i framework che tutti conosciamo).
Però, per raccogliere la sfida delle applicazioni, per me JS non è pronto a sufficienza.
Il mondo del web, da quando JS è cambiato l’ultima volta, è cambiato tantissimo e JS non si è adattato: ha preteso che gli sviluppatori lo usassero così com’è (anzi, a un certo punto fu dato per moribondo).
Ora, è chiaro che ci sono problemi di tipo storico: JS proviene comunque dal mondo Netscape e ha pesato la scissione di JScript (IE). Poi, il suo creatore ama la sua creatura per come è.
Ma sono uscite tante cose belle nel frattempo: ci sono cose geniali in AS, in Python, in Ruby, addirittura in PHP!, e JS cosa fa? Un monumento alla proprietà prototype?
# - postato da Pino - 02 Dicembre 2010 - 22:00