Al momento, l'unico linguaggio pienamente supportato e lo standard di fatto per la manipolazione dell'albero DOM nel browser è JavaScript. Sembra che abbia profondi problemi di progettazione che lo rendono un campo minato di bug e falle di sicurezza per i principianti.

Conoscete qualche iniziativa esistente o pianificata per introdurre una lingua migliore (riprogettata) di qualsiasi tipo (non solo javascript) per la manipolazione dell'albero DOM e richieste HTTP nei browser di prossima generazione? In caso affermativo, qual è la roadmap per la sua integrazione in, diciamo, Firefox, e se no, per quali motivi (a parte l'interoperabilità) dovrebbe essere JavaScript l'unica lingua supportata sulla piattaforma del browser?

Ho già usato jQuery e ho anche letto "javascript: le parti buone". In effetti i suggerimenti sono buoni, ma ciò che non sono in grado di capire è: perché solo JavaScript? Sul lato server (la tua piattaforma OS preferita), possiamo manipolare un albero DOM con ogni lingua, anche fortran. Perché il lato client (la piattaforma del browser) supporta solo javascript?

Il problema con JavaScript non è il linguaggio stesso: è un linguaggio prototipo e dinamico perfettamente valido. Se vieni da un background OO c'è un po 'di una curva di apprendimento, ma non è colpa della lingua.

Molte persone credono che Javascript sia come Java perché ha una sintassi simile e un nome simile, ma in realtà è molto più simile a lisp. In realtà è abbastanza adatto alla manipolazione del DOM.

Il vero problema è che è compilato dal browser e ciò significa che funziona in modo molto diverso a seconda del client.

Non solo l'attuale DOM è diverso a seconda del browser, ma c'è una grande differenza in termini di prestazioni e layout.

Modifica dopo il chiarimento in questione

Supponiamo che siano supportate più lingue interpretate - hai ancora gli stessi problemi. I vari browser sarebbero comunque difettosi e avere DOM diversi.

Inoltre, dovresti avere un interprete integrato nel browser o in qualche modo installato come plug-in (che potresti verificare prima di pubblicare la pagina) per ogni lingua. Ci sono voluti anni per rendere Javascript coerente.

Non puoi usare i linguaggi compilati allo stesso modo, quindi stai introducendo un eseguibile che non può essere facilmente esaminato per quello che fa. Molti utenti sceglierebbero di non lasciarlo funzionare.

OK, che ne dici di una sorta di sandbox per il codice compilato? Mi sembra Java Applets. O ActionScript in Flash. O C # in Silverlight.

Che dire di un qualche tipo di standard IL? Questo ha più potenziale. Sviluppa in qualsiasi lingua tu voglia e poi compilarlo in IL, che il browser quindi JIT.

Tranne, Javascript è già un po 'quel IL - basta guardare GWT . Ti consente di scrivere programmi in Java, ma di distribuirli come HTML e JS.

Modifica dopo ulteriori chiarimenti in questione

Javascript non è, o meglio non è stato, l'unica lingua supportata dai browser: nei tempi bui di Internet Explorer si poteva scegliere tra Javascript o VBScript da eseguire in IE. Tecnicamente IE non ha nemmeno eseguito Javascript: ha eseguito JScript (principalmente per evitare di dover pagare Sun per la parola java , Oracle possiede ancora il nome Javascript ).

Il problema era che VBScript era proprietario di Microsoft, ma anche che non era molto buono. Mentre Javascript stava aggiungendo funzionalità e ottenendo i migliori strumenti di debug in altri browser (come FireBug) VBScript rimase solo IE e praticamente non debug (gli strumenti di sviluppo in IE4 / 5/6 non esistevano). Nel frattempo VBScript si è anche espanso fino a diventare uno strumento di scripting piuttosto potente nel sistema operativo, ma nessuna di queste funzionalità era disponibile nel browser (e quando lo erano diventavano enormi falle di sicurezza).

