Eccoci alla seconda puntata delle nostre traduzioni delle interviste di "People of HTML5" di Chris Heilmann. Oggi Chris ha parlato con Remy Sharp (@rem su Twitter), co-autore di "Introducing HTML5" e organizzatore, fra le varie cose, della conferenza Full Frontal a Brighton in Inghilterra.

Remy Sharp 1) Leggendo "Introducing HTML5" si ha l'impressione che tu sia più l'esperto di API mentre Bruce quello concentrato sul markup. E' corretta questa impressione?
Direi perfetta. Bruce mi ha chiesto di partecipare come "JavaScript guy" – che è peraltro il mio slogan quando mi trasformo in supereroe davanti ai clienti (piuttosto sorpresi).
Io sono sempre stato un coder – fin da piccolo, quando mio padre mi chiedeva di ricopiare listati di codice dai giornali sullo Spectrum, e poi non funzionava mai niente per qualche errore misterioso che non si riusciva mai a trovare.
Invecchiando mi sono laureato scrivendo C ma in quei giorni gli SDK erano roba da 10 mega da scaricare con un modem a 14kb e si compilava in ambienti strani. Non sono andato molto avanti lì.
E poi è arrivato JavaScript. Un linguaggio di programmazione che non richiedeva nessun particolare ambiente di sviluppo. Potevo scrivere codice con Notepad sul mio vecchio PC con Windows 95, e ogni macchina poteva eseguirlo: bastava un browser. Bingo!
Da quel momento l'idea che potevo immediatamente vedere la mia creazione funzionare in un browser mi ha conquistato – JavaScript era la mia strada.
Ho poi lavorato anche in ambienti di back-end (sono un ragazzo Perl, sorry!) ma sempre attratto dal front-end. E poi, da quando mi sono messo in proprio nel 2006, mi sono potuto concentrare quasi esclusivamente sul front-end e specializzarmi in JavaScript. Sostanzialmente, dal punto di vista lavorativo, sono un maiale che sguazza felice nel fango [NTD: sic]

2) Dall'ottica del programmatore, quali sono le parti più esaltanti di HTML5 e che cosa consiglieresti di affrontare come prima cosa ad un programmatore che vuole incamminarsi su questa strada?
Per me la cosa più esaltante di HTML5 è la profondità delle API JavaScript. Non è facile spiegare al casual blogger che questa nuova versione di HTML in realtà parla più di JavaScript che di HTML.
Non potrei indicare solo una parte specifica di HTML5, sarebbe come chiedermi qual è la parte che preferisco di CSS3 (uhm, in realtà lì c'è una parte che preferisco, il selector target: – vabbè…). La cosa che mi piace di più di HTML5 è che la piattaforma è il browser – questa volta sul serio.
Se un coder vuole qualcosa di rapido e veloce gli direi di cominciare dalle API per i video: non sono le migliori ma sicuramente sono tra le più semplici da usare.
Se poi vuole veramente impressionare gli altri gli direi di studiarsi bene JavaScript (ovviamente conoscendo bene HTML e CSS), partendo da un libro come "JavaScript: The Good Parts" e poi "JavaScript Patterns". E poi, se proprio vuole, magari potrebbe comprare "Introducing HTML5", scritto da due ragazzi veramente spettacolari – soprattutto se nudi: http://flic.kr/p/8iyQTE e http://flic.kr/p/8iy6Z1.

3) Nel tuo libro hai scritto un tutorial molto carino per la creazione di un video player con HTML5. Quali sono secondo te i punti di forza e di debolezza delle API video di HTML5?
L'API per i media è molto semplice, quindi lavorare con audio e video è una bellezza. Per me, va abbastanza bene così (avendo ben chiari il loading process e gli eventi)
Quello che è davvero fico è il fatto che si possono catturare frames del video e lavorarci su un canvas – si possono davvero fare cose molto carine, basta dare un'occhiata al lavoro di Paul Rouget.
Cosa non mi piace, e proprio non mi piace, è che le specifiche chiedono esplicitamente ai vendor (i browser) di *non* implementare il full screen. Indicano problemi di sicurezza come motivo (e posso capirlo) ma Flash ha risolto questa cosa molto tempo fa – quindi perchè non seguire il loro esempio? Se il video HTML5 non avrà mai il full screen non sarà mai un'alternativa valida a Flash.
Tutto ciò detto, apprezzo che i ragazzi di WebKit abbiano ignorato la specifica e implementato il full sscreen. D'altro canto le specifiche sono linee guida e personalmente penso che i browser dovrebbero implementare questa feature.

