Google, Microsoft e Mozilla insieme per WebAssembly, il bytecode per velocizzare il web

Molti degli utenti di Internet nemmeno sanno cosa significhi protocollo. Noi sappiamo che il web è solo una parte di Internet, ma, in percentuale, quanti altri lo sanno? C'è gente che non sa nemmeno che non esiste solo Google come motore di ricerca, di che stiamo parlando?

Chiaramente, va detto che bisogna vedere cosa sarà questo WebAssembly, all'atto pratico. Per ora parliamo molto di aria fritta.

Ma infatti, non è importante che debbano saperlo, l'importante è che si possa, sarà poi il singolo utente a decidere del proprio uso della Rete. Così come era in passato, dove per fare tante cose dovevi, per forza di cose, applicarti almeno un minimo. L'importante è che vi sia sempre una "via di fuga" per l'uso "alternativo" della rete.

Fidati, non introdurrà niente che possa ridurre al singolo utente il suo spazio di manovra.

Trovo positiva la collaborazione tra diversi soggetti nella realizzazione degli standard.
Detto questo penso che andrebbe approfondito quali problematiche di sicurezza questo approccio possa portare.
Tra l'altro trattandosi di codice C/C++ probabilmente la sua diffusione all'interno di progetti avverrà tramite librerie di componenti, non soltanto per comodità, ma per praticità.

Purtroppo è "soltanto" una codifica binaria di un AST. Senz'altro di gran lunga migliore del classico sorgente Javascript da compilare e ottimizzare a dovere, ed è ottimo il fatto di potersi liberare di questo linguaggio e usarne altri. Ma una virtual machine con un'architettura astratta sarebbe stata di gran lunga migliore.

Come fa a non essere una macchina virtuale visto che dovrebbe essere compili una volta e va tutte le parti? Oppure ho capito male?
Io speravo in un ritorno delle Java Applet*

* Era la via giusta solo con fu mai granchè ottimizzata e non era realmente interoperabile con l'HTML, ma se avessero voluto si poteva fare! Sun sembrava avere sempre buone idee, ma poi le lasciava lì... lo stesso Java - un gioello - prima dell'arrivo di Oracle pareva abandonware

Infatti non lo è. Funziona così: se il browser supporta WebAssembly, il binario viene immediatamente convertito nella sua rappresentazione interna (bytecode o direttamente in codice nativo tramite JIT). Se non c'è il supporto, c'è un piccolo stub scritto in Javascript che si occupa di convertire il binario in codice Javascript (e da lì di nuovo parsing, e trasformazione in bytecode o codice nativo).

Magari senza l'enorme framework di Java e con una virtual machine più moderna e orientata prettamente alla compilazione in codice nativo, anziché con interprete.

Il problema è che Java è divenuta una piattaforma enorme e complessa. E' come se fosse un s.o. che gira dentro un s.o..

Molto meglio pensare a una virtual machine più semplice, con un set di librerie più ridotto. Visto che un browser deve avere a che fare col DOM & HTML, ovviamente tutte queste funzionalità andrebbero integrate.

Casomai il contrario, il webassembly punta, come l'assembly, ad essere un qualcosa ottenuto dalla compilazione, quindi un linguaggio che compilato offra il web assembly. Ad oggi si fa la stessa cosa, solo che il codice risultante è javascript (nessun guadagno prestazionale). In questo modo invece avresti sia guadagno prestazionale che la possibilità di sceglierti il linguaggio. Potremmo così finalmente trovarci roba come c# web, ruby web e via dicendo. Nota che ad oggi per qualsiasi progetto grosso sia ha sempre una pipeline di compilazione del javascript di qualche tipo, almeno per concatenare i file.

In che senso "il contrario"?
Escludendo i plugin, oggi il codice oggi viene scritto o compilato in HTML+JS per essere dato in pasto a tutti i browser.
Con DART Google vuole (voleva?) sostituire JS con un linguaggio più "potente" ed adatto al web moderno (eseguibile direttamente dai browser, con tanto di traduttore in JS da usare nel frattempo), ma mi pare evidente come questo progetto superi queste intenzioni e le due tecnologie risulterebbero essere ridondanti.

Quello che mi chiedevo è se l'apertura di questo progetto significa la morte di DART.
Per come la vedo io questo progetto ha lo stesso scopo, con in più il vantaggio delle prestazioni.

Certo, le differenze ci sono. Mentre oggi ci sono alcuni framework che permettono di usare altri linguaggi per scrivere codice web, nel caso di webassembly l'uso di altri linguaggi diventerebbe una prassi.
Mi chiedo però che ripercussioni questo possa avere sulla leggibilità del codice e se ci saranno strumenti che permetteranno di metterci mano. Già oggi il codice compilato per il web può essere offuscato, ma difficilmente queste tecniche sono utilizzate al di fuori delle applicazioni web complesse.

Meglio WebAssembly che consente di svincolarsi dal linguaggio.

In questo caso il binario generato da/per WebAssembly sarà ancora più offuscato, perché non hai codice, ma soltanto (!) una rappresentazione più a basso livello di esso, sotto forma di AST.

Per i non addetti ai lavori, rozzamente di un qualunque codice sorgente viene eseguito il parsing, che genera una struttura dati in memoria chiamata AST (Abstract Syntax Tree), dalla quale è di gran lunga più facile ed efficiente interpretare o compilare.

Per cui è ovvio che il codice originale sarà andato perso, e ci sarà ben poco di leggibile, ma in sostanza quel che conta è tutto ancora lì (parliamo di una rappresentazione di ben più alto livello rispetto a un binario per un'architettura).
Questo significa che è comunque ancora possibile "giocarci" in qualche modo, manipolando l'AST per farci quel che si vuole, prima di darlo in pasto all'interprete o al compilatore.
Per essere chiari, è ancora abbastanza facile intercettare qualche chiamata "indigesta" e rimpiazzarla con... niente oppure semplicemente sostituire una funzione con una "dummy".