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

[bobafetthotmail]

Originariamente inviato da zappy

roba binaria è roba non leggibile dall'umano, no?

No, un essere umano può leggere anche il binario visto che si sa come lo legge la macchina (chi ha fatto la macchina? un uomo, quindi si sa esattamente come funziona). Ci vuole solo più tempo.
Se vedi comunque nell'articolo parlano di un componente di compatibilità che legge il binario e genera del javascript per farlo leggere a browser che non comprendono il webassembly.
Se vuoi leggere il webassembly in tempi più rapidi probabilmente usi quel componente per tradurlo.

e questo dovrebbe rassicurare qualcuno? non vedo come. "Il browser" non è "il sw pwefetto".

Si sta parlando di pre-compilare le pagine web, il binario è comunque una pagina web con i suoi javacript eccetera. Ma in una forma che è più facile da leggere per la macchina.

Quindi il malware veicolato è lo stesso veicolabile da una pagina web normale, perchè se mandi dei comandi che il browser non supporta l'esecuzione fallisce.

Solo che essendo un pagina precompilata il browser la "esegue" molto più facilmente.

Tutta sta roba avrà un impatto enorme anche sui giochini HTML5 e simili, e anche su app di Chrome/ium

[LMCH]

Originariamente inviato da bobafetthotmail

Quindi il malware veicolato è lo stesso veicolabile da una pagina web normale, perchè se mandi dei comandi che il browser non supporta l'esecuzione fallisce.

WebAssembly dovrebbe essere pure più sicuro.

Questo perche anche il gruppo che sviluppa PNaCl (Portable Native Client) fa parte di quelli che si sono uniti per sviluppare WebAssembly.

Quelli hanno fatto un gran bel lavoro riguardo la generazione di codice sicuro e l'eliminazione di comportamenti indefiniti (che sono fonti di falle di sicurezza) e tutto questo confluirà nei generatori e convertitori di codice usati nelle toolchain e nei runtime WebAssembly.

[cdimauro]

Originariamente inviato da LMCH

E' da notare che la differenza di prestazioni è principalmente legata all'implementazione dei runtime ed a differenti approcci riguardo la retrocompatibilità.

Questo si potrebbe dire se confrontassimo soltanto le hashmap e il thread (ci sono due benchmark in proposito, di cui il primo è mostrato nel grafico), per i quali sono stati usate le classi della rispettiva libreria standard, ma per tutti gli altri test si tratta esclusivamente di number-crunching, e dunque della bontà della VM e del relativo compilatore JIT.

Poi esistono soluzioni molto più performanti e portabili su piattatforme diverse, basati su ecosistemi multipiattaforma tipo Qt e C++ (oppure Qt e Python).

Non amo i linguaggi non-managed, per cui Python mi va benissimo, ma preferirei anche qualcosa tipo C# per roba di più basso livello.

Comunque Qt è un pachiderma: è quasi un s.o. che gira su un s.o.. Va bene nel caso devi wrapper i widget grafici, perché servono toolkit adeguati alle esigenze delle moderne UI, ma per il resto sarebbe una duplicazione di quanto il linguaggio o il s.o. mette già a disposizione.

Infatti, se si ha la proprietà del codice sorgente, la soluzione migliore è non dipendere da specifici runtime e VM o ridurre tali dipendenze al minimo necessario.

Beh, anche quando scegli un linguaggio ti leghi alla sua libreria standard e/o a qualche altra libreria mainstream.

[cdimauro]

Originariamente inviato da zappy

roba binaria è roba non leggibile dall'umano, no?

Esiste anche la versione testuale di WebAssembly, che si può usare per assemblare il binario, oppure può essere generata a partire dal binario.

In ogni caso puoi sempre trasformare il binario in codice Javascript, come t'è già stato detto, ma avendo a disposizione l'intero AST si potrebbe facilmente ricostruire il sorgente (a meno di commenti et similia) con una discreta approssimazione.

[LMCH]

Originariamente inviato da cdimauro

Comunque Qt è un pachiderma: è quasi un s.o. che gira su un s.o.. Va bene nel caso devi wrapper i widget grafici, perché servono toolkit adeguati alle esigenze delle moderne UI, ma per il resto sarebbe una duplicazione di quanto il linguaggio o il s.o. mette già a disposizione.

Dipende da su cosa lo si fa girare e cosa si utilizza, non è mica necessario installare le componenti che non si usano.
Poi ovunque possibile non ci sono duplicazioni inutili di funzionalità.
In confronto i runtime Java e Net sono molto più pesanti e per applicazioni non banali pure i tempi di caricamento non sono significativamente differenti.

Originariamente inviato da cdimauro

Beh, anche quando scegli un linguaggio ti leghi alla sua libreria standard e/o a qualche altra libreria mainstream.

