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

35

Perché oggi esiste solo il supporto per JavaScript e alcuni VBScript nei browser? So che JavaScript è buono e tutto, ma la possibilità di utilizzare un altro linguaggio di programmazione non contribuirebbe a promuovere diversi stili di sviluppo?

web-development javascript browser

— Eric Packwood
fonte

1

Vedi questa domanda su Stack Overflow: stackoverflow.com/questions/2872037/…

— Corey

1

La tua domanda è precisamente perché Google ha creato GWT .

— jhocking del

1

Credo che il punto centrale dell'API DOM fosse fornire supporto per più lingue. Il fatto è che JS è davvero molto adatto alla sfida. Si normalizza come gli affari di nessuno e le funzioni di prima classe sono enormi in un paradigma fortemente guidato dagli eventi. Ciò che realmente è venuto fuori è che nessuno voleva lasciare che MS prendesse quella decisione e nessuno ne ha escogitato una migliore di JS. Inoltre, le applet Java erano davvero, VERAMENTE lame.

— Erik Reppen,

33

Non è necessario aggiungere il supporto per più lingue, una soluzione sarebbe quella di standardizzare un bytecode generico che potrebbe essere utilizzato dagli implementatori del linguaggio. 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. E ci sono già molti esempi di questo.

— nkassis
fonte

3

+1 - Per sottolineare che JavaScript è un linguaggio potente che può essere utilizzato come astrazione per altre lingue. Sarebbe un progetto interessante scrivere un'estensione di Firefox che eseguisse C ++ o Java lato client! <script type="text/cpp" src="test.cpp"></script>.

— jmort253,

2

@ jmort253, dai un'occhiata al client nativo.

— dan_waterworth,

Il client nativo è decisamente interessante ma a meno che Mozilla non lo adotti, non ci sarà alcuna trazione. L'ultima volta che ho controllato non erano ancora pronti per accettarlo.

— nkassis,

1

Ho trovato Gestalt ~ un paio di anni fa: gestalt.codeplex.com è un buon esempio di costruzione di altri linguaggi di scripting su Javascript.

— Jim Schubert,

2

Un altro esempio: Google Web Toolkit ? Java è compilato in JavaScript

— MarkJ

21

JavaScript è lo standard di fatto ed è stato dal 1996. Essere uno standard semplicemente perché non c'è concorrenza non è esattamente giusto, ma non ho sentito molte lamentele sul perché non sia inclusa un'altra lingua.

L'aggiunta di un altro linguaggio "standard" promuove tutti i tipi di piccoli problemi divertenti.

Come lavoreranno con altre lingue?
Il DOM sarà condiviso?
Gli script scritti in entrambi potrebbero funzionare ancora?
Porting di librerie su entrambi

— Josh K
fonte

8

In realtà penso che JavaScript sia il linguaggio usato nel geco di Mozilla. In IE abbiamo JScript. La maggior parte degli altri browser utilizza qualcosa che più o meno segue le specifiche ECMAScript. Tutte queste lingue sono per semplicità chiamate 'JavaScript', mentre in realtà differiscono.

— Mchl

1

Puoi avere più lingue che generano lo stesso bytecode. Guarda JVM - Groovy, Java, Scala, Clojure, jRuby possono essere compilati direttamente in bytecode JVM. In questo modo, condivideranno le stesse API DOM e potranno essere rese interoperabili. Sebbene sia esponenzialmente più difficile da implementare con JavaScript VM poiché viene interpretato.

— David Sergey,

21

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

— Michael Brown
fonte

5

Già, è già lì, lato client VBScript ... uugh, rabbrividisci.

— ocodo

1

+1 Penso che le nostre teste esploderebbero se avessimo un sottoinsieme di altre lingue da memorizzare per ciascuno dei browser principali e le loro versioni. Buona risposta.

— jmort253,

4

Questo potrebbe essere un pignolo, ma il supporto di JavaScript da parte dei browser [ECMAScript] è stato in realtà molto coerente dall'inizio alla fine. Ciò che è stato incoerente è la loro implementazione del DOM (e dei metodi associati). Da un punto di vista pratico (e storico), è difficile separare i due - poiché l'unico vero utilizzo di JS è stato manipolare il DOM in un browser - ma con l'ascesa di JS lato server (cose come NodeJS), questo in realtà diventa una distinzione piuttosto importante.