4) Parliamo un attimo di standard non-HTML5, come Geolocation. Mi sembra che tu ci abbia lavorato e abbia trovato che alcune parti della specifica funzionano e altre no. Puoi dirci di più?
Al di sopra della specifica di HTML5 ci sono un sacco di altre specifiche che rendono il browser uno strumento fantastico. Se pensiamo ai browser moderni (incluso IE9) ci sono un sacco di cose possibili che 10 anni fa sembravano fantascienza.
C'è la parte "non-HTML5" che era parte di HTML5 ma che è stata separata (a ragione, così da poter essere gestita meglio), come web storage, l'API 2D del canvas e Web Sockets – ma ci sono anche parti che proprio non hanno nulla a che vedere con HTML5 come ad esempio querySelector, XHR2 e Device API. Vorrei proprio provare tutte queste cose anche se ancora non sono supportate da tutti i browser.
Geolocation è un ottimo esempio di scelta oculata di una tecnologia, legata un po' al fatto che io stesso a volte mi chiedo se sia il caso di usare (già) HTML5. Solo il 50% della specifica di Geolocation è implementata nei browser che la supportano dal momento che non hanno altitudine, direzione o velocità – tutti elementi della specifica. Questo ha impedito a Google Maps di utilizzare queste API? (suggerimento: no!).
I ragazzi che hanno scritto le specifiche hanno fatto un ottimo lavoro, e ci sono alcuni casi in cui le specifiche sono state scritte "ex-post". XHR è una di queste e adesso abbiamo un'API stabile implementata nei nuovi browser (non parlate più di IE6!). La qual cosa ci porta a "drag and drop". La vera pecora nera delle API. In teoria una delle più potenti che potrebbero far fare il salto di qualità alle nostre applicazioni, ma l'implementazione tecnica è un guaio. PPK (Peter-Pal Koch) ha fatto a pezzi la specifica: è utilizzabile, ma è un po' confusa e lacunosa.
In generale ho trovato che le specifiche per elementi "non-HTML5" sono un po' miste, nel senso che alcune sono ben supportate nei nuovi browser, altre per nulla. SVG è una oldie e adesso veramente utilizzabile con librerie JavaScript come Raphaël.js o SVGWeb (una soluzione basata su Flash). In conclusione, c'è davvero una scelta molto ampia nell'utilizzo di API JavaScript rispetto al "medio evo" di qualche anno fa.

5) Parliamo di Canvas vs. SVG un attimo. Non è forse Canvas un altro rettangolo di pixel un po' come gli Applets Java di una volta? SVG, d'altro canto, è vettoriale e dunque dovrebbe essere la scelta naturale per fare qualcosa con un standard open che adesso si fa in Flash. Quando scegliere Canvas e quando SVG, allora?
Canvas, sotto molti aspetti, è un po' come le API di disegno di Flash. Non è accessibile ed è una "scatola nera". Il discorso è che qua da noi un sacco di aziende, a torto o a ragione, vogliono che le loro animazioni funzionino su iOS, e visto che Flash non funziona su iOS canvas è un'ottima soluzione. Ma è necessario, davvero importante scegliere la tecnologia più adeguata. Non usare canvas solo perchè abbiamo visto un demo di Mario Kart. Bisogna analizzare pro e contra di ognuna – SVG e canvas non sono due tecnologie antagoniste ma piuttosto strumenti diversi per esigenze diverse. Brad Neuberg ha fatto un ottimo lavoro spiegando le differenze fra le due tecnologie (ecco il video). In sostanza:

  • Canvas: serve a manipolare pixel, non è interattiva e va bene per animazioni
  • SVG: interattiva, vettoriale

