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

[Redazione di Hardware Upg]

Link alla notizia: http://www.hwupgrade.it/news/web/goo...web_57742.html

I tre guru della categoria dei web browser hanno imbastito una partnership per dare alla luce, insieme al team WebKit, un nuovo progetto per rendere più veloce e versatile il web

Click sul link per visualizzare la notizia.

[Nui_Mg]

Notizia che aspettavo da tanto, trooppo tempo: Jit o Aot che sia, ormai il codice javascript (non solo javascript, ma tutto il codice interpretato che costituisce la quasi totalità del web) è diventato molto esoso in termini di risorse occupate, basta guardare, per ogni pagina, nel task manager del proprio browser.

Google ha già fatto un buon lavoro nel mettere a disposizione qualche tempo fa una libreria che aiuta nel diminuire in lossless le dimensioni di png con grafica "solida", spero che continui verso questa direzione (anche perché ne va del proprio business principale).

[calabar]

Mi piacerebbe capire in che rapporto questa tecnologia dovrebbe porsi con DART, ossia quello che Google ritiene (riteneva?) dovesse diventare il nuovo linguaggio per il web, creato per superare i limiti di javascript.

Se questo progetto dovesse prendere piede ho idea che il progetto DART potrebbe essere abbandonato, anche perchè ha incontrato l'ostilità degli altri competitor (che non intendono supportarlo e che, a differenza di Google, non ritengono che per superare gli attuali limiti di JS occorra passare ad un altro linguaggio).

[Apachi22]

progetto interessante

[bobafetthotmail]

Bisogna vedere se questo sistema permette ad eventuali estensioni del browser di intercettare javascript non voluto (pubblicità o tracking).

Perchè se è come ho il sospetto che sia, fare dei binari non permette a me di decidere cosa va e cosa non va. Se il sito fa un blob unico di javascript suo, tracker e pubblicità che faccio, tiro fuori Kali e mi metto a disassemblare il codice a colpi di riga di comando?

Va bene che posso bloccare l'accesso ai siti a prescindere con un ablocker ma le pubblicità possono anche fare tappa sul loro stesso sito, quindi sarei fregato...

[GTKM]

Originariamente inviato da bobafetthotmail

Bisogna vedere se questo sistema permette ad eventuali estensioni del browser di intercettare javascript non voluto (pubblicità o tracking).

Perchè se è come ho il sospetto che sia, fare dei binari non permette a me di decidere cosa va e cosa non va. Se il sito fa un blob unico di javascript suo, tracker e pubblicità che faccio, tiro fuori Kali e mi metto a disassemblare il codice a colpi di riga di comando?

Va bene che posso bloccare l'accesso ai siti a prescindere con un ablocker ma le pubblicità possono anche fare tappa sul loro stesso sito, quindi sarei fregato...

Stavo pensando la stessa cosa, e, secondo me, accadrà proprio quello che dici tu.

[Nui_Mg]

Originariamente inviato da GTKM

Stavo pensando la stessa cosa, e, secondo me, accadrà proprio quello che dici tu.

Ma va là, non ci credo nemmeno se vedo: Google e Mozilla non sono scemi, si darebbero una mega-zappa sui piedoni, è impossibile. Già google ha dimostrato la sua non stupidità nel suo advertising (nonostante sia il suo core business per eccellenza, più delle altre due) pull proprio perché sa bene come potrebbe prenderla l'utente e il fatto che il web non è internet.

[GTKM]

Originariamente inviato da Nui_Mg

Ma va là, non ci credo nemmeno se vedo: Google e Mozilla non sono scemi, si darebbero una mega-zappa sui piedoni, è impossibile. Già google ha dimostrato la sua non stupidità nel suo advertising (nonostante sia il suo core business per eccellenza, più delle altre due) pull proprio perché sa bene come potrebbe prenderla l'utente e il fatto che il web non è internet.

Google, infatti, ha delle regole molto restrittive riguardo l'advertising. Ma questa è una tecnologia a disposizione degli sviluppatori indipendenti.

Per intenderci, tu nel tuo sito potresti realizzare un mega blob in modo tale da impedirmi di bloccare eventuale pubblicità rompiscatole, o elemento tracciante.

A meno che io non abbia semplicemente frainteso il tutto.

[Nui_Mg]

Originariamente inviato da GTKM

Google, infatti, ha delle regole molto restrittive riguardo l'advertising. Ma questa è una tecnologia a disposizione degli sviluppatori indipendenti.

Sì, ma tu credi veramente che Google e soprattutto Mozilla potrebbero dare un potere così estremo al mondo dell'advertising? L'ho detto, non ci credo nemmeno se vedo

[GTKM]

Originariamente inviato da Nui_Mg

Sì, ma tu credi veramente che Google e soprattutto Mozilla potrebbero dare un potere così estremo al mondo dell'advertising? L'ho detto, non ci credo nemmeno se vedo

Spero di no, ma non si sa mai.

[Nui_Mg]

Originariamente inviato da GTKM

Spero di no, ma non si sa mai.

Nell'assurda ipotesi che lo facessero, l'utente avrà sempre l'ultima parola di scegliere (visto che web non corrisponde ad Internet) finché le modifiche vengono fatte a questo layer. Io ancora oggi uso dei protocolli che i "nativi" digitali manco hanno mai usato.

[GTKM]

Originariamente inviato da Nui_Mg

Nell'assurda ipotesi che lo facessero, l'utente avrà sempre l'ultima parola di scegliere (visto che web non corrisponde ad Internet) finché le modifiche vengono fatte a questo layer. Io ancora oggi uso dei protocolli che i "nativi" digitali manco hanno mai usato.

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.

[Nui_Mg]

Originariamente inviato da GTKM

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?

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.

[Nui_Mg]

Originariamente inviato da GTKM

Chiaramente, va detto che bisogna vedere cosa sarà questo WebAssembly,

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

[AleLinuxBSD]

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à.

[cdimauro]

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.

[fano]

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

[cdimauro]

Originariamente inviato da fano

Come fa a non essere una macchina virtuale visto che dovrebbe essere compili una volta e va tutte le parti? Oppure ho capito male?

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).

Io speravo in un ritorno delle Java Applet*

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.

* 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

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.

[Fire-Dragon-DoL]

Originariamente inviato da calabar

Mi piacerebbe capire in che rapporto questa tecnologia dovrebbe porsi con DART, ossia quello che Google ritiene (riteneva?) dovesse diventare il nuovo linguaggio per il web, creato per superare i limiti di javascript.

Se questo progetto dovesse prendere piede ho idea che il progetto DART potrebbe essere abbandonato, anche perchè ha incontrato l'ostilità degli altri competitor (che non intendono supportarlo e che, a differenza di Google, non ritengono che per superare gli attuali limiti di JS occorra passare ad un altro linguaggio).

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.

[calabar]

Originariamente inviato da Fire-Dragon-DoL

Casomai il contrario, ...

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.