— josh3736,

stava per scrivere praticamente esattamente questo come una risposta, Internet ha abbastanza standard che non sono seguiti o supportati. il fatto che il pasticcio confuso che abbiamo funziona a metà e lo fa non è affatto un miracolo.

— Ryathal,

1

Josh ha ragione. È qui che ti colleghi all'idea borked del singolo browser su come dovrebbero essere visualizzate le cose e a cui JS accede che le cose sono diventate brutte ma IE sta finalmente assistendo a problemi API proprietari di vecchia data su quel fronte (anche se continua a in ritardo rispetto all'ultimo in quasi tutto ciò a causa della fatidica decisione di MS di collegare il proprio browser al navigatore dei file - jackasses).

— Erik Reppen,

6

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

Se hai più lingue a disposizione, devi assicurarti che funzionino tutte in modo simile. Se sei uno sviluppatore web e hai una scelta di lingue, che possono essere o meno supportate in alcune località, allora questo è un ulteriore mal di testa.

Javascript è un linguaggio molto flessibile, è un imperativo, è funzionale, può essere OOP (dopo una moda con prototipi), ed è interpretato. Ora con motori decenti come quelli di Chrome, è ragionevolmente in grado di fare cose buone. I linguaggi extra riportano semplicemente le cose qui, guardano VBScript, solo IE, e quindi tutto ciò che è scritto in esso è legato a un particolare browser e piattaforma, incubo.

— Orbling
fonte

2

Il punto importante qui è "con motori decenti come in Chrome". Fare qualsiasi cosa anche leggermente faticosa fa sì che anche IE8 inizi a zoppicare come se avesse una gamba rotta, mentre le versioni recenti di Firefox e Chrome da sempre che l'ho usato (questa è la ragione per cui sono passato di fatto) saltano avanti senza perdere un colpo.

— Matthew Scharley,

1

@Matthew Scharley: IE è generalmente lento, anzi sembra peggiorare con ogni versione. Hanno bisogno di migliorare il loro gioco, o saranno fuori di esso. L'unica ragione per cui IE è in sospeso è a causa dell'inclusione del sistema operativo, ora devono mettere un selettore al primo utilizzo, che è calato molto.

— Orbling

"può essere OOP" ... è OOP! L'ereditarietà non è ciò che definisce OOP. Gli oggetti sono.

— KaptajnKold,

@KaptajnKold: Questa è una questione di dibattito nei circoli accademici, sorprendentemente. Sono d'accordo che JS è in grado di OOP, in quanto ha oggetti, ma non sono sempre eccessivamente utilizzati da alcuni. Il sistema prototipo è anche molto diverso dal solito sapore OOP, il che lo rimuove ulteriormente dalla definizione standard di "un linguaggio OOP". Come con la maggior parte delle lingue, dipende da come lo usi: quando lo uso, è OOP.

— Orbling

3

Invece di inserirli nei browser, ai fornitori piace creare plug-in per browser ingombranti: Java, Flash, Silverlight, ecc. Ciò garantisce coerenza multipiattaforma.

— Kirk Broadhurst
fonte

Beh, non si tratta di garantire la coerenza multipiattaforma, quanto di garantire il controllo. Come in te controlli il plugin e non devi rispondere a nessun altro.

— jhocking del

Rispetto alle difficoltà con l'esecuzione di javascript sporco veloce, i plug-in "clunky" sono molto meglio. Mi sentivo negativamente sull'intero download del browser-plugin, ma è sicuramente più aperto di "javascript implementato universalmente".

— Milind R

2

Uno dei motivi è che è praticamente impossibile per i diversi fornitori di browser anche concordare 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 pensa giustamente che ottenere un altro linguaggio lato client nell'ecosistema e convincere tutti i fornitori a sostenerlo sia praticamente impossibile e la maggior parte delle persone che potrebbero potenzialmente farlo accadere sono già coinvolte in problemi di standardizzazione Javascript che penso sia molto meglio uso del loro tempo.

