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

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

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

di pubblicata il , alle 11:31 nel canale Web
MicrosoftGoogleMozilla
 
I migliori sconti su Amazon oggi

TCL 55T6C 55'' QLED TV 4K HDR, FireTV (SmartTV con Dolby Vision e Atmos, HDR10+, Premi e Chiedi ad Alexa)

349.00€ Compra ora

Lefant M330Pro Robot Aspirapolvere Lavapavimenti con Mappatura, Navigazione dToF, Zona vietata, Evitamento ostacoli PSD, Aspirazione 5000Pa, 150 minuti, Pulizia programmata, Alexa/APP/WiFi,Nero

Compra ora

FRITZ!Repeater 1200 AX Edition International, Ripetitore - Wi-Fi 6 extender Dual Band con 2.400 Mbit/s (5 GHz) & 600 Mbit/s (2,4 GHz), Mesh, Access Point, 1x Gigabit LAN, Interfaccia in italiano

Compra ora
49 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
LMCH22 Giugno 2015, 02:05 #41
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.
cdimauro22 Giugno 2015, 18:47 #42
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.
cdimauro22 Giugno 2015, 18:50 #43
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.
LMCH23 Giugno 2015, 01:51 #44
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.
cdimauro23 Giugno 2015, 07:03 #45
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.
LMCH23 Giugno 2015, 13:05 #46
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.
cdimauro29 Giugno 2015, 22:33 #47
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-DoL29 Giugno 2015, 22:42 #48
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
cdimauro29 Giugno 2015, 22:47 #49
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.
« Pagina Precedente     Pagina Successiva »

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^