Programmare in Javascript 1

JavaScript è il linguaggio di programmazione più incompreso del mondo, tanto che neanche chi ci programma, spesso, ha la consapevolezza di quali siano i suoi limiti. Con limiti non intendo indicare le limitazioni, che pure sono presenti, ma i suoi confini.

Non è un linguaggio semplice da utilizzare, da un lato perché è un linguaggio potente ed espressivo, dall’altro perché i tentativi dei progettisti di renderlo amichevole hanno, a mio parere, reso più difficile per chi si occupa di programmazione gestirlo al meglio.

Breve escursus storico

In principio era il Browser. Il più vecchio che ricordi di aver mai usato è Mosaic, un programma molto semplice che non prevedeva il supporto a JavaScript ma mostrava già tutte le potenzialità del web a chi era abituato a dividersi tra gopher, ftp e fidonet.

In seguito venne Netscape e, con esso, la prima incarnazione di JavaScript. Si trattava di una rivoluzione nella rivoluzione di cui non avevo ben compreso in mezzo alla confusione che regnava sovrana negli anni ’90 del secolo scorso. Tra Applet Java e pessime implementazioni degli interpreti associati ai browser JavaScript si costruì la pessima, e non del tutto immeritata, fama che lo accompagna ancora oggi.

A questo aggiungiamo la Browser War tra Microsoft e Netscape combattuta a colpi di deroghe agli standard, in parte ancora in via di definizione, estesi unilateralmente sperando di creare uno standard de facto e costringere il w3c ad uniformarsi per ottenere importanti vantaggi sui concorrenti.

Non è tutto JavaScript quello che luccica

Quando ci troviamo a programmare un browser abbiamo a che fare con una macchina virtuale che fornisce alcune astrazioni. Queste macchine virtuali sono leggermente differenti l’una dall’altra, differenze
sottili ma importanti che impediscono al programmatore web di dormire sonni tranquilli. Anche se qualche grattacapo l’abbiamo ancora la situazione è molto migliorata ed ormai sono pochissime le notti che passo in bianco per la programmazione.

L’handicap maggiore che ci troviamo ad affrontare, in realtà, non è la differenza tra le macchine virtuali ma le aspettative dell’utenza. Prendiamo ad esempio Java, il linguaggio portabile per eccellenza. Non sono rari i programmi che possono funzionare solo su una determinata versione di JVM senza che nessuno gridi allo scandalo o consideri Java un linguaggio poco professionale.

Ogni pagina web, invece deve funzionare al meglio su diversi Browser, volendo limitarsi ai più diffusi: Firefox, Chrome, Opera, Safari ed Internet Explorer. Un sito che non funzioni al meglio su uno di questi non è considerato professionale. Anche in questo la situazione, e le aspettative dell’utenza, sono cambiate in meglio: non dimentichiamo che qualche tempo da i siti web, anche quelli istituzionali, erano ottimizzati per un solo browser ad una specifica risoluzione.

Un applicativo web può essere diviso in tre segmenti: markup (html), presentazione (css) e logica di funzionamento (JavaScript). A voler essere pignoli bisognerebbe anche prendere in considerazione il Browser Object Model (BOM), una interfaccia attraverso la quale il nostro programma interagisce con il browser che lo esegue.

La maggior parte dei problemi che si incontrano oggigiorno originano dai primi due strati ma vengono percepiti come mancanze di JavaScript. Il Browser Object Model, poi, comincia ad essere standardizzato solamente ora con HTML5, anche se tutti i browser maggiori implementano uno standard di fatto.

Il Document Object Model, anche se ha avuto un passato parecchio travagliato ormai è abbastanza standardizzato e, se si evitano i vecchi trucchi, utilizzabili soltanto perché alcuni browser ancora supportano vecchie modalità di accesso ai documenti visualizzati, non costituisce più un grosso problema.

Come mettere la polvere sotto il tappeto

Le differenze tra i motori di rendering html costringono i web designer ad adottare i peggiori trucchi per far in modo che i documenti siano visualizzati allo stesso modo sui diversi browser. Anche JavaScript gode di questo handicap e programmare in maniera professionale significa doversi prendere carico di tutte le differenze, leggi bug ed estensioni proprietarie. Mentre per le seconde basta evitare la tentazione di seguire comode scorciatoie ed attenersi il più possibile agli standard, aggirare i bug significa investire tempo e risorse in aggiornamento e sviluppo.

Per fortuna esiste una soluzione semplice e vantaggiosa: scegliere una libreria, che si incarichi di gestire le differenze tra i vari browser ed esponga una interfaccia coerente ed omogenea. Solitamente queste librerie vengono pubblicizzate per altre caratteristiche ma il loro pregio maggiore è proprio quello di essere cross-browser. In pratica costruiscono uno strato che rende omogenei i browser in modo da semplificare il lavoro degli sviluppatori.

Ovviamente non è tutto un modo di rose e fiori, anche queste librerie possono essere soggette a malfunzionamenti o idiosincrasie ma scegliere con oculatezza il proprio framework di riferimento può aiutare a risolverle al meglio.

In poche parole, meglio programmare verso un unico framework che impelagarsi nella gestione dei più diversi Browser, che tra l’altro, non smettono di evolvere.

A cominciare da Prototype, la più vecchia libreria che io ricordi passando da Script.aculo.us, Dojo Toolkit, ExtJs, Jquery e MooTools fino alle più recenti BackboneJs e Spine è impossibile che non troviate quella che si adatta al vostro modo di programmare ed al vostro progetto.

Ovviamente la lista è incompleta ma non sarà difficile, per chi vuole, integrarla.

Il re è morto, lunga vita al nuovo re

Da qualche tempo JavaScript sta cercando di evadere dalla prigione dorata dei client web (i browser) per avventurarsi nel mondo dei server. A partire da Rhino passando da Aptana Jaxer, per finire al recentissimo e promettente node.js, sta nascendo una serie di nuovi server, passatemi la definizione di Rhino come tale, che possono essere programmati usando JavaScript.

A questi vanno aggiunti i vari framework per desktop application come Adobe Air, Prism e Titanium.

Non parliamo poi di tutti i sistemi operativi, mobili e non, che promettono di poter essere programmati usando JavaScript ed HTML5.

Ovviamente JavaScript non è ancora del tutto pronto a questo passo; fin dalle sue origini manca, sopratutto per ragioni di sicurezza, di funzionalità che sono comuni ai linguaggi general purpose. Una per tutte, l’acceso al filesystem. Il rischio di frammentazione è alto, le proposte tante che non si sa da dove cominciare ad esaminarle (anche se personalmente scarterei a priori tutte le proposte basate su piattaforme proprietarie).

Per chi è interessato all’argomento penso che un buon punto di partenza possa essere common.js.

Si è fatto presto (nel senso che è sorto il sole). Sono desolato ma sono costretto a lasciarvi.