Per entrare nel vivo delle nuove, potentissime meccaniche offerte dalla versione 1.2 del framework MooTools, in questo articolo vi riporto l'intervista che ho realizzato con l'ideatore, nonché team leader, della libreria in questione: Valerio Proietti.
Ringrazio personalmente Valerio per la completa disponibilità e per la ricchezza dei contenuti. Inoltre consiglio a tutti gli sviluppatori che utilizzano MooTools di non perdersi questa risorsa. Al suo interno troverete consigli, suggerimenti, codici e tante novità sull'universo di MooTools, con qualche curiosità sul suo ideatore. Iniziamo!
Riccardo: Come e quando è nata la tua passione per il Web Design e in particolare per Javascript?
Valerio: La mia passione è iniziata più o meno sei anni fa. Allora il mio lavoro (parecchio noioso) consisteva nella realizzazione di scripting vari, ma sopratutto nell'ottimizzazione di questi ultimi. Dovevo migliorarli e scriverli più elegantemente. La passione per Javascript è quindi piu una passione per lo scripting in generale. Programmare per il web da una grande soddisfazione immediata e facendolo hai il grande vantaggio che il tuo lavoro possa essere visto da tantissime persone in poco tempo.
Riccardo: Sviluppare un framework Javascript completo e "full-featured" come MooTools è un'impresa ardua, soprattutto con prodotti come Prototype e jQuery in circolazione già da tempo. Quali sono stati i motivi che ti hanno fatto intraprendere questa scelta?
Valerio: Poco dopo aver iniziato con il web development ho deciso insieme ad un amico di creare un CMS, chiamto MooFlex e basato sull'accopiata Prototype + Scriptaculous. Devo dire che ero davvero impressionato dalla potenza di Prototype, mentre con Scriptaculous non mi trovavo per niente bene. Ho quindi deciso di scrivermi il mio framework di animazioni: moo.fx (togli "le" da MooFlex ed ottieni moo.fx). Volevo qualcosa che sfruttasse davvero la potenza di Prototype, qualcosa di ottimizzato alla perfezione ed allo stesso tempo utile agli sviluppatori. Continuando ad ottimizzare e migliorare i miei lavori, lo script diventava sempre più grande, coeso ed "armonico": è da qui che è nato MooTools.
Riccardo: Sfogliando accuratamente il codice della versione 1.2 e paragonandolo a quello delle primissime release, come la 0.90 o la 1.0, si nota come questo sia diventato molto più robusto ed articolato. Come si è evoluta la tua metodologia di programmazione e di conseguenza MooTools?
Valerio: Diciamo che MooTools mi ha insegnato, e continua ad insegnarmi, sia JavaScript, sia HTML, sia CSS, come si comportano i browser e molto altro. Sviluppando MooTools imparo tantissimo. All'inizio impari tantissime cose in poco tempo e il framework cresce rapidamente, poi raggiungi una certa stabilità continuando comunque ad evolvere. La versione 1.2 rappresenta questa stabilità che stiamo rincorrendo da piu di un anno. Ma l'evoluzione non sta solamente nel codice in termine stretto, ma riguarda anche il design di API e l'immedesimazione nell'utente.
Riccardo: Qual è stata la parte più ostica da realizzare/progettare all'interno del framework?
Valerio: In linea generale, sicuramente realizzare la compatibilità con tutti i browser, soprattutto con Opera e Internet Explorer 6. È veramente un compito ostico da portare a termine, ma mi compiaccio del fatto che nessun utente che usa MooTools debba fare lo stesso, compreso me.
Riguardo il codice, senza dubbio i selettori CSS3 sono stati parecchio complessi, pur non essendo particolarmente difficili da programmare sotto la componente logica. Bisognava trovare la giusta via di mezzo tra velocità, eleganza, efficenza ed estensibilità.
A differenza di altri framework che dopo il calcolo principale aumentano la velocità di esecuzione, ho optato per un parser "logico", senza nessun tipo di "case" specifico. Ogni selettore viene "splittato" nelle sue parti e trattato nel medesimo modo di tutti gli altri.
I vantaggi si riscontrano nella drastica riduzione della mole di codice, nell'aumento della sua mantenibilità e ancora nella riduzione del margine d'errore.
Riccardo: MooTools ha acquisito un successo internazionale ed è stato accolto molto positivamente dagli sviluppatori, come dimostra la numerosa community e il gran numero di plugin realizzati da terze parti. Te lo aspettavi?
Valerio: Sì e no. Dopo un certo periodo di tempo, ovviamente mi aspettavo di vedere realizzati plug-in basati su di esso.
Quello che non mi aspettavo è la grande quantità di siti che usano MooTools come enhancement grafico, come Rockettheme e Joomla, per esempio. Io ho puntato principalmente ad un'audience di sviluppatori, invece questo dimostra che MooTools è usato tantissimo anche per i suoi effetti, il che mi rende molto felice.
Riccardo: Quali sono i principali cambiamenti tra la versione 1.1 e la versione 1.2 e quali sono i vantaggi fondamentali offerti da quest'ultima?
Valerio: Qui ci sono tantissime cose da elencare, quindi ti riporto solo quelle principali. Per prima cosa i selettori e le API per scrivere pseudo-selettori, che sono le stesse che usiamo internamente. Ti faccio un esempio pratico:
Selectors.pseudo.invisible = function(){ return (this.get('opacity') == 0); };
Per ottenere tutti gli elementi di tipo "div" con un valore di opacity uguale a 0 è poi possibile fare:
$$('div:invisible')
Il parser di cui parlavo precedentemente supporta tutte le concatenazioni di tutti i tipi, anche 6 classNames se vuoi :D. Inoltre, diversi namespace sono stati modificati per una questione di consistenza. Anche se questo potrebbe inizialmente creare dei problemi per chi arriva dalla versione 1.1, penso ne valga parecchio la pena, perché aggiunge davvero molta consistenza.
Un'altra grande novità sono poi gli shortcuts come i seguenti:
element.fade(); element.tween(); element.morph();
Questo è stato un dei motivi per cui abbiamo cambiato il nome alle classi, dato che element.style() non avrebbe avuto molto senso.
Mi soffermo un attimo sugli shortcuts, che a mio avviso sono potentissimi. Sia gli shortcut "vecchia scuola" (come element.effect()) che le classi (come new Fx.Qualcosa), ritornano un'istanza, che dovresti usare ogni volta che lanci un effetto. I nuovi shortcut invece, ritornano l'elemento e creano automaticamente un'istanza associata a quell'elemento, che poi verrà riusata automaticamente. Ad esempio:
el.fade(); // crea istanza e crea una dissolvenza el.fade(); // riusa istanza e crea una dissolvenza
È un'automazione pazzesca, perché permette di creare effetti velocemente, senza preoccuparti delle istanze. Inoltre permette di non crearle finché non vengono usate, risparmiando memoria e velocità.
Questa nuova metodologia permette la creazione di moltissime nuove cose, ma non deve essere una sostituzione completa alle classi, che consiglio di utilizzare per la creazione di effetti personalizzati. Gli shortcut sono quindi una "parte client", che all'interno di un'applicazione, dovrebbero essere utilizzati più dall'utente che dal suo sviluppatore.
Passiamo ora ad Element. Questi utilizzano internamente lo Storage, che è a mio avviso una delle novità più rilevanti. Esso permette di associare un valore ad un elemento, senza che esso sia attaccato fisicamente all'elemento, e successivamente riprendere questo valore. Ti faccio un esempio pratico:
// salviamo nell'elemento inputElement, con keyword 'label' il suo elemento label inputElement.store('label', labelElement); // salviamo nell'elemento labelElement, con keyword 'input' il suo elemento input labelElement.store('input', inputElement); // successivamente utilizziamo questi valori restituiti dal metodo retrieve e compiamo operazioni con essi inputElement.addEvent('focus', function() { this.retrieve('label').setStyle('color', 'red'); }); inputElement.addEvent('blur', function() { this.retrieve('label').setStyle('color', 'blue'); }); labelElement.addEvent('click', function() { this.retrieve('input').focus(); });
Nei miei lavori non riesco proprio a fare a meno di utilizzare questa metodologia, che trovo molto più utile che riempire il DOM di query ogni volta che abbiamo bisogno di trovare un determinato elemento. Ovviamente con il metodo store è possibile registrare qualsiasi cosa, come oggetti, istanze e così via:
element.store('fx', new Fx.Morph(element));
// successivamente
element.retrieve('fx').start();
Sempre riguardo ad Element non posso non riportare i nuovi metodi set, get ed erase, che rappresentano una nuova metodologia per scrivere, leggere e cancellare gli attributi da un elemento. E' possibile lavorare sia con attributi standard che con attributi custom:
// aggiungo una propriet&agreva; 'invisible' per vedere se il mio elemento ha un opacity pari a 0
// e per settarla a questo valore
Element.Properties.invisible = {
get: function(){ return this.get('opacity') == 0; },
set: function(){ this.setStyle('opacity', 0); }
}};
// settiamo a 0 il valore di opacity
element.set('invisible');
// mentre per gli attributi standard MooTools usa internamente getProperty e setProperty
// restituendo il determinato valore
element.get('checked');
element.get('id');
L'ultima novità di rilievo per quanto riguarda la classe Element è rappresentata dal supporto completo per gli iframes, grazie alla classe helper per creare iframes in tutta semplicità e per lavorare con gli elementi in essi contenuti (iframe.getElement('someelement').fade(), ad esempio).
Altre novità interessanti sono la nuova classe Hash, cambiata moltissimo rispetto al passato e facente ora parte del "core", e la classe Request che migliora le funzionalità precendenti di Ajax ed offre più organizzazione, nelle sue componenti Request.HTML, Request.JSON ed in futuro Request.XML.
Inoltre, un'altra grande novità è la completa separazione del core dai plug-in: altro Trac, altro SVN.
Riccardo: Allo sviluppatore che utilizza MooTools 1.1 nelle proprie applicazioni, che consigli dai per integrarsi al meglio con le meccaniche della nuova versione e migrare cosi alla 1.2?
Valerio:
- utilizzare Firebug, vedere su quali metodi da errore e cercarli nella documentazione;
- leggere tanta documentazione, che è immensamente più dettagliata rispetto alla precedente;
- nel trunk c'è una cartella chiamata Compatibility
(molto probabilmente varrà rilasciato come file singolo dal nome di compatibility.js). Includendolo si ottiene una buona compatibilità con la versione 1.1 ed i precedenti metodi continueranno a funzionare, anche se consiglio vivamente di utilizzare la 1.2 ed imparare le nuove meccaniche (ci sono parti dove ovviamente non si può ottenere la piena compatibilità); - comprare il libro in lingua inglese che esce tra poco,
attualmente in fase di scrittura da parte di Aaron Newton; - seguire il forum ed il blog ufficiali.
Riccardo: Nei forum e nei blog internazionali che includono la trattazione dei framework Javascript tra i propri argomenti, si è parlato di una quasi totale riscrittura della tua libreria rispetto alla precedente versione. Perché questa scelta?
Valerio: In realtà credo sia un esagerazione. Sicuramente è vero che quasi tutto il codice è stato rivisitato e spesso migliorato, ma una totale riscrittura è decisamente un esagerazione. In fondo, utilizza gli stessi principi di base, quasi la stessa struttura a moduli: anche se molte cose sono state spostate e riorganizzate, per consistenza o per future proofing, le parti che sono state riscritte da zero le posso contare sulle dita di una mano :). Direi più che altro che è stato completamente ottimizzato.
Riccardo: Perché uno sviluppatore dovrebbe scegliere MooTools 1.2 preferendolo ad altri grandi framework come Prototype, jQuery, Ext o Dojo?
Valerio: Non conosco molto bene questi altri framework in realtà, ma trovo che ognuno di essi sia un ottimo lavoro.
Secondo me è una questione di quello che serve a te, di quali sono le tue esigenze.
Per fare un esempio, io so che Prototype, come MooTools, modifica i prototypes degli oggetti, mentre YUI, Dojo e JQuery non lo fanno.
Questo aspetto dovrebbe avere un impatto enorme nella scelta del framework.
Se hai una pagina della quale non hai il completo controllo o che include altri framework, MooTools darà sicuramente dei problemi dato che modificando i prototypes va in conflitto con gli altri, mentre YUI o JQuery si comporteranno alla perfezione.
Personalmente non potrei fare a meno di avere i metodi sugli Array per esempio, ed è per questo che sceglierei un tipo di libreria come MooTools o Prototype, che modifica i prototypes degli oggetti nativi.
Un altro criterio di scelta potrebbe essere la dimensione, ma in fine tutti i maggiori framework hanno più o meno lo stesso footprint, quindi si devono controllare le features offerte da ognuno di essi. A differenza di altre librerie, MooTools racchiude in sé sia un'ampia base dedicata alle classi sia moltissimi plug-in "built-in".
Una caratteristica fondamentale di MooTools è che vuol essere rispettoso verso Javascript, rappresentando un'estensione al linguaggio. I framework namespaced, non presentano quest'ultima caratteristica, ad esempio.
Riccardo: A differenza di altre librerie, MooTools utilizza una sintassi molto Object Oriented che, soprattutto per gli oggetti di tipo
Class, ricorda molto i modelli di PHP5 e Java. Che vantaggi possiamo trarre da questa sintassi, oltre all'infinit‡ ri-usabilità delle variabili ed alla conservazione del loro stato?
Valerio: Il vantaggio più eclatante è che questo modello offre una base pazzesca per i plugin, dato che ogni plugin all'interno di MooTools è rappresentato da una classe. Un codice "class-based" offre quindi una grande estensibilità al framework, come hai giustamente riportato.
Riccardo: Quali progetti hai per il futuro? Che sorprese ci riserverà MooTools nelle prossime release?
Valerio: Decisamente il mio più grande progetto è la creazione di un framework UI (attualmente in fase di lavorazione), che uscirà probabilmente insieme ad una delle point releases della versione 1.2. Una delle poche informazioni sicure è che sarà interamente basato sugli elementi canvas in sostituzione delle immagini, e sarà "modulare" in pieno stile MooTools. Esso permetterà la creazione di una "User Interface" basata su bottoni, finestre, menu e così via.
Riccardo: Infine, non posso non chiedere al papà di MooTools un giudizio sulla versione 1.3.1 della mia libreria moo.rd. Che ne pensi?
Valerio: Devo dire che ho riscontrato un miglioramento enorme. Mi piacciono molti degli effetti, e la galleria non si puo rompere, il che è una grande cosa. Ti dico la verità: quando vedo uno script la prima cosa che faccio Ë cercare di "romperlo". Se non ci riesco questo mi da un'idea di solidità, e ciÚ dice tantissimo sul codice. Gli effetti "shuffle" sono fighissimi! Ripeto, un miglioramento esponenziale, complimenti!
Riccardo: Valerio, ti ringrazio ancora per la disponibilità. A presto!
Valerio: E' stato un piacere. Grazie a te!
