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

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

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

Discuss

[cdimauro]

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

Intanto ecco quello che cercavi: Javascript .NET

Ed ecco quello che ho installato sulla mia macchina giusto venerdì: IronPython.
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, 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.

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.
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? Hai C#: usa quello e vivi felice (ndr: solo per chi ama i linguaggi C-like ).

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 , ma ne mina alla base l'adozione da parte di tutti gli zozzoni che usano C & derivati, o altri linguaggi più o meno esotici. 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, 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

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]

Originariamente inviato da Tommo

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

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.

[Tommo]

Originariamente inviato da cdimauro

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
Anche a me sembrava molto strano in effetti... non è che i linguaggi dinamici hanno caratteristiche "speciali" a basso livello.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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...in-the-browser

p.s. dimenticavo il progetto più importante in questo settore http://blog.chromium.org/2010/03/nat...rtability.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]

Originariamente inviato da pabloski

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

p.s. dimenticavo il progetto più importante in questo settore http://blog.chromium.org/2010/03/nat...rtability.html

PNaCL sembra esattamente quello di cui si parla
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
Però a occhio NaCL manca delle varie librerie di contorno (e quindi è inutile per un sacco di roba)?

Originariamente inviato da 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?

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

[dierre]

Originariamente inviato da Tommo

[...]

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]

Originariamente inviato da dierre

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]

Originariamente inviato da Tommo

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]

Originariamente inviato da Tommo

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/native...ocs/audio.html

[tomminno]

Originariamente inviato da 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.

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

[pabloski]

Originariamente inviato da tomminno

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

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

[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]

Originariamente inviato da Tommo

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.

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.

Originariamente inviato da 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.

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

[pabloski]

Originariamente inviato da cdimauro

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]

Originariamente inviato da cdimauro

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
E anche google non credo salterebbe di gioia.

Originariamente inviato da cdimauro

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?

Originariamente inviato da cdimauro

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
Comunque LLVM è anche un'ottimo compilatore per Obj-C.