Potrò mai codificare il codice del browser lato client in una lingua a mia scelta? [chiuso]

Per rispondere alla tua domanda, sì, ci sono degli sforzi per deprecare Javascript in favore di un linguaggio più coeso per lo scripting web. Google ha dato molta spinta alla loro lingua Dart . Dart ha la sua VM che è già incorporata in Chrome, ma non sono sicuro che gli altri browser lo abbiano già adottato. Esiste anche un linguaggio abbastanza promettente chiamato CoffeeScript .

C'è anche un progetto molto ambizioso chiamato HaXe che mira a unificare tutta una serie di piattaforme di sviluppo con una sola lingua ..

Credimi che non sei il solo a non gradire Javascript, ma temo che non andrà da nessuna parte presto - infatti sembra che stia guadagnando molto slancio con le app HTML5 / JS di Windows 8 ecc. ma alternative come quelli che ho menzionato stanno iniziando a spuntare:)

Javascript può essere visto come una lingua intermedia, definendo una macchina virtuale in cui possono essere compilate altre lingue. In progetti come GWT questa nozione sta già decollando. Potrebbe non essere ciò che avresti progettato da zero, ma sta già diventando una realtà che potresti compilare "la tua lingua preferita" in Javascript.

In sostanza, no. Sei praticamente bloccato con Javascript.

Detto questo, ci sono stati degli sforzi in passato per portare altre lingue a bordo (applet java, vbscript, ecc.). Ognuno di questi non ha mai veramente guadagnato la trazione di javascript perché javascript è integrato .

L'unico modo per creare ciò a cui ti riferisci sarebbe creare un linguaggio di scripting che gira su una macchina virtuale, compilato lato client, e poi eseguito. Quindi ciascun browser dovrebbe implementare la macchina virtuale nella propria base di codice in modo che tutto il codice venga eseguito su tutti i browser. Quindi dovresti assicurarti di avere una sorta di standard in modo che tutti i browser eseguano i comandi allo stesso modo. Naturalmente, essendo i browser creati in modo indipendente, ci sarebbero probabilmente stranezze che gli sviluppatori dovrebbero tenere a mente.

Ma ora abbiamo appena descritto Javascript.

Quindi, alla fine, le tue scelte sono:

1. abituarsi a Javascript
2. prova ad usare un linguaggio che si compila in Javascript. (Ricorda che vuoi comunque verificare il Javascript, che rimanda all'opzione 1.)
3. usa un linguaggio che esiste come plug-in nel browser, come actionscript (Flash), ActiveX, applet java, .Net (SilverLight). Ciò evita il problema con più fornitori / implementazioni del linguaggio, ma non integra la lingua.

In sostanza, se vuoi una lingua integrata, sei bloccato con Javascript.

In realtà non stai odiando javascript, come descritto negli standard Ecma, ma stai odiando l'orribile implementazione su vari browser , con stranezze, bug e wtfs. Javascript sul lato server è piuttosto divertente in realtà. Anche il modello DOM è la causa dell'80% del dolore del javascript lato client.

Se desideri ancora utilizzare un'altra lingua, puoi utilizzare GWT , che in pratica ti consente di scrivere Java , quindi compilarlo in (brutto) javascript o CoffeeScript , che è uno zucchero sintattico su JS, che compila in JS .

Questa domanda si apre di tanto in tanto.

Perché non abbiamo altri linguaggi nei tag script invece di solo Javascript

Indietro nel giorno IE ha introdotto VB come alternativa a Javascript. Penso che tu possa già vedere come questo porterebbe a un inferno standard se fosse preso ...

Allora perché non una lingua intermedia standard comune allora?

C'è un vecchio podcast di Brendan Eich che spiega perché nel prossimo futuro non vedrà una lingua bytecode intermedia:

link

link

Il problema di base è che mentre il linguaggio intermedio (come CIL e i bytecode JVM) cerca di essere generico, la maggior parte delle volte si rivelano troppo bassi e troppo legati ai linguaggi di alto livello originali compilati per loro. Ad esempio, non è possibile implementare realmente funzioni ricorsive in coda nella JVM: quali altre funzionalità linguistiche o scelte di implementazione non saremo in grado di implementare se abbiniamo a un'astrazione bytecode di basso livello troppo presto?

Nel frattempo, Javascript è un linguaggio flessibile di alto livello con semantica risolta e implementazioni multiple, differenti ed efficienti. Quello che potremmo vedere in futuro è Javascript stesso come linguaggio intermedio - Sfortunatamente questo è un po 'immaturo e poche lingue vengono compilate da JS a partire da oggi.

Sì. Puoi già compilare Dart, Coffeescript e Java in Javascript. Hai Emscripten, che è un backend del compilatore per LLVM per generare un bytecode Javascript (e LLVM gestisce un bel po 'di lingue, credo).

Ma diverso dalla compilazione in JS, non in un breve periodo di tempo. IE6 ha 10 anni e continua a dare calci. Spero che i browser attuali (che non supportano altre lingue) non sopravviveranno così a lungo, ma saranno in giro per alcuni anni, provocando il ciclo di coda di "dobbiamo ancora supportare i browser che supportano solo Javascript, quindi dobbiamo usare Javascript ", in un modo molto più difficile di dire CSS3- il tuo sito potrebbe funzionare senza CSS3, ma prova a farlo funzionare senza scripting lato client.

Potresti essere solo fortunato. Questo è il paragrafo di apertura di una submission sul forum webkit-dev:

Many languages compile to JavaScript today to run on the web. As alternative, we’ve been experimenting with enabling different language runtimes in WebKit to run in web pages alongside JavaScript...

Puoi visualizzare il resto del messaggio qui .

JavaScript è l'anima dei browser, ecco perché la maggior parte dei nuovi tentativi sta generando JavaScript (CoffeeScript è un chiaro esempio).
In GWT, si codifica la logica lato client nel linguaggio di programmazione Java e il toolkit genera JavaScript.

ClojureScript è un progetto interessante se sei in codice Lisp.

Quindi sembra non importa cosa, JavaScript è qui per rimanere. (COBOL del web forse?).

"Any customer can have a car painted any colour that he wants so long as it is black." -- Henry Ford

Ci sono già un certo numero di compilatori che hanno come target javascript, e puoi scegliere qualsiasi lingua che compili su javascript.

Il tuo link che discute il valore delle lingue intermedie li discute nel contesto dell'implementazione di una suite di compilatori, non nel fornire il codice che verrà spedito attraverso una rete ed eseguito su un computer client. Javascript potrebbe non essere il formato migliore per questo, ma qualunque cosa sia, non assomiglierà molto ai bytecode CIL o java.

Se odi javascript, ti suggerisco di trasferirti nello spazio di sviluppo Embedded, Scientific o di gioco, dove C, Fortran e C ++ controllano il posatoio. La linea di app aziendali si sta spostando molto sul Web e ciò significa più Javascript, non meno.