WebCLI?

[Tommo]

Al mio solito, stavo giocherellando con un'idea di quelle che cambiano le cose (semicit.), in questo caso l'idea di un Bytecode+Runtime standard per il web, implementata dai vari browser.
Perchè javascript puzza e voglio fare siti in C++ :asd:

Dopo un rapido sopralluogo alle tech esistenti (Chrome V8, LLVM, .NET CLI, Python Unladen Swallow) mi sono reso conto che fare una roba del genere è un'impresa titanica sia come tecnologia sia come peso nel mercato, ma non voglio mollare l'osso :D

La butto la, magari per beccare l'interesse di alcuni esperti di bytecode:
un bytecode condiviso eseguibile da un browser, che possa implementare JavaScript ma anche C#, Java o altri, come potrebbe essere strutturato?
E che runtime dovrebbe avere?
Sicuramente un GC opzionale, sicuramente un modo per accedere al DOM della pagina (e ai canvas), poi?

.NET CLI sembra l'ideale, ma non supporta linguaggi dinamici, e quindi tutto il JS esistente sarebbe da buttare al secchio o mantenere in parallelo. Malissimo.
Inoltre MS è odiata da tutti i produttori di browsers, quindi qualsiasi proposta by MS è destinata al fallimento. Triste verità.

LLVM sembra la seconda alternativa migliore, ma andrebbe affiancato da un runtime scritto da 0. Ma almeno è open e type-agnostic.

Certo, scrivere applicazioni web come se fossero applicazioni native sarebbe un nerdgasm non da poco :D

Discuss :read:

[cdimauro]

.NET è l'ideale proprio perché supporta di tutto, quindi anche i linguaggi dinamici.