L'importante è che i sorgenti siano accessibili e progettati per essere portabili.
Sotto tale aspetto Qt è semplicemente spettacolare, già ora supporta un range di piattaforme che sia Java che .Net si sognano, passare da runtime win32 a winRT è pure più semplice che usando .Net, esiste già un porting in corso verso PNaCl e non appena fissano uno standard probabilmente verrà supportato anche WebAssembly.

[cdimauro]

Originariamente inviato da LMCH

Dipende da su cosa lo si fa girare e cosa si utilizza, non è mica necessario installare le componenti che non si usano.

Hai ragione. Sperando che non ci siano dipendenze, però.

Poi ovunque possibile non ci sono duplicazioni inutili di funzionalità.
In confronto i runtime Java e Net sono molto più pesanti e per applicazioni non banali pure i tempi di caricamento non sono significativamente differenti.

Senz'altro.

L'importante è che i sorgenti siano accessibili e progettati per essere portabili.
Sotto tale aspetto Qt è semplicemente spettacolare, già ora supporta un range di piattaforme che sia Java che .Net si sognano, passare da runtime win32 a winRT è pure più semplice che usando .Net, esiste già un porting in corso verso PNaCl e non appena fissano uno standard probabilmente verrà supportato anche WebAssembly.

Beh, WebAssembly è comodo per il web, ma è un ambito che personalmente non piace.

Però il discorso non fa una grinza.

[LMCH]

Originariamente inviato da cdimauro

Beh, WebAssembly è comodo per il web, ma è un ambito che personalmente non piace.

In mancanza di informazioni più dettagliate e difficile dire fin dove ci si può spingere, ma come minimo dovrebbe essere interessante per piccole applicazioni e frontend
(anche usando Qt, tanto con il caching sul browser al massimo c'e' un ritardo di avvio solo la prima volta) o anche per demo senza essere costretti a passare per gli app store.

Come dicevo prima, dal mio punto di vista il vantaggio principale è poter riutilizzare codice già scritto e testato a lungo (almeno per quel che riguarda la logica interna) senza sprecare troppo tempo a riscrivere UI, aggiungere wrapper ecc.

[cdimauro]

Capisco e condivido, ma il problema che vedo riguarda Qt: pensare di convertirlo addirittura in WebAssembly mi sembra troppo esagerato. E' già enorme di suo, e il binario che ne verrebbe fuori sarebbe ancora più pachidermico.

Riusare Qt anche in ambito web avrebbe senso soltanto se fosse possibile accedervi direttamente, passando dal browser direttamente alle librerie di questo framework. In buona sostanza, esponendo pubblicamente le API di Qt all'interno di Javascript, come funzioni & classi "first citizen".

[Fire-Dragon-DoL]

Originariamente inviato da cdimauro

Capisco e condivido, ma il problema che vedo riguarda Qt: pensare di convertirlo addirittura in WebAssembly mi sembra troppo esagerato. E' già enorme di suo, e il binario che ne verrebbe fuori sarebbe ancora più pachidermico.

Riusare Qt anche in ambito web avrebbe senso soltanto se fosse possibile accedervi direttamente, passando dal browser direttamente alle librerie di questo framework. In buona sostanza, esponendo pubblicamente le API di Qt all'interno di Javascript, come funzioni & classi "first citizen".

Ma la comparazione non è sbagliata? Non è QT a tirar fuori l'assembly ma il compilatore dal C++, quindi QT potrebbe ipoteticamente essere una libreria (reworkata per il web), quindi al piu col web assembly avremo dei compilatori C++ che compilano web assembly invece che assembly (ipoteticamente).

Speranzosamente, anche qualche compilatore Ruby-Web assembly (questo per mio gusto personale) o simili.

Dopodiché, non serve nessun layer di compatibilità, alla fine la "JVM" del WebAssembly è già il browser, che ha già il suo gigantesco layer di compatibilità.

E ora speriamo lo sfornino in fretta! :P

[cdimauro]

Originariamente inviato da Fire-Dragon-DoL

Ma la comparazione non è sbagliata? Non è QT a tirar fuori l'assembly ma il compilatore dal C++, quindi QT potrebbe ipoteticamente essere una libreria (reworkata per il web), quindi al piu col web assembly avremo dei compilatori C++ che compilano web assembly invece che assembly (ipoteticamente).

E' chiaro che la "conversione" di Qt in WebAssembly la fa un compilatore.

Speranzosamente, anche qualche compilatore Ruby-Web assembly (questo per mio gusto personale) o simili.

Assolutamente sì.

Dopodiché, non serve nessun layer di compatibilità, alla fine la "JVM" del WebAssembly è già il browser, che ha già il suo gigantesco layer di compatibilità.

Esattamente.

E ora speriamo lo sfornino in fretta! :P

Se è ridotto all'osso non dovrebbe servire molto tempo per definirne le specifiche. Ne servirà di più per implementarlo nei vari browser, ovviamente, ma dopo lo sforzo più grosso sarà rappresentato da cosa e come convertire codice esistente in WebAssembly.