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

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.

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.

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.

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

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?

Dipende molto da chi lo scrive eh.

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

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


Concordo.

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.

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.

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

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

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.