Scegliete con attenzione!

6) E a proposito delle performance? Non sono forse i grandi Canvas molto lenti, soprattutto su device mobili? Non è un problema per i giochi? Che si può fare per questo?
Beh… sì e no. Sto finendo un progetto che ha un'animazione su un grosso canvas e non è lento sui telefonini (anche se non è stato progettato per questi device). La ragione per cui non è lento è nel modo in cui il canvas viene animato: non deve essere sempre aggiornato a 60fps.
La performance dipende all'applicazione. Bisogna valutare bene l'ambiente, le tecnologie alternative e poi prendere una decisione ragionata. Personalmente non penso che utilizzare canvas per giochi ad altre prestazioni in ambito mobile sia già praticabile. Non penso che i device abbiamo ommph per ottenere risultati apprezzabili – e c'è poi un problema nascosto – il browser del telefono non ce la fa. L'accellerazione hardware potrebbe aiutare ma oggi, in questo momento storico, non penso che vedremo giochi come Angry Birds in JavaScript.
Ciò detto… sto seriamente pensando di replicare un gioco tipo Canabalt usando un mix di canvas, DIVs e CSS. Penso che ce la si può fare.
Penso poi che la nostra community può imparare molto dalla comunity Flash. Ci sono già passati. Persone come Seb Lee-Delisle (@seb_ly / http://seb.ly) stanno facendo un lavoro splendido in questo ambito.

7) Una feature che era originariamente parte di HTML5 e adesso ha una sua specifica è LocalStorage e derivati quali Session Storage o i completi WebSQL e IndexDB. Un'altra cosa è offline storage. Sembra che ci sia una grossa discussione tra i developer su cosa usare e se soluzioni NoSQL dal lato client siano il futuro o no. Che cosa ne pensi? Quando sono da usare e quali sono i limiti?
In un certo senso funziona come (secondo la mia piccola esperienza di) NoSQL, nel senso che cerchi una chiave e ottieni un risultato.
Allo stesso modo penso che SQL nel browser sia esagerato. Vuol dire usare un metodo di storage che *tu* conosci e ficcarlo dentro il browser. Troppa fatica per quello che si ottiene.
Offline Apps ("application cache") dal punto di vista delle API è davvero sexy. Ultra-sexy. L'idea che le nostre applicazioni possano funzionare senza il web e si accorgano quando si va offline è davvero potente. L'unico problema è che la gestione degli eventi fa schifo. L'evento che dice che il tuo browser è offline richiede un intervento dell'utente che dice al browser di "lavorare offline". Un fallimento totale dal punto di vista dell'esperienza. E a peggiorare le cose per quel che ne so non c'è nessun progetto futuro di far funzionare gli eventi offline/online nella maniera adeguata. :-(
Tutto cià detto, i cookies sono morti, secondo me. Devo ancora trovare una soluzione che preveda i cookies da quando ho iniziato a usare Web Storage API – e ci sono un sacco di polyfills per Web Storage – quindi è un'API che si può usare senza preoccupazioni.

8) Cambiando un po' discorso, hai creato HTML5shiv per consentire di mostrare correttamente gli elementi HTML5 su IE. L'idea ha dato origine ad una serie di altre soluzioni per far funzionare IE6 con le nuove tecnologie (o piuttosto simularle). Dov'è il confine? Pensi che ne valga la pena di scrivere così tanto codice per dare un supporto completo a IE6?
Allora, ci sono due aspetti da considerare:

  • Supportare IE6 (suggerimento: no)
  • Polyfills