— DavidK01
fonte

Praticamente quello che stavo per dire. L'importante (in questa discussione) differenza tra le lingue lato client e lato server è che i browser devono implementare il linguaggio lato client.

— jhocking del

2

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

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 scripting debba essere consegnato sotto forma di file JAR compilati e firmati o come codice sorgente JavaScript. Se il browser rileva JavaScript, potrebbe eseguirlo tramite un interprete dedicato (come avviene oggi) o tramite Rhino in cima alla JVM. Se incontra file jar, crea un nuovo caricatore di classi e sandbox di sicurezza, carica il bytecode java in memoria ed esegue. Ciò sarebbe completamente compatibile con le pagine Web esistenti e consentirebbe al browser, con un solo colpo, di supportare dozzine di lingue in esecuzione sulla JVM.

Altri vantaggi:

La JVM ha beneficiato di un decennio di miglioramenti delle prestazioni. Ora è molto veloce, stabile e maturo. Scommetto che vedresti un grande miglioramento delle prestazioni rispetto al javascript interpretato.
Man mano che le app lato client diventano più grandi e complesse, i vantaggi di linguaggi strutturati e tipizzati come Java e Scala aumentano.
Avresti accesso al vero multi-threading e tramite Scala, una libreria di raccolte ottimizzata per il calcolo multi-core.
È possibile utilizzare una qualsiasi delle migliaia di librerie Java open source all'interno del browser.
Attraverso librerie come openGL, il browser potrebbe fornire accesso a funzionalità avanzate di elaborazione di grafica e schede grafiche.
Se avessi java in esecuzione sul lato client e server, potresti trarre ulteriore vantaggio dalle comunicazioni client-server tramite serializzazione binaria e ad oggetti binari estremamente compressa = caricamento e esecuzione di pagine Web più veloci.

— Patrick Arnesen
fonte

1

Puoi già eseguire il codice JVM. Si chiama applet java

— Raynos il

1

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

POW Web Server SJS - JavaScript lato server per POW Web Server, che viene eseguito come estensione di Firefox o come applicazione XULRunner. SJS svolge un ruolo simile a quello di PHP in Apache in quanto può connettersi a database e generare contenuti sul 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 sole 6 righe!
Jaxer : un server JavaScript che interpreta tutti i blocchi di script con runat="server"JavaScript lato server. Intere applicazioni Web possono essere scritte in JavaScript.
Rhino - JavaScript per Java - Mozilla ha creato questa implementazione JavaScript lato server che gira su Java. È essenzialmente un concetto simile a Querces PHP per Java , Jython, JRuby e molte altre astrazioni di altri linguaggi che girano su 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 aziendale in un'altra lingua!
JQuery Claypool - Framework JavaScript lato server che utilizza la potenza di JQuery sul server. Molto bello! È stato sviluppato utilizzando l'implementazione JavaScript lato server di EnvJs di un browser.
EnvJs - Un browser senza testa costruito su Rhino.

Ciò che molte 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 vedremo evolversi.

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

— jmort253
fonte

+1 per indicare che JavaScript non è limitato al browser

— Gary Rowe,

1

Esistono diversi esempi di strumenti che compileranno altre lingue 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 dell'università abbia scritto un'implementazione dello schema in Javascript. Quindi se ti piace lo schema puoi farlo anche tu.

— Zachary K
fonte

0

Le persone hanno aggirato la mancanza di varietà integrata in due modi: usando plugin come applet flash o java e costruendo livelli che usano javascript come loro "codice macchina", come jquery o google web toolkit. Se ci fosse un nuovo stile di sviluppo abbastanza popolare, le persone troverebbero un modo per ottenerlo.

Basta essere consapevoli se si esegue un runtime .net in javascript e diventa sempre popolare, alcuni circoli malediranno il tuo nome su Internet per sempre.

— Karl Bielefeldt
fonte

Incolpare i moduli web e IE. Faresti pisciare di meno sugli sviluppatori dell'interfaccia utente web colpendoli con hot poker. Non va bene per l'associazione di marca.

— Erik Reppen,