Il linguaggio Javascript ha avuto una diffusione esponenziale negli ultimi anni e ha rappresentato il vero e proprio "motore" del Web 2.0.
Questo è stato possibile per due motivazioni principali:
- Javascript offre un vastissimo insieme di strumenti che permette di realizzare ogni tipo di applicazione web client-side interagendo con HTML, CSS e server;
- la sua particolarissima (e atipica) struttura offre una totale libertà di programmazione e rappresenta una vera e propria manna del cielo per gli svilippatori creativi.
Il secondo punto è la chiave principale del successo. Javascript, infatti, non presenta regole di scrittura precise, quindi sta allo sviluppatore il compito di crearsi una propria tipologia di programmazione definita, basandosi sulla moltitudine di offerte provenienti dal linguaggio nativo stesso.
Il punto debole di Javascript è semplice da individuare: essendo un linguaggio di scripting client-side, quando si lasciano i costrutti nativi per passare all'interazione con il client, iniziano le noie. Questo perchè ogni browser presenta comportamenti, valori, keywords e hacks differenti l'uno dall'altro, soprattutto per quanto riguarda Internet Explorer.
E' veramente un compito ostico tentare di creare applicazioni Javascript cross-browser, per questo molti sviluppatori perdono ore e ore di tempo per tenter di trovare soluzioni comuni ed accettabili.
Tutto questo fino alla nascita dei framework.
I framework
Il compito principale di un framework è quello di porre delle regole precise all'interno del vastissimo universo di Javascript e di utilizzare un'unica sintassi che valga per qualsiasi browser.
Avendo a disposizione delle API ben definite e soprattutto collaudate in una moltitudine di software client, gli sviluppatori non devono più preoccuparsi della resa cross-browser, ma sono liberi di concentrarsi sulle applicazioni vere e proprie.
Dato che, avvalendosi di un framework, ogni programmatore (principiante, intermedio o esperto che sia) ha a disposizione la possibilità di creare applicazioni collaudate e di nuova generazione, si è infine arrivati all'abuso, o meglio ancora, all'overdose delle librerie: tutti sono invogliati ad utilizzarle. Tuttavia, è bene avere le idee chiare sul quando e perché ci si dovrebbe affidare ad una libreria, dato che non sempre il suo utilizzo porta dei benefici.
In questo articolo vedremo appunto quando e perché è opportuno utilizzare un framework Javascript e quando invece sarebbe meglio sviluppare applicazioni standalone.
Panoramica dei framework Javascript
Ecco una panoramica molto veloce dei principali framework Javascript:
Framework completi
Selector Engines
Framework per le animazioni/interfacce
- jQueryUI
- GX (di mia creazione)
- moo.rd (di mia creazione)
- scriptaculous
Framework per le richieste Ajax
Quando usare un framework
Ci sono dei casi in cui, se si ha la necessità di realizzare una determinata applicazione, ci si deve per forza affidare ad un framework. Ecco di seguito le situazioni più plausibili.
Selector Engine. Tutti i più potenti framework di ultima generazione, dispongono di efficaci Selector Engine che ci permettono di effettuare query DOM sugli elementi, dalle più semplici sino a quelle assai complesse:
// elementi annidati multi-livello
$("div#myEl span.myClass p.mySubEl b")...
// pseudo-selettori
$("div#myEl:even p.mySubEl:odd")...
Senza contare, inoltre, che i risultati e le performance vengono ottimizzate con tecniche e stratagemmi di alto livello. Sviluppare un Selector Engine da sè è un compito molto difficile e dunque fortemente sconsigliato, soprattutto quando in circolazione esistono engine di ottima fattura e per giunta open-source.
Animazioni. Nonostante sia possibile creare animazioni costruendosi un proprio, semplice engine per la gestione delle stesse, è sempre consigliabile l'uso di una libreria specifica per giungere a questo obiettivo. Questo perchè, come nel caso dei Selector Engine, anche per gli Animation Engine occorre utilizzare il 100% di tecniche Javascript di alto livello e riflettere molto sulla combinazione tra risultati e performance.
Tramite le API dei framework è possibile animare una vasta gamma di proprietà CSS, creare animazioni a catena e gestire animazioni di più set di elementi. L'uso di una libreria per animazioni inoltre, offre una solida base per la creazione di plug-in personalizzati.
Richieste AJAX. Tutti i più importanti framework offrono API straordinarie per la creazione e la gestione di richieste asincrone al server. La maggior parte delle librerie permette di impostare tutti i parametri che vanno a costituire l'interazione tra client e server, tra cui:
- metodo della richiesta
- eventi e callbacks
- headers di richiesta e risposta
- codifica di scrittura
- vasta lista di parametri extra opzionali
E' possibile inoltre gestire una moltituidine di responsi e formati: dall'ovvio "testo semplice" fino ad arrivare all'HTML, al formato JSON ed all'XML. Invece, tramite script standalone è possibile solamente creare richieste molto basilari e questo è utile solo nel caso in cui si vogliano spedire dei semplici messaggi al server.
Multi-task. Più che consigliato, direi che è quasi obbligatorio l'uso di un framework quando nelle nostra applicazione necessitiamo di più funzionalità avanzate, che siano comprese tra quelle elencate sopra (molto probabile) oppure no. Ricordiamo che un framework mette a disposizione un vasto kit di strumenti collaudati in tutti gli scenari web più plausubili, caratterizzati da performance elevate e, cosa fondamentale, da una continua e costante evoluzione.
Quando non usare un framework
Nonostante i punti elencati nel paragrafo precedente possano indurre a pensare che sarebbe sempre meglio usare un framework, in realtà non è così.
Di seguito ho elencato le situazioni più plausibili per cui sarebbe meglio non affidarsi ad un framework specifico, analizzando i vantaggi ed i punti di forza che emergono dall'uso di script standalone.
Single-task. Se abbiamo un'applicazione in cui necessitiamo solamente di una particolare funzionalità, è bene riflettere attentamente prima di fiondarsi ad occhi chiusi su di una qualsiasi libreria. Ad esempio, se la nostra applicazione richiede l'impostazione di eventi cross-browser, abbiamo mille e più modi differenti per creare il nostro (leggero) script standalone che gestisce sia il modello W3C standard che quello proprietario di IE.
Se dobbiamo recuperare gli elementi DOM, ma in ogni caso conosciamo l'id o il class name di ciascuno di essi, non occorre buttarsi su di un Selector Engine.
O ancora, se dobbiamo cambiare il valore degli stili CSS semplici dei nostri elementi, non è necessario un metodo complesso per la gestione di più situazioni particolari che un framework può offrire.
Evoluzione professionale. Nella maggior parte delle situazioni, l'utilizzo di un framework contribuisce al 70-80% del risultato finale di una applicazione più o meno semplice. Se una funzionalità presenta degli errori, basta aprire un ticket sugli interminabili Issue Trackers e questi, se giudicati veritieri, verranno risolti. Tutto questo non porta ad una evoluzione professionale dello sviluppatore, che pone le sorti della propria applicazione nelle mani del Dev Team in questione. Gli sviluppatori abituati a realizzare applicazioni standalone o plug-in avanzati, sanno come ovviare ai diversi bug e soprattutto possiedono un bagaglio di conoscenze tecniche, teoriche e pratiche maggiori.
Peso. La presenza di un framework in una pagina web... pesa. Questo peso è accettabile se facciamo un uso vero e proprio del framework in questione, sfruttandone al massimo le funzionalità offerte.
Altrimenti, appesantire il carico di lavoro del cliet risulta inutile e soprattutto svantaggioso, sia per l'applicazione che per gli utenti della stessa.
Costrutti nativi e funzionalità interne. Sebbene il Web 2.0 sia tempestato di funzionalità appariscenti ed avanzate, bisogna sempre ricordare che Javascript è un linguaggio di scripting che offre un vasto insieme di costrutti e concetti nativi, primo tra tutti quello che riguarda l'ereditarietà basata sui prototypes. Proprio questa sua struttura ci permette di aggiungere tutte le nostre funzionalità personalizzate agli oggetti nativi tramite script standalone, senza ricorrere all'uso di un framework.
// Estensione della classe Array
Array.prototype.forEach: function() {
// ...
}
// Estensione della classe String
String.prototype.reverse = function() {
var s = "";
for(var i = this.lenght; i == 0; i--) {
s += this[i];
}
return s;
}
// "gnirts a"
"a string".reverse():
Vantaggi e svantaggi derivanti dall'uso di un framework
Pro:
- risultati cross-browser
- vasto kit di funzionalità pronte per l'uso
- performances di alto livello
- non sono richieste competenze Javascript di livello elevato
Contro:
- peso maggiore rispetto ai normali script
- non permette un'evoluzione particolare dello sviluppatore
Vantaggi e svantaggi derivanti dall'uso di script standalone
Pro:
- script leggeri
- evoluzione personale dello sviluppatore
- è possibile aggiungere alla pagina delle sole funzionalità richieste, senza molti kb superflui
Contro:
- funzionalità avanzate mancanti
- compatibilità cross-browser non completa
- sono richieste competenze specifiche di alto livello
Conclusioni
Le conclusioni possono essere tratte semplicemente analizzando il precedente paragrafo: la presenza di un framework collaudato nella pagina, se usato a dovere, permette di creare applicazioni cross-browser di alto livello e comprensive di ogni feature di nuova generazione.
Inoltre, per usare la maggior parte delle librerie open-source presenti in circolazione non occorrono competenze di sviluppo particolari (la maggioranza dei framework sono infatti "designed for everyone"), quindi anche lo sviluppatore principiante è invogliato a contribuire alla realizzazione di applicazioni Web 2.0.
Tuttavia non si dovrebbe mai abusare dei framework, ma ricordare che:
- questi ultimi appesantiscono il carico di lavore del client;
- Javascript offre costrutti nativi davvero interessanti, da cui gli stessi framework prendono vita, la cui conoscenza porta lo sviluppatore ad un'evoluzione maggiore delle proprie competenze.
