NaCl, il precursore
Era il 2010, e stavo compilando la mia tesi, al momento di decidere l’argomento mi sono subito indirizzato verso i sistemi operativi. Mi è stato proposto dal mio professore di studiare la documentazione di una nuova tecnologia sviluppata da Google. La tecnologia in questione era Google Native Client.
Native Client (NaCl da qui in poi) non è l’argomento di questo articolo, tuttavia è stato il primo esempio di esecuzione di codice nativo all’interno di un browser. Ebbene si NaCl permetteva l’esecuzione di codice C, C++, Java, ecc all’interno delle pagine web dei nostri browser mediante la compilazione con una versione opportunamente modificata di GCC (GNU C Ccompiler). Il codice binario generato veniva scaricato dal browser come un qualsiasi asset e veniva poi eseguito all’interno di una sandbox, il tutto interagiva poi con il DOM attraverso il Javascript.
Problematiche
Realizzare una cosa del genere ovviamente implica difficoltà estreme relative alla sicurezza, vi immaginate cosa potrebbe succedere se le pagine web scaricassero ed eseguissero codice binario insicuro? Magari con completo accesso alle risorse della macchina? Ve lo dico io, la totale anarchia informatica e non 🙂 (il panico generato dal caso Meltdown e Spectre ne è un esempio).
NaCl permetteva quindi alle pagine web di eseguire codice con performance paragonabili al codice nativo. Fantastico, ma come mai non ne ho mai sentito parlare prima, vi starete chiedendo.
Semplice, a livello commerciale e di diffusione NaCl è stato un completo fiasco, decisamente troppo visionario come concetto, troppo precursore dei tempi. E poi richiedeva l’installazione di un plugin…
Sviluppi odierni
Il concetto però era troppo interessante e dal potenziale assolutamente illimitato ed inseplorato perché non saltasse fuori sotto altre spoglie ed infatti nel 2018 eccoci a scrivere un articolo sul WebAssembly (wasm da qui in poi). A differenza di NaCl, wasm ha al proprio arco numerose frecce extra. Intanto non è una tecnologia proprietaria ma uno standard aperto sviluppato da W3C. In secondo luogo tutti, e ribadisco tutti, i browser moderni lo supportano già ora nativamente (anche nelle versioni mobile)!
Il funzionamento di base è praticamente quello descritto qui sopra per NaCl, il tutto è al momento limitato a linguaggi che non necessitano di Garbage Collector per funzionare (C, C++, Rust). Il codice viene compilato tramite un apposito compilatore contenuto nella toolchain ufficiale, e viene scaricato dalle pagine web come un qualsiasi altro asset. L’esecuzione deve poi essere “lanciata” dal codice Javascript, al momento non è possibile quindi realizzare un’applicativo web senza l’utilizzo di Javascript che faccia da collante tra il DOM, le Web APIs e i moduli binari wasm.
Diciamo anche che in quel ruolo il Javascript se la cava piuttosto bene, dove invece l’adozione di moduli nativi possa dare un grosso boost sono le parti CPU intesive, ovvero le parti di applicazione che richiedono grosse potenze di elaborazione. Pensate per esempio ad una libereria che permetta l’elaborazione di video e foto.
Wasm al momento ha performance che 30 volte maggiori del normale codice Javascript, oltre a questo i binari sono notevolmente più compatti del codice testuale JS e non deve essere letto, interptato (compilato) ed eseguito. La parte di lettura, controllo sintattico e semantico viene eseguita una sola ed unica volta da chi distribuisce l’applicativo.
Tutto bellissimo, ma perché non lo stanno già utilizzando tutti?
Diciamo che gli ambiti di utilizzo sono abbastanza specifici, il titolo dell’articolo si riferisce al fatto che ci sarà un fiorire di applicativi web molto più complessi ed articolati rispetto a quelli odierni. Il web quindi muterà ma non da un momento all’altro, sarà un mutamento “lento” e costante nel tempo. Oltre a questo utilizzare questi moduli binari implica saper programmare in linguaggi che oggi non sono usati in ambito web, scommetto che non tutti i miei colleghi ne sarebbero capaci.
Al fatto che i siti web puramente informativi o che implicano una limitata tipologia di interazioni non avranno mai bisogno di questa tecnologia va aggiunto una certa immaturità del progetto wasm, tante funzionalità ancora mancano, vedi accesso alle Web APIs piuttosto che funzionalità di debug avanzate del codice nativo.
Insomma all’orizzonte si intravedono avvisaglie interessanti per il mondo delle applicazioni desktop ed in maniera minore mobile (qui c’è un discorso di UI importante da fare), ovvero l’ambiente multipiattaforma per eccellenza sta per entrare a gamba tesa nel mondo degli applicativi CPU intesive mantenendo invariate facilità di accesso da parte dei fruitori dei servizi e complicando di poco la vita agli sviluppatori. Sulla carta, una vittoria schiacciante…