Esistono ancora alcune applicazioni interne aziendali che usano VBScript (e alcune si basano su quelle falle di sicurezza), e stanno ancora eseguendo IE7 (hanno fermato IE6 solo perché MS alla fine l'ha ucciso).

Portare Javascript allo stato attuale è stato un incubo e ha impiegato 20 anni. Non ha ancora un supporto coerente, con alcune funzionalità linguistiche (specificate nel 1999) ancora mancanti da alcuni browser e molti shim richiesti.

L'aggiunta di una lingua alternativa per l'interpretazione nei browser deve affrontare due problemi principali:

• Consentire a tutti i fornitori di browser di implementare il nuovo standard linguistico, qualcosa che non sono ancora riusciti a utilizzare JavaScript per 20 anni.

• Una seconda lingua potenzialmente diluisce il supporto che hai già, consentendo (ad esempio) a IE di avere un supporto Javascript di seconda qualità ma un ottimo VBScript (di nuovo). Non voglio davvero scrivere codice in lingue diverse per browser diversi.

Va notato che Javascript non è "finito" - si sta ancora evolvendo per migliorare nei nuovi browser. L' ultima versione è anni prima delle implementazioni dei browser e stanno lavorando a quella successiva.

Compila in Javascript

Per ora, l'uso di un linguaggio che si compila in Javascript sembra essere l'unico modo realistico per raggiungere tutte le piattaforme mentre si scrive codice più intelligente, e questo probabilmente rimarrà per molto tempo. Con qualsiasi nuova offerta, ci sarà sempre qualche motivo per cui uno o più venditori non si affretteranno a spedirla.

(Ma non credo proprio che questo sia un problema. Ormai Javascript è stato ben ottimizzato. Anche il codice macchina non è sicuro se scritto a mano, ma funziona bene come obiettivo di compilazione e linguaggio di esecuzione.)

Così tante opzioni

C'è un pool di lingue in continua crescita che si compila in Javascript. Un elenco abbastanza completo può essere trovato qui:

• Elenco delle lingue che vengono compilate in JS nel Wiki Coffeescript

Degno di nota

Ne citerò alcuni che ritengo degni di nota (mentre senza dubbio trascurando alcune gemme di cui non sono a conoscenza):

• Spider è apparso nel 2016. Afferma di prendere le migliori idee di Go, Swift, Python, C # e CoffeeScript. Non è typesafe, ma ha alcune caratteristiche di sicurezza minori .

• Elm : Haskell potrebbe essere il linguaggio più intelligente di tutti, ed Elm è una variante di Haskell per Javascript. È altamente sensibile al tipo e conciso e offre la Programmazione reattiva funzionale come alternativa pulita ai modelli reattivi o agli spaghetti MVC. Ma potrebbe essere un vero shock per i programmatori procedurali .

• Google's Go è mirato a concisione, semplicità e sicurezza. Il codice Go può essere compilato in Javascript da GopherJS .

• Dart è stato il tentativo successivo di Google di sostituire Javascript. Offre interfacce e classi astratte attraverso una sintassi simile a C / Java con digitazione opzionale.

• Haxe è come ActionScript di Flash, ma può indirizzare più lingue in modo che il codice possa essere riutilizzato nei programmi Java, C, Flash, PHP e Javascript. Offre oggetti dinamici e sicuri.

• Opalang aggiunge zucchero sintattico a Javascript per fornire accesso diretto al database , continuazioni intelligenti, controllo del tipo e assistenza nella separazione client / server. (Legato a NodeJS e MongoDB.)

• GorillaScript , "un linguaggio di compilazione in JavaScript progettato per potenziare l'utente nel tentativo di prevenire alcuni errori comuni". è simile a Coffeescript ma più completo, fornendo un sacco di funzioni extra per aumentare la sicurezza e ridurre i modelli ripetitivi di boilerplate.

• LiteScript rientra tra Coffeescript e GorillaScript. Offre sintassi asincrona / yield per callback "inline" e verifica errori di battitura.

• TypeScript di Microsoft è un piccolo superset di Javascript che consente di inserire restrizioni di tipo sugli argomenti delle funzioni, che potrebbero rilevare alcuni bug. Allo stesso modo BetterJS ti consente di applicare restrizioni, ma in puro Javascript, aggiungendo chiamate extra o specificando i tipi nei commenti JSDoc. E ora Facebook ha offerto Flow che esegue anche l'inferenza di tipo.

• LiveScript è uno spin-off di Coffeescript che era popolare per la sua brevità ma non mi sembra molto leggibile. Probabilmente non è il migliore per le squadre.

Come scegliere?

Quando si sceglie una lingua alternativa, ci sono alcuni fattori da considerare :

• Se in futuro altri sviluppatori si uniranno al tuo progetto, quanto tempo impiegheranno ad accelerare e ad imparare questa lingua, o quali sono le probabilità che lo sappiano già?

• La lingua ha troppe funzionalità (il codice sarà ancora pieno di boilerplate) o troppe funzionalità (ci vorrà molto tempo per padroneggiare e fino ad allora un codice valido potrebbe essere indecifrabile)?

• Ha le caratteristiche di cui hai bisogno per il tuo progetto? (Il tuo progetto ha bisogno del controllo del tipo e delle interfacce? Ha bisogno di continuazioni intelligenti per evitare l'inferno del callback nidificato? C'è molta reattività? Potrebbe essere necessario rivolgersi ad altri ambienti in futuro?)

Il futuro...

Jeff Walker ha scritto una serie stimolante di post sul blog sul "problema Javascript", incluso il motivo per cui non ritiene che né TypeScript , né Dart né Coffeescript offrano soluzioni adeguate. Suggerisce alcune caratteristiche desiderabili per un linguaggio migliorato nella conclusione .

JavaScript dovrebbe essere l'unica lingua supportata sulla piattaforma del browser?

Sì e no. Esiste un'alternativa là fuori chiamata Dart di Google che si compila in JavaScript e proprio come jQuery cerca di rendere un po 'più facile la manipolazione del DOM. Potrebbe essere divertente sperimentare, dai un'occhiata.

• Da Google vedere La lingua dei dardi
• Da Microsoft vedere il linguaggio TypeScript

Guarda anche

• Olmo
• Kal

È vero che Javascript era a un certo punto notoriamente difficile da gestire, ma la comunità di sviluppo web ha fatto molta strada da allora. Invece, ti incoraggio a dare un'occhiata a jQuery . È facile e risolve tutti i vari problemi.

E davvero non ci sono alternative che funzionano su tutta la linea. Mi viene in mente Flash, ma anche questo è lo script ECMA ed è probabilmente un kill over per la maggior parte delle cose.

A breve termine, userei cose come jQuery per nascondere le incompatibilità del browser. A lungo termine, tecnologie come Silverlight o Adobe AIR potrebbero renderlo un campo minato molto diverso (ma ancora un campo minato) in futuro.

Doug Crockford ha parlato a Google descrivendo in dettaglio le parti cattive e buone di JavaScript e il suo futuro. In realtà non è cambiato molto dal 1999, il che si può dire che sia una buona cosa (praticamente tutti i browser possono eseguire lo stesso codice purché siano a conoscenza dei loro limiti) e Doug mostra dove si trovano le parti buone erano per lo più incomprensioni che si rivelano molto potenti.

Per manipolazione DOM, guarda JQuery come una libreria lato client che sostituisce la maggior parte dell'API DOM orribile con operazioni che sono difficili da scrivere su pezzi di codice piuttosto eleganti che sono più facili da scrivere.

Se stai pensando che JavaScript abbia problemi profondi, raccomando il libro di Doug Crockford, JavaScript: The Good Parts . (O Google per "Crockford JavaScript" per trovare diverse presentazioni video che ha realizzato.) Crockford delinea un sottoinsieme sicuro e una serie di pratiche ed elenca in modo specifico alcune parti del linguaggio da evitare.

Non sono a conoscenza dei piani per sostituire JavaScript come mezzo di fatto per manipolare il DOM. Quindi meglio imparare ad usarlo in modo sicuro e bene.

In termini di client lato Javascript è l'unico modo per manipolare il DOM. In termini di lato server ci sono molti modi.

Internet Explorer supporta linguaggi di script collegabili, sebbene l'unico incluso in modo affidabile con IE oltre a JScript sia VBScript.

Per quanto ho visto, sembra esserci una sorta di distorsione generale nei confronti di linguaggi dinamici nel browser e JavaScript sembra soddisfare questa esigenza in modo sufficientemente adeguato che gli effetti di rete rendono qualsiasi altra lingua un antipasto. Il linguaggio è in realtà abbastanza potente, sebbene la sua implementazione nei browser lasci molto a desiderare.

Se sei disposto a limitare i tuoi clienti / visitatori a browser specifici e possibilmente a richiedere loro di installare un plug-in, puoi guardare MS Silverlight : una panoramica leggibile è su Wikipedia . Con Silverlight 2, puoi eseguire, lato client, codice che hai scritto in C #, IronPython, IronRuby, VB.NET, ecc .; il clone Moonlight gratuito di Silverlight, del progetto Mono, promette di portare la stessa funzionalità su Linux.

In pratica, la maggior parte degli sviluppatori di app e siti Web preferisce raggiungere un pubblico più vasto di quello che Silverlight (e alla fine Moonlight) può attualmente offrire, il che significa attenersi a Javascript, o possibilmente Flash (che utilizza un linguaggio di programmazione simile, Actionscript).

Quindi, ottenere una sostanziale condivisione della mente, l'adozione e la trazione per qualsiasi altra cosa si sta rivelando una lotta in salita anche per Microsoft con i suoi grandi gruppi di ingegneri e budget di marketing e un progetto di software libero sul lato (per eventualmente alleviare le preoccupazioni sul lock-in proprietario ) - il che può aiutare a spiegare perché l'interesse, per esempio da parte della Mozilla Foundation, è molto scarso nel perseguire tale obiettivo. "A parte l'interoperabilità", dite: ma chiaramente il problema dell'interoperabilità è IL GRANDE qui, dato ciò che osserviamo sui progressi di Silverlight ...

Come già detto, hai Flash (ActionScript, che è un linguaggio derivato da Javascript) e Silverlight / Moonlight (IronPython, IronRuby, JScript, VBScript, C #) che possono essere eseguiti nel browser tramite plugin (il primo è molto più onnipresente) .

C'è anche un'altra alternativa se ti piace Ruby: HotRuby , è un'implementazione ruby ​​in javascript che verrà eseguita nel browser. Non è ancora molto maturo, ma puoi dargli un'occhiata.

Una cosa che non ho visto menzionato (oh, vedo Alcides menzionato HotRuby mentre stavo scrivendo e Nosredna ha menzionato GWT e Script #) e che vorrei buttare lì c'è una serie di implementazioni di [insert language] -on- JavaScript (ad es. Traduttori che consentono di convertire Ruby , Python , C # , Java , Obj-J / Cappuccino [simile a Obj-C / Cocoa] o Processing [per Canvas] in JavaScript sul client o prima della distribuzione [e alcuni di cui dispongono anche di varie librerie di astrazione]). Ovviamente c'è un sovraccarico prestazionale se viene tradotto sul client, ma se ti senti più a tuo agio con un'altra lingua ti consentirà una certa flessibilità.

Personalmente, però, consiglio di imparare ad amare JavaScript. È un linguaggio eccellente, potente e abbastanza elegante una volta che lo conosci. Sto affrontando il dilemma opposto, chiedendomi un po 'di avere una soluzione JavaScript / DOM sul lato server che soddisfi tutte le mie esigenze. / opinione non richiesta

No. JavaScript è, ma si evolverà. La prossima versione è "JavaScript Harmony" e puoi saperne di più se lo fai su Google.

Di tanto in tanto qualcuno suggerisce di inserire un interprete di codice byte nei browser insieme a JavaScript. Probabilmente non accadrà, almeno per un po '.

Mi capita di amare JavaScript. Ma ci sono altre soluzioni, tra cui GWT, che compila Java in JavaScript e Script #, che compila C # in JavaScript.

Jquery (ancora javascript ma) ti aiuterà davvero a supportare tutti i browser e non è poi così difficile da imparare :)

JavaScript è la lingua inglese del web. L'inglese si diffuse storicamente perché aveva una forte marina che conquistava vari paesi. Questo è paragonabile alle grandi aziende che hanno conquistato il web con JavaScript. È una lingua combinata da più fonti europee (greco, latino, lingue germaniche, francese anche alcune parole cinesi e indiane). JavaScript ha preso in prestito molti concetti nel corso degli anni da altre lingue (strutturale, OO, funzionale). L'inglese è parlato in luoghi diversi con lievi variazioni nel dialetto e nell'accento, il che può rendere difficile la comprensione. Proprio come JavaScript ha browser diversi che lo interpretano in modo leggermente diverso.

Anche se inizialmente l'inglese è facile da imparare, ha una pronuncia molto incoerente e più eccezioni delle regole. Proprio come JavaScript è sempre lì per offrire una sorpresa.

Nonostante i diversi accenti, JavaScript è la lingua franca del web. Proprio come potresti non essere inglese e scrivere qui in inglese, ogni browser web ha un certo grado di comprensione dell'inglese. IE6 è come il ragazzo che dice nel suo curriculum di essere fluente, ma ha frequentato solo un corso di due settimane sull'inglese come lingua straniera.

Ci sono stati tentativi di soppiantare l'inglese come lingua principale del mondo, ad esempio l'esperanto. Ma tutti fallirono, perché la maggior parte della gente sulla terra parla un po 'di inglese. Allo stesso modo sarà difficile introdurre alternative migliori a JavaScript.

Non credo che Javascript verrà sostituito presto. Per un approccio completamente diverso ai rich client, potresti voler esaminare Flex, che è una tecnologia basata su Flash.

Forse qualcosa come haxe (vedi haxe.org) potrebbe aiutarti. È un linguaggio che sembra più pulito di JavaScript e può essere compilato in JavaScript, quindi può essere eseguito all'interno di un browser.

So che questa non è una risposta diretta alla tua domanda, ma ho pensato che potrebbe essere interessante per te, comunque.

Molte persone capiscono che Javascript non è la lingua migliore e più bella di sempre. Tuttavia, è attualmente supportato dai browser e quindi sarà estremamente difficile introdurre una lingua diversa. Semplicemente non abbiamo bisogno di un'altra guerra browser.

Questo spiega perché non conosco piani per passare a un'altra lingua lato client.

Ma penso che Javascript non sia così male se inizi a pensare al modello DOM e al modo in cui uno funzionerebbe con esso. Molte cose che sono confuse con JS sono il risultato del modo in cui funziona il modello DOM.