Per quanto riguarda IE6, seriamente e per l'ennesima volta, date un'occhiata alle statistiche. Se non si conoscono i numeri, cercateli. Se la maggior parte dei vostri utenti usa IE6, video e canvas non funzioneranno mai – neanche con shims e polyfills. IE6 è un vecchio scarpone che non ce la fa più neanche a fare quello che un tempo riusciva a fare. E adesso basta parlare di IE6.
Per quanto riguarda invece i polyfills, la questione è diversa. Non esistono per supportare IE6, esistono per dare ai developer un set di funzionalità di cui fidarsi per tutti i browser. Comunque, vorrei che tutti pensassero bene prima di utilizzarli. Il punto è che questi script integrano API mancanti sui "vecchi browser" (e non intendo solo IE6). Non penso che i developer dovrebbero utilizzare codice "tanto per": bisognerebbe considerare bene che cosa si vuole ottenere e decidere se una certa tecnologia è la soluzione giusta. Se sì, e se si sa che i propri utenti avranno per lo più un browser che non la supporta, bisogna chiedersi se vale la pena "integrarla" con un polyfill o se piuttosto non è meglio cambiare tecnologia.
La stessa cosa si può dire ad esempio quando qualcuno aggiunge jQuery per cambiare o aggiungere una classe ad un elemento. Non ne vale la pena – ma ovviamente quel developer non aveva ben chiaro che cosa doveva fare. Quindi la base è sempre la stessa – educazione e cultura.

9) Dove indirizzeresti le persone che vogliono imparare HTML5? Quali tutorial ti hanno insegnato di più? Dove dovrebbero "girare" le persone interessate?
Che me lo chiedi a fa' – HTML5 Doctor! :)
Suggerisco spesso anche alle persone il mio http://html5demos.com per incoraggarli a dare un'occhiata al codice e fare un po' gli hacker.
Per quanto riguarda i tutorial che mi hanno insegnato molto – ad essere onesto il posto dove ho imparato di più è HTML5 Doctor. Ci sono dei tutorial JavaScript/API davvero buoni anche su http://bocoup.com. E poi, ovviamente, passo molto tempo a spulciare le specifiche, cercando bestioline che non avevo mai visto e stuzzicandole con un bastone…

10) Hai annunciato che stai lavorando ad un framework pensato per rendere semplice l'utilizzo di Websockets. Come procede e per che cosa pensi che Websockets sarà usato in futuro? In sostanza, perchè questa attrazione?
Attrazione mi sembra un po' esagerato 😉 ma è vero, ho iniziato a lavorare ad un progetto che astrae i Web Sockets come servizio. Non semplicemente un'API, che già è semplice di suo, ma un vero e proprio server: creare sessioni, gestione del flusso utente, attesa di altri utenti e altro ancora.
Il servizio si chiama Förbind, parola svedese per "connettersi", cioè connettersi ai proprio utenti. E' ancora nella sua infanzia ma spero di dare accesso alpha a forbind.net questo mese.
Io lavoravo per siti finanziari e il real-time era il trucco: accedere ai dati appena erano disponibili. Adesso tutto ciò è disponibile in maniera nativa nel browser, ed ecco perchè mi piace così!
In più, adoro l'idea di utenti anonimi. Ho creato un sacco di demo dove l'utente può contribuire a qualcosa senza rivelare la sua identità, e quando si tratta di utenti puoi davvero capire quanto è grande la creatività delle persone senza nemmeno sforzarsi. Certo, ti ritrovi con un sacco di piselli disegnati, ma trovi anche delle idee fantastiche – ad esempio la pagina 404 della mia società consente alle persone di lasciare un disegno, una delle più notevoli era un Super Mario in tutto il suo splendore. Gli utenti anonimi mi interessano perchè anche nel grigiore quotidiano un estrano può essere davvero la tua ispirazione

L'intervista originale è qui, il video eccolo: