Perché non ci sono altri linguaggi di scripting lato client per i siti Web? [chiuso]

Non è necessario aggiungere suport per più lingue, una soluzione sarebbe quella di standardizzare su un bytecode generico che potrebbe essere utilizzato dagli implementatori linguistici. Ma al momento non ci sono piani per questo (è stato suggerito).

Le lingue possono essere implementate anche su Javascript. Javascript è abbastanza buono da consentire l'implementazione di altre lingue su di esso. E ci sono molti esempi di questo già.

JavaScript è lo standard de facto ed è stato dal 1996. Essere uno standard semplicemente perché non c'è competizione non è esattamente giusto, ma non ho sentito molte lamentele < em> perché non è inclusa un'altra lingua.

L'aggiunta di un altro linguaggio "standard" promuove ogni sorta di piccoli problemi divertenti.

• Come lavoreranno con altre lingue?
• Il DOM sarà condiviso?
• Gli script scritti in entrambi funzionano ancora?
• Porting di librerie per entrambi

Pensa alle incoerenze tra i browser per il loro supporto di javascript da solo. Ora pensa a come sarebbe se ci fossero più lingue.

I browser devono essere standardizzati, in modo che ciò che sviluppi funzioni ovunque, su tutti i browser.

Se hai a che fare con più lingue, devi assicurarti che si comportino in modo molto simile. Se sei uno sviluppatore web e hai una scelta di lingue, che possono o non possono essere supportate in alcune località, allora si tratta di un ulteriore mal di testa.

Javascript è un linguaggio flessibile molto , è imperativo, è funzionale, può essere OOP (dopo una moda con i prototipi) ed è interpretato. Ora con i motori decenti come in Chrome, è ragionevolmente capace di fare alcune cose buone. Le lingue extra riporterebbero le cose solo qui, guardate solo VBScript, IE, e quindi tutto ciò che è scritto in esso è legato a un particolare browser e piattaforma, un incubo.

Invece di costruirle nei browser, i venditori amano costruire goffi plug-in del browser - Java, Flash, Silverlight, ecc. Ciò garantisce la coerenza multipiattaforma.

Una delle ragioni è che è praticamente impossibile per i vari fornitori di browser concordare su un'implementazione standard di Javascript e Javascript è in circolazione da sempre, almeno dal punto di vista del linguaggio web. Quindi la maggior parte delle persone giustamente pensa che l'acquisizione di un altro linguaggio lato client nell'ecosistema e l'impossibilità di tutti i fornitori di supportarlo sia praticamente impossibile e la maggior parte delle persone che potrebbero potenzialmente farlo accadere sono già coinvolte nei problemi di standardizzazione di Javascript che ritengo sia molto meglio uso del loro tempo.

Ci sono diverse risposte qui che sostengono che il supporto di più lingue renderebbe molto odioso per i costruttori di browser Web per assicurarsi che siano compatibili con tutte le lingue. Per me questo sembra scorretto.

Java, ad esempio, è uno standard estremamente ben definito. In sostanza, tutto ciò che devi fare è esporre il DOM del browser come API Java ed eseguire Java Virtual Machine (JVM) all'interno del tuo browser web. È possibile specificare che il codice di script debba essere consegnato sotto forma di file JAR compilati e firmati o come codice sorgente JavaScript. Se il browser rileva JavaScript, può eseguirlo tramite un interprete dedicato (come fa oggi) oppure tramite Rhino in cima della JVM. Se incontra i file jar, crea un nuovo caricatore di classi e una sandbox di sicurezza, carica il bytecode java in memoria e lo esegue. Ciò sarebbe completamente retrocompatibile con le pagine Web esistenti e consentirebbe al browser, con un singolo colpo, di supportare le dozzine di lingue che girano sulla JVM.

Altri vantaggi:

1. La JVM ha beneficiato di un decennio di miglioramenti delle prestazioni. Ora è molto veloce, stabile e maturo. Scommetto che vedresti un notevole miglioramento delle prestazioni rispetto al javascript interpretato.
2. Man mano che le app lato client diventano più grandi e complesse, aumentano i vantaggi di linguaggi strutturati e tipizzati come Java e Scala.
3. Avresti accesso al vero multi-threading e tramite Scala, una raccolta di librerie ottimizzata per l'elaborazione multi-core.
4. Potresti usare una qualsiasi delle migliaia di librerie java open source all'interno del browser.
5. Attraverso librerie come openGL, il browser potrebbe fornire accesso a funzionalità avanzate di grafica e scheda grafica.
6. Se avessi Java in esecuzione sul lato client e server, potresti trarre ulteriore vantaggio dalle comunicazioni client-server tramite serializzazione di grafici ad oggetti binari estremamente compressi = caricamento più veloce ed esecuzione di pagine web.

Credo che JavaScript guadagnerà ancora più terreno come linguaggio standard per il Web. Stiamo assistendo a un aumento del JavaScript sul lato server. Ecco alcuni esempi di implementazioni di questo potente linguaggio sul server:

• POW Web Server SJS - JavaScript lato server per il server Web POW, che funziona come estensione per Firefox o come un'applicazione XULRunner. SJS ha un ruolo simile a quello di PHP in Apache in quanto può connettersi ai database e generare contenuti lato client.

• NodeJS - JavaScript lato server che utilizza un modello basato su eventi. È costruito utilizzando il Motore JavaScript V8 di Google . NodeJS è pubblicizzato come uno strumento per la creazione di programmi di rete scalabili. Un server Web "Hello World" può essere scritto in solo 6 linee brevi!

• Jaxer - Un server JavaScript che interpreta tutti i blocchi di script con runat="server" come JavaScript lato server. Intere applicazioni Web possono essere scritte in JavaScript.

• Rhino - JavaScript per Java - Mozilla ha creato questa implementazione JavaScript sul lato server che viene eseguita su Java. È essenzialmente un concetto simile a Querces PHP per Java , Jython, JRuby e molte altre astrazioni di altre lingue che eseguire sulla JVM. Rhino viene in genere utilizzato per incorporare JavaScript in Java per fornire strumenti di scripting agli utenti finali, ma potrebbe anche essere utilizzato per spostare il codice lato client sul server senza dover riscrivere la logica di business in un'altra lingua!

• JQuery Claypool - Struttura JavaScript lato server che sfrutta la potenza di JQuery sul server. Molto bello! È stato sviluppato utilizzando l'implementazione JavaScript di EnvJs sul lato server di un browser.

• EnvJs - Un browser senza testa costruito su Rhino.

Quante di queste implementazioni e framework dimostrano che JavaScript sta diventando una forza così potente nello sviluppo Web che i leader della comunità hanno già iniziato a spostare JavaScript sul server. JavaScript è un linguaggio di programmazione funzionale estremamente potente, e col passare del tempo sento che lo vedremo evolvere.

In sintesi, sembra una contraddizione portare le altre lingue al browser quando invece possiamo portare questa singola lingua del browser al server e colmare il divario in un modo più unificato.

Ci sono diversi esempi di strumenti che compileranno altri linguaggi in javascript, tra cui Haskel, Lisp e Python (Probabilmente altri). Quindi se vuoi lavorare in una di quelle lingue puoi farlo.

E penso che uno dei miei professori universitari abbia scritto un'implementazione di schema in Javascript. Quindi se ti piace lo schema puoi farlo anche tu.

Le persone hanno lavorato attorno alla mancanza della varietà integrata in due modi: usando plugin come le app flash o java e costruendo layer che usano javascript come "codice macchina", come jquery o google web toolkit. Se esistesse un nuovo stile di sviluppo abbastanza popolare, le persone troverebbero un modo per farlo entrare.

Tieni presente che se esegui un runtime .net in javascript e diventi sempre popolare, certe cerchie maledicono il tuo nome su Internet per sempre.