Intanto ecco quello che cercavi: Javascript .NET (http://javascriptdotnet.codeplex.com/)

Ed ecco quello che ho installato sulla mia macchina giusto venerdì: IronPython (http://ironpython.net/).
Motivazione? Pur lavorando bene con C#, per provare pezzi di codice al solito dovevo compilare il progetto e/o creare apposite pagine da richiamare da dentro l'applicazione principale. Mi sono decisamente rotto le scatole.
Quindi ho duplicato un'icona di DreamPie (http://dreampie.sourceforge.net/), l'ho fatta puntare ad IronPython, e nel giro di pochi secondi smanettavo alacremente con la mia bella shell interattiva, importando qualunque roba da .NET, istanziando classi scritte in chissà quale linguaggio, ispezionandole, manipolandone, e provandole. E in pochissimo tempo ho levato di mezzo i dubbi che avevo. :cool:

Riguardo allo scrivere applicazioni web allo stesso modo di quello che faresti con quelle desktop, lo sto già facendo con Windows Phone 7, e si chiama Silverlight (http://www.silverlight.net/).
Una goduria immensa. A parte la produttività molto elevata, è proprio WPF (Silverlight ne è un sottoinsieme) che è strutturato proprio bene, in maniera molto intelligente.
Però all'inizio è un po' ostico per chi è abituato a sviluppare con altri strumenti. C'è una certa curva di apprendimento. Ma dopo cominci a fare roba turca con XAML, i binding, i converter, e il codice vero e proprio risulta ridotto ai minimi termini.
Insomma, potrebbe lavorarci tranquillamente un grafico / web designer, lasciando al programmatore la business logic nuda e cruda.

Riguardo a C++, potresti utilizzare C++/CLR, ma perché continuare a farsi del male (http://www.codeguru.com/forum/showthread.php?t=368044)? Hai C#: usa quello e vivi felice (ndr: solo per chi ama i linguaggi C-like :cry: ).

Io userei IronPython ovviamente. Altri potrebbero usare IronRuby, F#, IronPHP, o qualunque altro linguaggio disponibile per .NET.

Tra l'altro .NET è uno standard ECMA, e per le parti che non lo sono c'è la Microsoft Community Promise. Infatti Mono sta andando avanti implementando buona parte di .NET, ed è anche disponibile Moonlight (l'equivalente Mono di Silverlight).

LLVM promette bene, ma supporta ancora pochi linguaggi e nemmeno il C++ è stato del tutto completato, se non erro (ma la situazione potrebbe anche essere cambiata nel frattempo).

Inoltre non hai un framework completo come quello che .NET mette a disposizione, e che rappresenta poi il reale valore aggiunto.

Unladen Swallow lascialo perdere perché non c'entra niente. Fa uso di LLVM, ma integrandola dentro CPython, quindi è legata mani e piedi a Python (CPython per l'esattezza) e la cosa personalmente mi fa molto piacere :D, ma ne mina alla base l'adozione da parte di tutti gli zozzoni che usano C & derivati, o altri linguaggi più o meno esotici. :asd: Inoltre il progetto non è mai stato completato e integrato ufficialmente in CPython.

Riguardo al realizzare un nuova virtual machine con nuovo bytecode (io ne ho realizzato uno nuovo (http://code.google.com/p/wpython2/), tra l'altro), è un progetto troppo complesso e non ne vale la pena perché in giro ci sono già delle valide soluzioni.

Hai dimenticato Java, che trovi praticamente ovunque e sulla cui virtual machine ormai girano parecchi linguaggi. Il problema è che... ti ritrovi col framework standard i Java, che può piacere o meno.

[Tommo]

Ma wikipedia diceva che i linguaggi con i tipi dinamici non si potevano implementare in .NET... cazzata :read:

Comunque lo so che adesso esistono *alcuni* linguaggi come Silverlight, Flash o JS... però sono dei plugin, magari non supportati dappertutto, e la sostanza è che l'unica cosa veramente utilizzabile ad oggi per fare un sito fruibile da tutti è l'accozzaglia di JS.

E SilverLight non andrà molto lontano per lo stesso motivo per cui la .NET CLI è da scartare per questa idea, cioè perchè le tecnologie MS al momento sono completamente ignorate o peggio ostacolate dalla concorrenza.
Al momento il mercato da ragione a Google, c'è un'enorme "fame di standard" per le rich web applications, nonostante l'evidente difficoltà tecnica in cui annaspano i browser HTML5 e l'inadeguatezza di fondo di uno strumento come JS.

Infatti l'idea alla base è diciamo "ideologica": gli equilibri di potere nel web di oggi impediscono l'adozione di qualsiasi nuovo linguaggio, e JavaScript è ancora l'unico tool a disposizione dei web developers.
Questo perchè l'idea che ogni linguaggio vada installato tramite plugin o implementato dal browser è semplicemente malato, e lo standard dovrebbe essere più a basso livello. Standardizzare una VM (perchè questo sarebbe) permetterebbe a tutti di far fruire applicazioni complesse compilate con qualsiasi linguaggio, senza preoccuparsi di dipendere da qualche altra azienda e senza preoccuparsi per il futuro.
Senza contare il dato di fatto che quando c'è concorrenza tra le implementazioni di uno standard, è probabile che vinca la migliore.

Non è un caso se nessuno dei siti più visitati usa plugin del browser, i cambiamenti, specie proprietari, sono MOLTO lenti a diffondersi nel web... a noi un plugin sembra "niente di che", ma ci sono ambienti dove il plugin non si può proprio installare, e tutto quello che hai è il browser nudo e crudo.
Tipo qualsiasi smartphone.
Con un plugin il tuo sito non sarà fruibile equamente, e molti non se lo possono permettere.
E poi nessuno vuole dipendere da un'altra azienda, specie se concorrente... chiedi a chiunque usasse Flash prima che iniziassero tutti a dare addosso ad Adobe spingendola a migliorarlo.
Vai, fai FB con Silverlight, così può vederlo solo il 40% della popolazione mondiale, e sei legato mani e piedi ad un'azienda concorrente.

PS: LLVM 2.9 è usato per compilare OSX ed è il compilatore default di XCode4, quindi direi che il suo lavoro lo fa: la cosa interessante è che per fargli supportare altri linguaggi, basta tradurre questi nel suo IR, senza modificarlo. Che è esattamente quello che intendevo fare.

[cdimauro]

Ma wikipedia diceva che i linguaggi con i tipi dinamici non si potevano implementare in .NET... cazzata :read:
:rotfl: Ma questa poi... Io posso capire che il VECCHIO CLR non avesse SPECIFICO supporto per i linguaggi dinamici, ma si potevano implementare lo stesso.

Adesso non so a partire da quale versione, ma nel CLR è stato aggiunto il supporto diretto ai linguaggi dinamici. Questo, però, per un solo motivo: AIUTARE nell'implementazione dei linguaggi dinamici. E aggiungiamo pure aiutare l'integrazione con gli altri linguaggi a tipizzazione statica.
Comunque lo so che adesso esistono *alcuni* linguaggi come Silverlight, Flash o JS... però sono dei plugin, magari non supportati dappertutto, e la sostanza è che l'unica cosa veramente utilizzabile ad oggi per fare un sito fruibile da tutti è l'accozzaglia di JS.

E SilverLight non andrà molto lontano per lo stesso motivo per cui la .NET CLI è da scartare per questa idea, cioè perchè le tecnologie MS al momento sono completamente ignorate o peggio ostacolate dalla concorrenza.
Al momento il mercato da ragione a Google, c'è un'enorme "fame di standard" per le rich web applications, nonostante l'evidente difficoltà tecnica in cui annaspano i browser HTML5 e l'inadeguatezza di fondo di uno strumento come JS.
Che vuoi farci: il W3C ha scelto questa strada, anziché buttare tutto e ricostruire da zero il web del futuro.

Da questo punto di vista non c'è scampo: qualunque proposta di soluzione innovativa è destinata all'oblio. Manco a parlarne, insomma.
Infatti l'idea alla base è diciamo "ideologica": gli equilibri di potere nel web di oggi impediscono l'adozione di qualsiasi nuovo linguaggio, e JavaScript è ancora l'unico tool a disposizione dei web developers.
Questo perchè l'idea che ogni linguaggio vada installato tramite plugin o implementato dal browser è semplicemente malato, e lo standard dovrebbe essere più a basso livello.
Ma alla fine tutti sono costretti a supportare JavaScript e il DOM...
Standardizzare una VM (perchè questo sarebbe) permetterebbe a tutti di far fruire applicazioni complesse compilate con qualsiasi linguaggio, senza preoccuparsi di dipendere da qualche altra azienda e senza preoccuparsi per il futuro.
Senza contare il dato di fatto che quando c'è concorrenza tra le implementazioni di uno standard, è probabile che vinca la migliore.
Benissimo, e allora perché non usare .NET/CLR che è uno standard ECMA? Tra l'altro sono disponibili implementazioni per quasi tutte le piattaforme.

Tutto ciò se l'obiettivo è quello di avere a disposizione soltanto la virtual machine. E a questo punto il browser si limiterebbe a caricare il codice oggetto IL e a eseguirlo nella VM.
Non è un caso se nessuno dei siti più visitati usa plugin del browser, i cambiamenti, specie proprietari, sono MOLTO lenti a diffondersi nel web... a noi un plugin sembra "niente di che", ma ci sono ambienti dove il plugin non si può proprio installare, e tutto quello che hai è il browser nudo e crudo.
Tipo qualsiasi smartphone.
Con un plugin il tuo sito non sarà fruibile equamente, e molti non se lo possono permettere.
E poi nessuno vuole dipendere da un'altra azienda, specie se concorrente... chiedi a chiunque usasse Flash prima che iniziassero tutti a dare addosso ad Adobe spingendola a migliorarlo.
Vai, fai FB con Silverlight, così può vederlo solo il 40% della popolazione mondiale, e sei legato mani e piedi ad un'azienda concorrente.
D'accordissimo, ma allora la sola VM "standard" non ti basta. Tu parlavi prima di un layer di livello molto basso da esporre, ma da programmatore il mio giudizio è netto: non te ne fai niente!

Una virtual machine DEVE ormai portarsi dietro un framework che aiuti nello sviluppo del codice. Non è pensabile di doversi reinventare la ruota per l'n-esima volta.

.NET da questo punto di vista è messo bene: la parte standard offre già qualcosa come 2mila classi a disposizione.
PS: LLVM 2.9 è usato per compilare OSX ed è il compilatore default di XCode4, quindi direi che il suo lavoro lo fa:
Hum. Ma non è scritto in C/Objective-C?
la cosa interessante è che per fargli supportare altri linguaggi, basta tradurre questi nel suo IR, senza modificarlo. Che è esattamente quello che intendevo fare.
OK, se ti fermi alla sola virtual machine ti può bastare. Ma da sviluppatore a me non basterebbe. :D

[Tommo]

:rotfl: Ma questa poi... Io posso capire che il VECCHIO CLR non avesse SPECIFICO supporto per i linguaggi dinamici, ma si potevano implementare lo stesso.


Vabbè, wikipedia :asd:
Anche a me sembrava molto strano in effetti... non è che i linguaggi dinamici hanno caratteristiche "speciali" a basso livello.


Ma alla fine tutti sono costretti a supportare JavaScript e il DOM...


JavaScript e il DOM potrebbero essere due cose distinte, e non ha granchè senso che oggi sono la stessa cosa: il primo è il linguaggio, il secondo è una struttura dati standard. Non vedo perchè non potrebbe essere rappresentato o modificato in C, C# o qualunque altro.
Di sicuro il DOM dovrebbe essere parte della specifica, perchè senza il web è poca roba.


Benissimo, e allora perché non usare .NET/CLR che è uno standard ECMA? Tra l'altro sono disponibili implementazioni per quasi tutte le piattaforme.


Microsoft. Il Web è uno strano guazzabuglio di tecnologia e politica, fatto sta che MS si è fatta odiare da Apple, Google e dalla maggioranza dei web developers, quindi questa ipotesi è fallimentare.
Inoltre è una iniziativa che dovrebbe partire da MS, ma a quanto pare non sembrano aver collegato i puntini (hanno browser, SO e VM... portati avanti separatamente. boh).
Concordo che sembra fatta apposta cmq.


D'accordissimo, ma allora la sola VM "standard" non ti basta. Tu parlavi prima di un layer di livello molto basso da esporre, ma da programmatore il mio giudizio è netto: non te ne fai niente!
Una virtual machine DEVE ormai portarsi dietro un framework che aiuti nello sviluppo del codice. Non è pensabile di doversi reinventare la ruota per l'n-esima volta.


Su questo non c'è dubbio, infatti mi chiedevo cosa dovrebbe essere parte dello standard, cioè deve essere offerto dal browser, e cosa invece si implementa on-top come WebCL.
Che io sappia le librerie di JS, C# e Python sono implementate nei rispettivi linguaggi, quindi sarebbero distribuibili in bytecode esattamente come tutto il resto.
Poi ad un certo punto ci sono chiamate native e strutture runtime come il GC, e quelle bisogna standardizzarle assieme al linguaggio.
L'idea è che se si offrono gli strumenti giusti, il framework può implementarlo lo sviluppatore del linguaggio, com'è oggi per i linguaggi desktop, in modo che sia browser-agnostic.
Quindi sicuramente andrebbe offerta una libreria nativa per ottenere il DOM (o anche solo l'HTML), un GC, poi?

Come cambiamento non sarebbe distruttivo: un browser che gira WebCL dovrebbe essere in grado di usarlo per compilare un qualsiasi sito "tradizionale" JS lato client senza alcun cambiamento: i primi tempi il cambiamento sarebbe del tutto invisibile, come fa la V8 di chrome (che internamente compila in bytecode).
Il divertimento inizia quando i developers sfruttano esplicitamente WebCL e mandano bytecode compilato lato server invece che JS testuale.


Hum. Ma non è scritto in C/Objective-C?


LLVM è fatto in C++ mi pare, e compila senza problemi C/C++/Obj-C come farebbe gcc.
Data una traduzione dell'IR compilerebbe anche qualsiasi altra cosa, ma appunto è "low level" e quindi manca del tutto di un runtime dato.
Però se l'idea è fornire uno standard di basso livello su cui costruire, questo potrebbe essere un vantaggio perchè non decide niente per lo "strato superiore".

[pabloski]

Non perdere le speranze, qualcosa si muove http://ajaxian.com/archives/llvm-and-running-c-as-well-as-python-in-the-browser

p.s. dimenticavo il progetto più importante in questo settore http://blog.chromium.org/2010/03/native-client-and-web-portability.html

[dierre]

Premettendo che non ho capito per intero la problematica, ma usare un bytecode non richiedere comunque al browser la necessità di avere un modulo installato per funzionare? In cosa la tua idea è differente rispetto ad usare Flex oppure Silverlight?

[Tommo]

Non perdere le speranze, qualcosa si muove http://ajaxian.com/archives/llvm-and-running-c-as-well-as-python-in-the-browser

p.s. dimenticavo il progetto più importante in questo settore http://blog.chromium.org/2010/03/native-client-and-web-portability.html

PNaCL sembra esattamente quello di cui si parla :D
Ma d'altra parte questa faccenda ha terribilmente senso per Chrome OS, senza sarebbe una roba inutile.
Sono sicuro che prima o poi ci arriveranno, bisogna solo che qualcuno tira fuori il coraggio di proporla :D
Però a occhio NaCL manca delle varie librerie di contorno (e quindi è inutile per un sacco di roba)?

Premettendo che non ho capito per intero la problematica, ma usare un bytecode non richiedere comunque al browser la necessità di avere un modulo installato per funzionare? In cosa la tua idea è differente rispetto ad usare Flex oppure Silverlight?

Javascript ha bisogno di un modulo? La VM sarebbe standard e definita solo su carta, poi ogni browser implementa la propria.

[dierre]

[...]

Javascript ha bisogno di un modulo? La VM sarebbe standard e definita solo su carta, poi ogni browser implementa la propria.

Uhm...what? Non ti seguo.

[Tommo]

Uhm...what? Non ti seguo.

Dico... il modulo ci sarebbe, ma sarebbe sviluppato da chi realizza il browser, come JavaScript, che non ha bisogno di moduli esterni. La VM sarebbe dentro al browser stesso.
Che poi già ora il browser è una VM per JavaScript... in pratica bisognerebbe "solo" generalizzarla.

La differenza con AS e Silverlight sarebbe che non esiste un'azienda che fornisce l'unica implementazione come plugin, ma al contrario sarebbe un linguaggio senza "implementazioni di riferimento", come HTML, Javascript, SQL, etc.

[dierre]

Dico... il modulo ci sarebbe, ma sarebbe sviluppato da chi realizza il browser, come JavaScript, che non ha bisogno di moduli esterni. La VM sarebbe dentro al browser stesso.
Che poi già ora il browser è una VM per JavaScript... in pratica bisognerebbe "solo" generalizzarla.

La differenza con AS e Silverlight sarebbe che non esiste un'azienda che fornisce l'unica implementazione come plugin, ma al contrario sarebbe un linguaggio senza "implementazioni di riferimento", come HTML, Javascript, SQL, etc.

Ah ok! Come il Native Client di Chrome?

[Tommo]

Più tipo il portable native client che ha linkato sopra pabloski, però standardizzato.

NaCL liscio in pratica esegue codice x86 nella sandbox, non fa granchè di più.
E' specifico a macchine x86 che girano chrome, le app vanno ricompilate per NaCL, non offre librerie, in pratica è un autoinstaller HTML e pure scarso.
Non credo che si possa fare un'implementazione di JavaScript che gira su NaCL, mi sembra un pò troppo limitato.

[pabloski]

Però a occhio NaCL manca delle varie librerie di contorno (e quindi è inutile per un sacco di roba)?

si, per ora è così e non so come google voglia procedere

su chromeos si appoggiano a google closure ma mi chiedo cosa intendano fare su windows, macos e linux ( visto che loro affermano di volerlo portare pure lì )

perà ho trovato qualche info interessante http://code.google.com/chrome/nativeclient/docs/audio.html

[tomminno]

Più tipo il portable native client che ha linkato sopra pabloski, però standardizzato.

NaCL liscio in pratica esegue codice x86 nella sandbox, non fa granchè di più.
E' specifico a macchine x86 che girano chrome, le app vanno ricompilate per NaCL, non offre librerie, in pratica è un autoinstaller HTML e pure scarso.
Non credo che si possa fare un'implementazione di JavaScript che gira su NaCL, mi sembra un pò troppo limitato.

Ci sarebbe un binding Qt per NaCL.
Chissà cosa succederebbe ad usare Webkit dentro Webkit :sofico:

[pabloski]

Ci sarebbe un binding Qt per NaCL.
Chissà cosa succederebbe ad usare Webkit dentro Webkit :sofico:

si sta tutto muovendo molto in fretta

è evidente che ormai hanno già deciso di scavarci la fossa del cloud e buttarci tutti noi dentro

mah, speriamo che almeno qualche distro linux non cloud resti in vita :D

[Tommo]

Mah io lo vedo come una cosa positiva, il "cloud cattivo" è quello dove il client è un'interfaccia irrilevante e tutta la logica deve passare dal server...
indubbiamente questo stato di cose dipende anche dagli strumenti inadatti a sviluppare pagine web ricche lato client.
Se potessi pubblicare un'app seria, il cloud diventerebbe un pò il mezzo di distribuzione del software, sarebbe il passo successivo rispetto agli AppStore.

Con NaCL sarebbe possibile muovere "nel cloud" anche compilatori, media player, IM, giochi etc, senza che tutti i dati che produco debbano passare dal server.
Il web permetterebbe però di accedere a qualunque applicazione con un indirizzo; garantirebbe software sandboxed (altro che user mode) e sempre aggiornato, e opzioni potenti di connettività stile google docs.

Però NaCL non riesce a sembrarmi valido, non credo possa essere usato a breve.

[pabloski]

ChromeOS va in questa direzione e infatti uno dei cavalli di battaglia è proprio il caching di dati e applicazioni. Poi ho notato che non è vero che è legato esclusivamente al cloud di google, ma ogni applicazione può operare come meglio crede.

Il problema del cloud è semmai la difficoltà di mantenere online un'infrastruttura del genere. Ad esempio un domani ci troveremo ad usare 10 servizi cloud, su ognuno di questi abbiamo un bel pò di dati e altra roba utile. Va già uno di questi tizi, anche per mezza giornata, finiamo in guai con la g maiuscola.

Le aziende che propagandano il cloud hanno sempre battuto su un tasto in particolare e cioè l'indistruttibilità dell'infrastruttura. Ma Amazon è andata giù per un paio di giorni, Google ogni tanto zoppica da qualche parte, Aruba ha subito una disfatta meno di un mese fa.

Insomma, è tutto bello a parole, ma se non fanno qualcosa per aumentare l'affidabilità, ci ritroveremo in un mondo dove oggi siamo online e facciamo di tutto e domani torniamo a spaccare pietre nelle cave.

[cdimauro]

JavaScript e il DOM potrebbero essere due cose distinte, e non ha granchè senso che oggi sono la stessa cosa: il primo è il linguaggio, il secondo è una struttura dati standard. Non vedo perchè non potrebbe essere rappresentato o modificato in C, C# o qualunque altro.
Facciamo Python, va. :D
Di sicuro il DOM dovrebbe essere parte della specifica, perchè senza il web è poca roba.
Concordo.
Microsoft. Il Web è uno strano guazzabuglio di tecnologia e politica, fatto sta che MS si è fatta odiare da Apple, Google e dalla maggioranza dei web developers, quindi questa ipotesi è fallimentare.
Su questo ci sarebbe di che discutere. Finora tanti sviluppatori web che hanno lavorato con gli strumenti di Microsoft ne hanno parlato bene.

Se ti riferisci alla famigerata "browser war" & co., ci sarebbe di che discuterne (e su Appunti Digitali ne abbiamo parlato non poco, in particolare nei commenti ad alcuni articoli).
Inoltre è una iniziativa che dovrebbe partire da MS, ma a quanto pare non sembrano aver collegato i puntini (hanno browser, SO e VM... portati avanti separatamente. boh).
Concordo che sembra fatta apposta cmq.
In realtà Microsoft non può far altro che presentare la sua tecnologia sotto forma di plugin, come hanno fatto tutti gli altri. Ormai Javascript rappresenta lo standard (e lo è a tutti gli effetti) per il web.
Su questo non c'è dubbio, infatti mi chiedevo cosa dovrebbe essere parte dello standard, cioè deve essere offerto dal browser, e cosa invece si implementa on-top come WebCL.
Che io sappia le librerie di JS, C# e Python sono implementate nei rispettivi linguaggi, quindi sarebbero distribuibili in bytecode esattamente come tutto il resto.
Poi ad un certo punto ci sono chiamate native e strutture runtime come il GC, e quelle bisogna standardizzarle assieme al linguaggio.
L'idea è che se si offrono gli strumenti giusti, il framework può implementarlo lo sviluppatore del linguaggio, com'è oggi per i linguaggi desktop, in modo che sia browser-agnostic.
Quindi sicuramente andrebbe offerta una libreria nativa per ottenere il DOM (o anche solo l'HTML), un GC, poi?
Per me è indispensabile un framework come Silverlight per non dover riscrivere n-mila volte la ruota, e magari ogni volta diversa. Quella di scrivere "rich-application" è ormai un'esigenza comune: tanto vale accontentare gli sviluppatori offrendo un solido e produttivo strumento, soprattutto standard.
Come cambiamento non sarebbe distruttivo: un browser che gira WebCL dovrebbe essere in grado di usarlo per compilare un qualsiasi sito "tradizionale" JS lato client senza alcun cambiamento: i primi tempi il cambiamento sarebbe del tutto invisibile, come fa la V8 di chrome (che internamente compila in bytecode).
Il divertimento inizia quando i developers sfruttano esplicitamente WebCL e mandano bytecode compilato lato server invece che JS testuale.
Sì, ma per fare cosa? Vedi sopra.
LLVM è fatto in C++ mi pare, e compila senza problemi C/C++/Obj-C come farebbe gcc.
Mi riferivo a OS X.
Data una traduzione dell'IR compilerebbe anche qualsiasi altra cosa, ma appunto è "low level" e quindi manca del tutto di un runtime dato.
Però se l'idea è fornire uno standard di basso livello su cui costruire, questo potrebbe essere un vantaggio perchè non decide niente per lo "strato superiore".
Come già detto, non mi serve. Io voglio una piattaforma completa, altrimenti non ha senso uno standard di così basso livello.
ChromeOS va in questa direzione e infatti uno dei cavalli di battaglia è proprio il caching di dati e applicazioni. Poi ho notato che non è vero che è legato esclusivamente al cloud di google, ma ogni applicazione può operare come meglio crede.

Il problema del cloud è semmai la difficoltà di mantenere online un'infrastruttura del genere. Ad esempio un domani ci troveremo ad usare 10 servizi cloud, su ognuno di questi abbiamo un bel pò di dati e altra roba utile. Va già uno di questi tizi, anche per mezza giornata, finiamo in guai con la g maiuscola.

Le aziende che propagandano il cloud hanno sempre battuto su un tasto in particolare e cioè l'indistruttibilità dell'infrastruttura. Ma Amazon è andata giù per un paio di giorni, Google ogni tanto zoppica da qualche parte, Aruba ha subito una disfatta meno di un mese fa.

Insomma, è tutto bello a parole, ma se non fanno qualcosa per aumentare l'affidabilità, ci ritroveremo in un mondo dove oggi siamo online e facciamo di tutto e domani torniamo a spaccare pietre nelle cave.
Nulla vieta di avere copiato in locale ciò che sta sul cloud.

[pabloski]

Nulla vieta di avere copiato in locale ciò che sta sul cloud.

è vero e sembra che almeno le aziende implicate nel cloud computing l'abbiano capito

mi chiedo quanto durerà e in che misura gli utenti acquisiranno questa buona abitudine....non sottovalutiamo la capacità dell'utonto di fare cose stupide e dannose

sicuramente in molti penseranno che avere i dati solo in remoto è tanto bello e pratico, salvo poi lamentarsi quando il facebook o il google di turno andranno down

[Tommo]

Su questo ci sarebbe di che discutere. Finora tanti sviluppatori web che hanno lavorato con gli strumenti di Microsoft ne hanno parlato bene.

Se ti riferisci alla famigerata "browser war" & co., ci sarebbe di che discuterne (e su Appunti Digitali ne abbiamo parlato non poco, in particolare nei commenti ad alcuni articoli).


Mi riferisco al fatto che l'idea di Apple che mette .NET dentro Safari per iPhone mi fa ridere di gusto :asd:
E anche google non credo salterebbe di gioia.


Per me è indispensabile un framework come Silverlight per non dover riscrivere n-mila volte la ruota, e magari ogni volta diversa. Quella di scrivere "rich-application" è ormai un'esigenza comune: tanto vale accontentare gli sviluppatori offrendo un solido e produttivo strumento, soprattutto standard.


Non chiedevo cosa serve a te sviluppatore finale, visto che è scontato che quantomeno, qualsiasi framework di oggi deve essere al livello di JS;
mi chiedevo cosa WebCL dovrebbe offrire per permettere di costruire un qualsiasi framework, cioè il passo precedente.
Ad esempio, mettiamo che voglia offrire una versione di JS compilata in WebCL e compatibile con tutti i siti attuali, cosa mi servirebbe da parte del browser?


Mi riferivo a OS X.


OSX ha diversi strati (4 esposti con API) è fatto in ObjC solo nello strato Cocoa, quello più elevato.
In linea di massima è possibile fare qualsiasi cosa usando C liscio e i vari livelli di Core API :read:
Comunque LLVM è anche un'ottimo compilatore per Obj-C.

[tomminno]

Mi riferisco al fatto che l'idea di Apple che mette .NET dentro Safari per iPhone mi fa ridere di gusto :asd:


Apple vuole solo che tu faccia App non un qualcosa di riusabile ovunque. Altrimenti non guadagnerebbe con lo store.
Apparentemente spinge per Html5, ma nei fatti tutto porta alla scrittura di App custom. Ovvero il percorso inverso a quello intrapreso dal resto del mondo da 10 anni a questa parte.

[cdimauro]

è vero e sembra che almeno le aziende implicate nel cloud computing l'abbiano capito

mi chiedo quanto durerà e in che misura gli utenti acquisiranno questa buona abitudine....non sottovalutiamo la capacità dell'utonto di fare cose stupide e dannose
Che possiamo farci: ne faranno sempre comunque, cloud o non cloud, sicurezza o non sicurezza.
sicuramente in molti penseranno che avere i dati solo in remoto è tanto bello e pratico, salvo poi lamentarsi quando il facebook o il google di turno andranno down
FB è messo sulla buona strada: tante volte ho trovato che non mi funzioni.

Cosa diversa per Google con GMail: quasi mai è stato inaccessibile. Certo, alla sfiga non c'è mai limite. :asd:
Mi riferisco al fatto che l'idea di Apple che mette .NET dentro Safari per iPhone mi fa ridere di gusto :asd:
E anche google non credo salterebbe di gioia.
Non v'è dubbio, ma alla fine Safari non è nemmeno tutta farina del suo sacco, visto che ha saccheggiato Konqueror/KHTML per realizzarlo (creando WebKit). Idem per la toolchain di compilazione.

Insomma, integrare roba non fatta da lei è diventata una prassi da quando ha tirato fuori OS X, se ha ritenuto che fosse valida.
Non chiedevo cosa serve a te sviluppatore finale, visto che è scontato che quantomeno, qualsiasi framework di oggi deve essere al livello di JS;
mi chiedevo cosa WebCL dovrebbe offrire per permettere di costruire un qualsiasi framework, cioè il passo precedente.
Ad esempio, mettiamo che voglia offrire una versione di JS compilata in WebCL e compatibile con tutti i siti attuali, cosa mi servirebbe da parte del browser?
Se conoscessi WebCL ti potrei rispondere, ma al momento per me rimane una sigla e una piccola descrizione (wrapper OpenCL per JavaScript).

Se, invece, parli in generale di una virtual machine che carica bytecode, anche con una microscopica puoi costruirci sopra dei framework complessi.
OSX ha diversi strati (4 esposti con API) è fatto in ObjC solo nello strato Cocoa, quello più elevato.
In linea di massima è possibile fare qualsiasi cosa usando C liscio e i vari livelli di Core API :read:
Sì, ma mi riferivo a tutto il codice: è scritto in C oppure Objective-C, mi pare. Non in C++.
Comunque LLVM è anche un'ottimo compilatore per Obj-C.
Sì, lo so. Manca un pieno supporto a C++, se non ricordo male (compresa la standard library, insomma). Mi sembra che alcuni progetti in C++ riesca a compilarli, mentre altri no.
Apple vuole solo che tu faccia App non un qualcosa di riusabile ovunque. Altrimenti non guadagnerebbe con lo store.
Apparentemente spinge per Html5, ma nei fatti tutto porta alla scrittura di App custom. Ovvero il percorso inverso a quello intrapreso dal resto del mondo da 10 anni a questa parte.
Non è il massimo sviluppare con HTML5 + JavaScript. Io preferisco utilizzare strumenti comodi, anche se ti vincolano a una singola piattaforma.

Mi pare che esistano anche soluzioni cross-platform che traducano poi tutto in HTML5 + JS, ma non me ne sono mai interessato.

[Tommo]

Se conoscessi WebCL ti potrei rispondere, ma al momento per me rimane una sigla e una piccola descrizione (wrapper OpenCL per JavaScript).

Se, invece, parli in generale di una virtual machine che carica bytecode, anche con una microscopica puoi costruirci sopra dei framework complessi.


Si intendevo un "Web Common Language", non l'esistente WebCL figlio di OpenCL :D
OpenCL implementato a parte come WebCL è proprio una di quelle cose che dovrebbe essere sostituita da un framework di base comune, come WebSockets, Canvas, etc.

Comunque la gente chiama e Google risponde:
http://aras-p.info/blog/2011/06/02/notes-on-native-client-pepper-plugin-api/

Sembra esattamente quello che avevo pensato, con la differenza che non espone le feature a livello di "bytecode" ma a livello di C. Che guardando al supporto attuale di C, è quasi la stessa cosa.

[pabloski]

Sembra esattamente quello che avevo pensato, con la differenza che non espone le feature a livello di "bytecode" ma a livello di C. Che guardando al supporto attuale di C, è quasi la stessa cosa.

e il C sale nuovamente sul podio :D

appello agli studenti: studiate il C, il maledetto C, l'ubiquo C, l'universale C !!

[cdimauro]

@Tommo: ho letto il documento, ma il fatto di usare il C non è garanzia di portabilità, perché al browser viene passato il codice oggetto (binario) che qualcuno avrà compilato per NaCL.

Quindi si dovrebbe provvedere a fornire binari per qualunque architettura, con tutti i problemi che si porta dietro una soluzione del genere (persino per x86 è possibile compilare per specifiche implementazioni).

Meglio un Intermediate Language, che permette di risolvere tutti questi problemi. ;)
e il C sale nuovamente sul podio :D

appello agli studenti: studiate il C, il maledetto C, l'ubiquo C, l'universale C !!
Vade retro, satana!

[pabloski]

@Tommo: ho letto il documento, ma il fatto di usare il C non è garanzia di portabilità, perché al browser viene passato il codice oggetto (binario) che qualcuno avrà compilato per NaCL.

Quindi si dovrebbe provvedere a fornire binari per qualunque architettura, con tutti i problemi che si porta dietro una soluzione del genere (persino per x86 è possibile compilare per specifiche implementazioni).

Meglio un Intermediate Language, che permette di risolvere tutti questi problemi. ;)


pNaCl è la soluzione a quello che chiedi



Vade retro, satana!

eh lo so ma satana è potente :D

[Tommo]

@Tommo: ho letto il documento, ma il fatto di usare il C non è garanzia di portabilità, perché al browser viene passato il codice oggetto (binario) che qualcuno avrà compilato per NaCL.

La cosa è pensata per PNaCL, cioè quello in cui si distribuisce LLVM IR.
E' anche vero che se vuoi farti particolarmente male puoi compilare in IR, ma il C ha un suo senso considerato il tipo di linguaggi che servirebbero sul web.
Alla prima prerelease provo a farci un qualche videogioco :D

[cdimauro]

pNaCl è la soluzione a quello che chiedi
In tal caso il C può anche uscire di scena. :D
eh lo so ma satana è potente :D
Poi ti fai male però. :fagiano:
La cosa è pensata per PNaCL, cioè quello in cui si distribuisce LLVM IR.
Allora ci siamo.
E' anche vero che se vuoi farti particolarmente male puoi compilare in IR, ma il C ha un suo senso considerato il tipo di linguaggi che servirebbero sul web.
Ma proprio no: il C è quanto di più lontano possa servire per il web.

Comunque con LLVM si può decidere di sviluppare in linguaggi diversi.

Il C potrebbe anche essere usato per alcune parti e/o librerie, al solito, per venire poi "consumato" da altri linguaggi.
Alla prima prerelease provo a farci un qualche videogioco :D
Ne hai di tempo. :p

[Tommo]

Ma proprio no: il C è quanto di più lontano possa servire per il web.

Tutte le macchine virtuali sono implementate in C; per il web servono linguaggi interpretati.
See the connection? :D

[tomminno]

Meglio un Intermediate Language, che permette di risolvere tutti questi problemi. ;)


Il problema dell'IL è il trovare qualcuno che ne scriva l'implementazione C per tutte le piattaforme da supportare :D

[cdimauro]

Sull'implementazione della virtual machine metto le mani avanti: se non altro per l'enorme diffusione del C, purtroppo non c'è niente di meglio di questo linguaggio (poi una VM non è roba da milioni di righe di codice, per fortuna).

Avevo capito che si volesse utilizzare il C per scrivere applicazioni web, e mi ero UN TANTINO preoccupato. :D

[Z80Fan]

L'idea non è male, una vm leggera potrebbe essere più efficiente di javascript, oltre a permettere di sfruttare tutte le tecnologie usate nel campo dei compilatori.

Idea un po' matta: e se facessimo in modo che gli opcode della VM siano caratteri ASCII validi? Magari non otteniamo la compattezza di un codice puramente binario, ma limitiamo cmq la dimensione da uno script JS standard; in tal modo è possibile integrarli in un documento HTML senza troppi problemi.
La cosa poi carina di JS è che è possibile scrivere programmi senza tool, a parte un editor di testo e il browser...
Sull'implementazione della virtual machine metto le mani avanti: se non altro per l'enorme diffusione del C, purtroppo non c'è niente di meglio di questo linguaggio (poi una VM non è roba da milioni di righe di codice, per fortuna).
C++ vorrei indicare, non tanto per le sue "funzioni avanzate", ma quelle piccole cose che sono molto utili e che il C non ha (come ti sei lamentato sull'articolo di Appunti Digitali)
Avevo capito che si volesse utilizzare il C per scrivere applicazioni web, e mi ero UN TANTINO preoccupato.
Pensa che con la mia idea uno potrebbe programmare applicazioni web in ASSEMBLY :ciapet:

[Kralizek]

vedo che il masochismo è ancora una piaga diffusa tra i programmatori... :rolleyes:

[pabloski]

Idea un po' matta: e se facessimo in modo che gli opcode della VM siano caratteri ASCII validi?

tipo la codifica base64 ?

vedo che il masochismo è ancora una piaga diffusa tra i programmatori... :rolleyes:

a me pare un'ottima idea ed inoltre è una necessità molto sentita nel mondo web

[Z80Fan]

tipo la codifica base64 ?

No non una codifica dell'output binario del compilatore, ma un vero e proprio linguaggio macchina composto però solo da cifre ASCII valide, quindi potrebbe essere A per add, J per jump ecc...
Ovviamente usando 1 carattere = 1 istruzione è possibile averne solo 95, quindi se è necessario averne di più si può usare un "architettura" a istruzioni di lunghezza variabile, per niente complicata visto che non dobbiamo implementarla in hardware.

[pabloski]

No non una codifica dell'output binario del compilatore, ma un vero e proprio linguaggio macchina composto però solo da cifre ASCII valide, quindi potrebbe essere A per add, J per jump ecc...
Ovviamente usando 1 carattere = 1 istruzione è possibile averne solo 95, quindi se è necessario averne di più si può usare un "architettura" a istruzioni di lunghezza variabile, per niente complicata visto che non dobbiamo implementarla in hardware.

In pratica un assembly.

[Z80Fan]

In pratica un assembly.
Non direi proprio assembly, perchè non ci saranno magari etichette o macro ecc... però si possono aggiungere anche quelle per fare una sorta di "assembly interpretato"

[Tommo]

No non una codifica dell'output binario del compilatore, ma un vero e proprio linguaggio macchina composto però solo da cifre ASCII valide, quindi potrebbe essere A per add, J per jump ecc...
Ovviamente usando 1 carattere = 1 istruzione è possibile averne solo 95, quindi se è necessario averne di più si può usare un "architettura" a istruzioni di lunghezza variabile, per niente complicata visto che non dobbiamo implementarla in hardware.

Tutta questa roba non è necessaria, HTML supporta i file binari da sempre :D

Basta mettere da qualche parte

<embed=filedibytecode.class type=application/bytecode>vari parametri</embed>

E passa la paura, senza compilcarsi la vita con l'ASCII :D

In questo modo puoi passare programmi flash, exe, silverlight... mai scaricato qualcosa da internet? :asd:

[Z80Fan]

Tutta questa roba non è necessaria, HTML supporta i file binari da sempre :D

Basta mettere da qualche parte

<embed=filedibytecode.class type=application/bytecode>vari parametri</embed>

E passa la paura, senza compilcarsi la vita con l'ASCII :D

In questo modo puoi passare programmi flash, exe, silverlight... mai scaricato qualcosa da internet? :asd:

Qualcuno sta facendo confusione... ;)
Sicuramente ti stai confondendo con l'HTTP, cioè il protocollo con cui il browser scarica la pagina/file dal server remoto.
Il tag HTML <embed> non include niente nella pagina .html, che è solo un file testuale, ma indica al browser di avviare un programma locale al client che elaborerà il file indicato dall'attributo "src".
Io intendevo mettere il bytecode nel file html, come si fa con uno script JavaScript, e cioè
<script type="text/myByteCode">...</script>
e non farlo caricare da un plugin esterno come avviene per Flash ad esempio.

Almeno, questo è quello che ho capito volevate fare :)

[Tommo]

No sei te che fai confusione :asd:

L'HTML è quello che specifica embed; HTTP è un formato binario data-agnostic (nonostante il nome), a parte gli header, quindi se mandi bytecode o testo nel payload, per HTTP non fa differenza.

Il tag embed serve appunto a dire che un "file qualsiasi" è parte della pagina, non c'entra con i plugin vari; è solamente un pezzo di pagina che non rientra nella specifica HTML. E per questo al 99% si usa per i plugin.
Ma in fondo anche il tuo è un plugin, quindi dov'è il problema :D

PS: mettere il bytecode nella pagina è urendo, non credo sia un problema obbligare a metterlo in un file separato.

[cdimauro]

L'idea non è male, una vm leggera potrebbe essere più efficiente di javascript, oltre a permettere di sfruttare tutte le tecnologie usate nel campo dei compilatori.
In verità Javascript non è legato a nessuna VM, e infatti c'è un'accesa competizione in questo campo, visto che il linguaggio è alla base del web 2.0.
Idea un po' matta: e se facessimo in modo che gli opcode della VM siano caratteri ASCII validi? Magari non otteniamo la compattezza di un codice puramente binario, ma limitiamo cmq la dimensione da uno script JS standard; in tal modo è possibile integrarli in un documento HTML senza troppi problemi.
La cosa poi carina di JS è che è possibile scrivere programmi senza tool, a parte un editor di testo e il browser...
Non è così, e sono d'accordo con quanto scritto da Tommo. Aggiungo che inserire bytecode direttamente nel sorgente HTML è una soluzione che non mi piace assolutamente, perché preferisco separare la descrizione della pagina da quella di un componente "esterno".

Altra cosa, la dimensione aumenterebbe anziché diminuire, a motivo della minore efficienza. Sottolineo, inoltre, che la codifica standard per le pagine è UTF-8 (che io ricordi :fagiano:), e non ASCII, dunque sarebbe possibile codificare le informazioni in maniera più efficiente rispetto al vecchio standard.
C++ vorrei indicare, non tanto per le sue "funzioni avanzate", ma quelle piccole cose che sono molto utili e che il C non ha (come ti sei lamentato sull'articolo di Appunti Digitali)
Di già il C non è implementato perfettamente seguendo lo standard. Col C++ la situazione è peggiore, e tra l'altro non è disponibile per qualunque piattaforma.

Non è un caso che molto codice venga ancora scritto in ANSI C89, proprio per questione di maggior portabilità (praticamente tutti i compilatori lo supportano).

Se limitiamo il discorso alle funzionalità, fra i due sceglierei... il D. :D
Pensa che con la mia idea uno potrebbe programmare applicazioni web in ASSEMBLY :ciapet:
http://www.thelivecommunity.it/forum/images/smilies/famale.gif
vedo che il masochismo è ancora una piaga diffusa tra i programmatori... :rolleyes:
C'è chi preferisce il masichismo... :asd:

[Kralizek]

C'è chi preferisce il masichismo... :asd:

Vauro? :Prrr:

[cdimauro]

Anche da quelle parti arriva? :D

[Kralizek]

OT

si, ho sia Rai1 che Rai2 anche se certa roba viene oscurata ogni tanto. Ad ogni modo me lo sto vedendo ora in streaming in ufficio ché ieri ero fuori a fare baldoria :P

[Z80Fan]

No sei te che fai confusione :asd:
Beh...
Tutta questa roba non è necessaria, HTML supporta i file binari da sempre :D

In questo modo puoi passare programmi flash, exe, silverlight... mai scaricato qualcosa da internet? :asd:
Da queste frasi (più nella seconda) pensavo che stessi facendo confusione tra HTML e HTTP, perchè scaricare file da internet non c'entra con embed...

Ma in fondo anche il tuo è un plugin, quindi dov'è il problema :D
Ma non si voleva farlo integrato nel browser?

PS: mettere il bytecode nella pagina è urendo, non credo sia un problema obbligare a metterlo in un file separato.
Aggiungo che inserire bytecode direttamente nel sorgente HTML è una soluzione che non mi piace assolutamente, perché preferisco separare la descrizione della pagina da quella di un componente "esterno".
Puoi sempre metterlo in un'altra pagina, richiamata con link o script, come avviene già per i css e per gli script js; non volevo dire che deve stare per forza nella pagina HTML principale...

In verità Javascript non è legato a nessuna VM
Infatti non lo ho detto; i browser moderni usano tecniche di compilazione Just-in-time; attuando una precompilazione da sorgente a bytecode pensavo che le prestazioni potessero aumentare e semplificare anche gli interpreti.

Non è così...
Scusa ma non ho capito su cosa sei contrario, perchè ho scritto un po' di roba in quel quote...

Altra cosa, la dimensione aumenterebbe anziché diminuire, a motivo della minore efficienza
Ovviamente gli opcode saranno ottimizzati in base al lavoro che devono fare, quindi avremmo un opcode "get element by id", o un opcode "set attribute" ecc... come ho detto prima, non è una macchina da implementare in hardware, si possono mettere tutti gli opcode più strani.

Di già il C non è implementato perfettamente seguendo lo standard. Col C++ la situazione è peggiore, e tra l'altro non è disponibile per qualunque piattaforma.
Lo vuoi compilare sul Commodore 64? :D
No cmq, queste "funzioni avanzate" a cui pensavo erano semplicemente l'ereditarietà singola tra strutture, niente di esotico.

[Kralizek]

Ovviamente gli opcode saranno ottimizzati in base al lavoro che devono fare, quindi avremmo un opcode "get element by id", o un opcode "set attribute" ecc... come ho detto prima, non è una macchina da implementare in hardware, si possono mettere tutti gli opcode più strani.

come fa un qualsiasi minifier, perö in bytecode?


var a = document.getElementById;

var myItem = a("myItem");

[Z80Fan]

come fa un qualsiasi minifier, perö in bytecode?


var a = document.getElementById;

var myItem = a("myItem");


Uhm mi sfuggiva il fatto che getElementById fosse un metodo di document...
In effetti forse la faccenda è un po' più complessa di quanto credessi (indipendentemente cmq dal formato degli opcode).

Si potrebbero fare delle istruzioni particolari che si mappano a funzioni usate comunemente (come appunto document.getElementById), e per tutte le altre si farà come nel tuo esempio.

[Tommo]

Uhm mi sfuggiva il fatto che getElementById fosse un metodo di document...
In effetti forse la faccenda è un po' più complessa di quanto credessi (indipendentemente cmq dal formato degli opcode).

Si potrebbero fare delle istruzioni particolari che si mappano a funzioni usate comunemente (come appunto document.getElementById), e per tutte le altre si farà come nel tuo esempio.

Credo che a fare così, tanto vale usare Javascript. Il browser deve comunque smazzarsi out-of-the box funzioni complesse, e quindi la situazione rimarrebbe invariata.

Tantopiù che sarebbe impossibile compilare C, o altri linguaggi in modo da usare quelle istruzioni con toolchain esistenti, quindi hai buttato via tutti i compilatori esistenti in una botta sola :D

L'unico modo secondo me è fare un vero assembly fatto di vere istruzioni RISC, magari stack based tipo MS CLI o SSA tipo LLVM IR... di certo non una robaccia testuale embedded con dentro un misto di istruzioni low level e high level, che poi si agganciano alle funzionalità offerte dal browser come librerie con interfaccia standard (a quel punto realizzate come preferisce chi fa il browser).

[Z80Fan]

Credo che a fare così, tanto vale usare Javascript. Il browser deve comunque smazzarsi out-of-the box funzioni complesse, e quindi la situazione rimarrebbe invariata.
Beh qualcosa il browser dovrà implementarla, non è che possiamo sostituire tutto con un framework esterno...

Tantopiù che sarebbe impossibile compilare C, o altri linguaggi in modo da usare quelle istruzioni con toolchain esistenti, quindi hai buttato via tutti i compilatori esistenti in una botta sola :D
I toolchain in qualsiasi caso non vanno bene, perchè bisogna scrivere o portare il compilatore per generare il giusto codice; una volta fatto questo, perchè non si potrebbe usare le istruzioni? Si scrivono le librerie che le usano.

L'unico modo secondo me è fare un vero assembly fatto di vere istruzioni RISC, magari stack based tipo MS CLI o SSA tipo LLVM IR... di certo non una robaccia testuale embedded con dentro un misto di istruzioni low level e high level, che poi si agganciano alle funzionalità offerte dal browser come librerie con interfaccia standard (a quel punto realizzate come preferisce chi fa il browser).
Troppo RISC non può essere, bisogna trovare il giusto bilanciamento di semplicità e densità di codice; per questo dicevo di mettere istruzioni più complesse, ma molto comuni da rendere vantaggioso l'inserimento.

Si, precedentemente mi ero focalizzato troppo su JavaScript, dovevo pensare più in generale; cmq l'idea del codice ascii mi sembra ancora valida.