Link alla notizia: http://www.hwupgrade.it/news/web/google-microsoft-e-mozilla-insieme-per-webassembly-il-bytecode-per-velocizzare-il-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.

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

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

progetto interessante

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

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.

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.

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. :D

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 :D

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 :D

Spero di no, ma non si sa mai. :D

Spero di no, ma non si sa mai. :D
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.

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? :D

Chiaramente, va detto che bisogna vedere cosa sarà questo WebAssembly, all'atto pratico. Per ora parliamo molto di aria fritta. :sofico:

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.

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.

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

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.

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* :stordita:

* 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 :eek:

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* :stordita:
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 :eek:
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.

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.

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.

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

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.

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 :D) anziché essere costretto a utilizzarne un altro solo per il web.

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 :D) anziché essere costretto a utilizzarne un altro solo per il web.

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

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ì. :D

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.

Considerato che non so cucinare... sì. :D

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. :D

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... :D

Ma stiamo divagando. :D

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

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.

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

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

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... :D

Ma stiamo divagando. :D
Anche perché è più importante scrivere codice ben testato. :D
codice Python più manutebilie?? cos'è uno scherzo?
per le risse c'è direttamente la sezione "programmazione". :O
Concordo. :asd:

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

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. :D

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, :D )
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. :eek: :doh: Sì giusto, la cache su disco e le pagine offline e tutta quella roba lì. Si integra bene quindi...

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. :D
Idem. :)
Che figata! App universali con Xmarin senza sbattimenti di porting. (si lo so che c'entra poco con quello che dici, :D )
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 (http://blog.xamarin.com/android-in-c-sharp/).

...
Dipende molto da chi lo scrive eh.
Così come per qualsiasi altro linguaggio di programmazione.

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

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

Così come per qualsiasi altro linguaggio di programmazione.



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

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

Così come per qualsiasi altro linguaggio di programmazione.Appunto. :D

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. :muro:

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

capito male, leggi con attenzione il post di cdimauro http://www.hwupgrade.it/forum/showpost.php?p=42595758&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.

Comunque Xamarin mostrò soltanto una ricompilazione (con qualche adattamento) di Android in C# / Mono, presentando i benchmark. Trovo tutto qui (http://blog.xamarin.com/android-in-c-sharp/).

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.

capito male, leggi con attenzione il post di cdimauro http://www.hwupgrade.it/forum/showpost.php?p=42595758&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".

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

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.

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.

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.

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.

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

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

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.

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

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

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.