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

[cdimauro]

Originariamente inviato da calabar

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.

Meglio WebAssembly che consente di svincolarsi dal linguaggio.

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.

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

[calabar]

Originariamente inviato da cdimauro

Meglio WebAssembly che consente di svincolarsi dal linguaggio.

Sono due approcci differenti, da una parte un linguaggio pensato per essere direttamente interpretato e pensato specificatamente per le applicazioni web, dall'altra un codice binario a basso livello ottenibile con qualunque linguaggio.

Il punto è che un approccio non esclude l'altro. Per esempio DART potrebbe rivelarsi un ottimo linguaggio per scrivere codice web, ma anziché essere eseguito direttamente sul browser si potrebbe compilarlo in WebAssembly (del resto è già stato pensato per essere utilizzato insieme ad un compilatore JS per compatibilità con i browser che non supportano direttamente DART, quindi il passo sarebbe breve).
Non è neppure da escludere che molti front-end leggeri vengano comunque realizzati in un linguaggio interpretato (JS o DART, se venisse adottato, anche se pare che Google al momento sia l'unico a crederci).

Del resto l'astrazione dal linguaggio non è una novità, e GWT con il suo compilatore Java->JS ne è forse l'esempio più celebre.

Ad ogni modo credo che non si vedrà nulla di concreto per parecchi anni, il lavoro di standardizzazione e adozione richiederà molto tempo. Però se il vantaggio prestazionale è quello promesso, beh, allora è un bene che abbiano cominciato a muoversi.

[cdimauro]

Si potrebbe fare di più con una virtual machine vera e propria (ma in questo caso saremmo a un livello molto più basso, e certi giochetti sarebbero molto difficili da realizzare).

Qualcosa di simile al CIL di Microsoft ben si presta alla compilazione (AOT o JIT che sia), e peraltro è pure uno standard ECMA (come Javascript), per cui sarebbe stata una scelta più intelligente adottare CLR come runtime base/comune/standard.

Comunque, sì, DART potrebbe anche essere un ottimo linguaggio per il web, ciò non toglie che preferisco che lo si dia in pasto a WebAssembly, come qualunque altro linguaggio. Per essere chiari, preferisco utilizzare il linguaggio che a me piace (Python ) anziché essere costretto a utilizzarne un altro solo per il web.

[GTKM]

Originariamente inviato da cdimauro

Si potrebbe fare di più con una virtual machine vera e propria (ma in questo caso saremmo a un livello molto più basso, e certi giochetti sarebbero molto difficili da realizzare).

Qualcosa di simile al CIL di Microsoft ben si presta alla compilazione (AOT o JIT che sia), e peraltro è pure uno standard ECMA (come Javascript), per cui sarebbe stata una scelta più intelligente adottare CLR come runtime base/comune/standard.

Comunque, sì, DART potrebbe anche essere un ottimo linguaggio per il web, ciò non toglie che preferisco che lo si dia in pasto a WebAssembly, come qualunque altro linguaggio. Per essere chiari, preferisco utilizzare il linguaggio che a me piace (Python ) anziché essere costretto a utilizzarne un altro solo per il web.

Tu il Python lo useresti pure per farti un piatto di pasta, ammettilo.

Effettivamente, a parte gli scherzi, poter utilizzare altri linguaggi (e non dover imparare il JS esclusivamente per il web) sarebbe una cosa particolarmente simpatica.

[cdimauro]

Considerato che non so cucinare... sì.

Trovo seccante dover usare linguaggi che non mi piacciono. Con Python sono enormemente produttivo e il codice è più leggibile e manutenibile, per cui lo userei e vorrei usarlo per qualunque cosa, anche se per lavorare a basso livello non è indicato.

[GTKM]

Originariamente inviato da cdimauro

Considerato che non so cucinare... sì.

Trovo seccante dover usare linguaggi che non mi piacciono. Con Python sono enormemente produttivo e il codice è più leggibile e manutenibile, per cui lo userei e vorrei usarlo per qualunque cosa, anche se per lavorare a basso livello non è indicato.

Hai sicuramente ragione, poi è ovvio che dipende dagli ambiti di utilizzo. Per quanto mi riguarda, tra Python e Java non avrei dubbi.

Tuttavia, in linea generale, tendo ancora a trovarmi meglio con i linguaggi che fanno uso di simboli, piuttosto che di tante keyword, anche se qua, ovviamente, subentra il problema del dover scrivere codice pulito, altrimenti son cazzi...

Ma stiamo divagando.

[Rossi88]

codice Python più manutebilie?? cos'è uno scherzo?

[bobafetthotmail]

Originariamente inviato da cdimauro

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

Piccolo dubbio possibilmente stupido: ma convertire sta roba non comporta dispendio di risorse e attesa?
Lo farà il server no?

O anche fare che prima mi mandano tutto il javascript a casaccio come ora, il browser lo compila e poi dopo lo esegue comunque risulta meglio che interpretarlo sul momento?
Mi pare che Dalvik facesse così comunque, quando avii la app ti ricompila la roba, ed è relativamente rapido.
Poi sono passati ad ART che la compia una volta e la salva nello storage (visto che oramai si hanno mille GB di storage), che è ovviamente meglio.

CIoè coi programmi in genere ha un senso visto che una volta che il programma fa X non è che lo cancelli e poi lo ricompili di nuovo ogni volta, ma una pagina web che in genere non vive nel mio dispositivo per anni?

codice Python più manutebilie?? cos'è uno scherzo?

Dipende molto da chi lo scrive eh.

[Fire-Dragon-DoL]

Originariamente inviato da calabar

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.

Ma no, dart diventerà semplicemente un altro dei tanti linguaggi compilati.

E per la cronaca, google sta portando dart su android e vuole usarlo come linguaggio principale per gestire le animazioni, quindi non mi sembra lo voglia mollare

[cdimauro]

Originariamente inviato da GTKM

Hai sicuramente ragione, poi è ovvio che dipende dagli ambiti di utilizzo. Per quanto mi riguarda, tra Python e Java non avrei dubbi.

Tuttavia, in linea generale, tendo ancora a trovarmi meglio con i linguaggi che fanno uso di simboli, piuttosto che di tante keyword, anche se qua, ovviamente, subentra il problema del dover scrivere codice pulito, altrimenti son cazzi...

Ma stiamo divagando.

Anche perché è più importante scrivere codice ben testato.

Originariamente inviato da Rossi88

codice Python più manutebilie?? cos'è uno scherzo?

Originariamente inviato da Antonio23

per le risse c'è direttamente la sezione "programmazione".

Concordo.

[cdimauro]

Originariamente inviato da bobafetthotmail

Piccolo dubbio possibilmente stupido: ma convertire sta roba non comporta dispendio di risorse e attesa?
Lo farà il server no?

Dici da WebAssembly a qualcosa di direttamente digeribile dal browser? Se è quello, non è affare del server, ma del browser, anche se un server potrebbe intercettare l'agent e far scaricare al browser la normale versione Javascript, quanto meno se il browser non supporta direttamente WebAssembly.

O anche fare che prima mi mandano tutto il javascript a casaccio come ora, il browser lo compila e poi dopo lo esegue comunque risulta meglio che interpretarlo sul momento?

No, è proprio quello che WebAssembly cerca di evitare: compilare ogni volta dal sorgente per generare l'AST. Generare l'AST direttamente da un binario è di gran lunga più veloce ed efficiente.

Mi pare che Dalvik facesse così comunque, quando avii la app ti ricompila la roba, ed è relativamente rapido.

Questo si può e si deve fare dopo che il binario WebAssembly è stato scaricato. E' il naturale, successivo passo.

Poi sono passati ad ART che la compia una volta e la salva nello storage (visto che oramai si hanno mille GB di storage), che è ovviamente meglio.

ART non fa solo quello. Hanno finalmente cambiato completamente la virtual machine, con una più efficiente, prevedendo al contempo la compilazione in binario che viene poi cachata onde evitarlo.

Ma anche così non siamo a livelli paragonabili ai runtime della concorrenza (tempo fa Xamarin mostrò una reimplementazione in C# / Mono che polverizzava Dalvik).

CIoè coi programmi in genere ha un senso visto che una volta che il programma fa X non è che lo cancelli e poi lo ricompili di nuovo ogni volta, ma una pagina web che in genere non vive nel mio dispositivo per anni?

Il discorso è simile alle applicazioni, perché hai pagine web che usi spesso e altre che usi di meno. Penso sia comodo poter aprire & eseguire più velocemente il sito di hwupgrade, che frequentiamo molto. Mentre qualche altro sito che è stato aperto qualche volta, potrà finire nel dimenticatoio col suo WebAssembly.

[bobafetthotmail]

Originariamente inviato da cdimauro

Dici da WebAssembly a qualcosa di direttamente digeribile dal browser?

Nono dicevo convertire le pagine del sito + annessi e connessi in webassembly. Visto che è un linguaggio di transizione, nessuno scrive in webassembly direttamente.

Se la compila il webmaster quindi (gran fatica), o tuttalpiù il server se è contenuto soggetto a modifiche (wiki o forum ad esempio)?

Poi il server manderebbe in giro la roba in webassembly salvo contrordini. Sembra interessante, molto interessante.

Il mio netbook guadagna anni di vita con sta cosa qui.

Ma anche così non siamo a livelli paragonabili ai runtime della concorrenza (tempo fa Xamarin mostrò una reimplementazione in C# / Mono che polverizzava Dalvik).

Che figata! App universali con Xmarin senza sbattimenti di porting. (si lo so che c'entra poco con quello che dici, )
Era un pò ora eh.
Ma rompe un bel pò di scatole a quelli che volevano l'ecosistema chiuso o sbaglio?

Il discorso è simile alle applicazioni, perché hai pagine web che usi spesso e altre che usi di meno.

Sì giusto, la cache su disco e le pagine offline e tutta quella roba lì. Si integra bene quindi...

[cdimauro]

Originariamente inviato da bobafetthotmail

Nono dicevo convertire le pagine del sito + annessi e connessi in webassembly. Visto che è un linguaggio di transizione, nessuno scrive in webassembly direttamente.

Se la compila il webmaster quindi (gran fatica), o tuttalpiù il server se è contenuto soggetto a modifiche (wiki o forum ad esempio)?

Anche se i contenuti fossero soggetti a modifiche, il WebAssembly rimarrebbe sempre lo stesso. Come un'applicazione. Al più lo si aggiorna se il software subisce delle modifiche. Comunque qualunque altra applicazione.

Poi il server manderebbe in giro la roba in webassembly salvo contrordini. Sembra interessante, molto interessante.

Già, l'idea è quella.

Il mio netbook guadagna anni di vita con sta cosa qui.

Idem.

Che figata! App universali con Xmarin senza sbattimenti di porting. (si lo so che c'entra poco con quello che dici, )
Era un pò ora eh.
Ma rompe un bel pò di scatole a quelli che volevano l'ecosistema chiuso o sbaglio?

Beh, a come utente interessa il prodotto finale. Che poi sia aperto, chiuso, a pagamento, o gratis, non me ne può fregar di meno.

Comunque Xamarin mostrò soltanto una ricompilazione (con qualche adattamento) di Android in C# / Mono, presentando i benchmark. Trovo tutto qui.

[Rossi88]

Originariamente inviato da bobafetthotmail

...
Dipende molto da chi lo scrive eh.

Così come per qualsiasi altro linguaggio di programmazione.

Originariamente inviato da Antonio23

per le risse c'è direttamente la sezione "programmazione".

Comunque concordo non è la sezione giusta. E' stato un commento che mi è uscito spontaneo

[Fire-Dragon-DoL]

Originariamente inviato da Rossi88

Così come per qualsiasi altro linguaggio di programmazione.



Comunque concordo non è la sezione giusta. E' stato un commento che mi è uscito spontaneo

Se volete vi mostro come è mantenibile il Java: aono incappato in una classe da 15k righe, sigh. Nessun linguaggio sarebbe sopravvissuto a quella, che sia Java o Python, lol

[bobafetthotmail]

Originariamente inviato da Rossi88

Così come per qualsiasi altro linguaggio di programmazione.

Appunto.

[zappy]

quindi, se non ho capito male, in pratica il browser scarica degli eseguibili e li manda in esecuzione appena apri la pagina web... evviva, la manna per i creatori di malware.

No grazie, preferisco vedere lo script in formato testo ed eventualmente poter leggere cosa fa.

[bobafetthotmail]

capito male, leggi con attenzione il post di cdimauro http://www.hwupgrade.it/forum/showpo...8&postcount=21

Semplicemente si parla di "roba predigerita".

è ovvio che viene "eseguita" dentro al browser e non nel PC, nello stesso modo che le pagine web lo sono.

[LMCH]

Originariamente inviato da cdimauro

Comunque Xamarin mostrò soltanto una ricompilazione (con qualche adattamento) di Android in C# / Mono, presentando i benchmark. Trovo tutto qui.

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

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

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.

[zappy]

Originariamente inviato da bobafetthotmail

capito male, leggi con attenzione il post di cdimauro http://www.hwupgrade.it/forum/showpo...8&postcount=21
Semplicemente si parla di "roba predigerita".

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

è ovvio che viene "eseguita" dentro al browser e non nel PC, nello stesso modo che le pagine web lo sono.

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