Warum gibt es keine anderen clientseitigen Skriptsprachen für Websites? [geschlossen]

35

Warum werden heutzutage nur JavaScript und VBScript in Browsern unterstützt? Ich weiß, dass JavaScript gut ist, aber würde die Option, eine andere Programmiersprache zu verwenden, nicht dazu beitragen, unterschiedliche Entwicklungsstile zu fördern?

web-development javascript browser

— Eric Packwood
quelle

1

Siehe diese Frage auf Stack Overflow: stackoverflow.com/questions/2872037/…

— Corey

1

Ihre Frage ist genau, warum Google GWT gemacht hat .

— jhocking

1

Ich glaube, der springende Punkt der DOM-API war die Unterstützung mehrerer Sprachen. Eigentlich ist JS wirklich gut für die Herausforderung geeignet. Es normalisiert sich, als wäre niemand geschäftlich tätig, und erstklassige Funktionen sind in einem stark ereignisgesteuerten Paradigma enorm. Worauf es wirklich ankam, war, dass niemand MS diese Entscheidung überlassen wollte und niemand eine bessere als JS fand. Außerdem waren Java-Applets wirklich WIRKLICH lahm.

— Erik Reppen

33

Es ist nicht erforderlich, Unterstützung für mehrere Sprachen hinzuzufügen. Eine Lösung wäre, einen generischen Bytecode zu standardisieren, der von Sprachimplementierern verwendet werden könnte. Aber es gibt derzeit keine Pläne dafür (es wurde vorgeschlagen).

Sprachen können auch über Javascript implementiert werden. Javascript ist gut genug, um andere Sprachen darüber zu implementieren. Und dafür gibt es bereits viele Beispiele.

— nkassis
quelle

3

+1 - Um darauf hinzuweisen, dass JavaScript eine leistungsstarke Sprache ist, die als Abstraktion für andere Sprachen verwendet werden kann. Es wäre ein interessantes Projekt, eine Firefox-Erweiterung zu schreiben, die clientseitig C ++ oder Java ausführt! <script type="text/cpp" src="test.cpp"></script>.

— jmort253

2

@ jmort253, werfen Sie einen Blick auf den nativen Client.

— Dan_waterworth

Einheimischer Client ist definitiv interessant, aber wenn Mozilla ihn nicht auch annimmt, wird es keine Traktion geben. Zuletzt überprüfte ich, dass sie noch nicht bereit waren, es anzunehmen.

— nkassis

1

Ich habe Gestalt ~ vor ein paar Jahren gefunden: gestalt.codeplex.com es ist ein gutes Beispiel dafür, wie man andere Skriptsprachen auf Javascript aufbaut .

— Jim Schubert

2

Ein weiteres Beispiel: Google Web Toolkit ? Java ist in JavaScript kompiliert

— MarkJ

21

JavaScript ist der De-facto- Standard und seit 1996. Ein Standard zu sein, nur weil es keine Konkurrenz gibt, ist nicht gerade fair, aber ich habe nicht viel darüber geklagt, warum keine andere Sprache enthalten ist.

Das Hinzufügen einer weiteren "Standardsprache" fördert alle Arten von lustigen kleinen Problemen.

Wie werden sie mit anderen Sprachen arbeiten?
Wird das DOM geteilt?
Konnten in beiden geschriebene Skripte noch funktionieren?
Bibliotheken auf beide portieren

— Josh K
quelle

8

Eigentlich denke ich, dass JavaScript die Sprache ist, die in Mozillas Gecko verwendet wird. Im IE haben wir JScript. Die meisten anderen Browser verwenden etwas, das mehr oder weniger den ECMAScript-Spezifikationen entspricht. Diese Sprachen werden der Einfachheit halber "JavaScript" genannt, obwohl sie sich tatsächlich unterscheiden.

— Mchl

1

Sie können mehrere Sprachen haben, die denselben Bytecode generieren. Schauen Sie sich JVM an - Groovy, Java, Scala, Clojure und jRuby können direkt zu JVM-Bytecode kompiliert werden. Auf diese Weise teilen sie sich dieselbe DOM-API und können interoperabel gemacht werden. Obwohl es exponentiell schwieriger ist, mit JavaScript VM zu implementieren, da es interpretiert wird.

— David Sergey

21

Denken Sie an die Inkonsistenzen zwischen den Browsern, die nur Javascript unterstützen. Nun überlegen Sie, wie es wäre, wenn es mehr Sprachen gäbe.

— Michael Brown
quelle

5

Yay, es ist schon da, clientseitiges VBScript ... uugh, schaudert.

— ocodo

1

+1 Ich denke, unsere Köpfe würden explodieren, wenn wir uns für jeden der Hauptbrowser und ihre Versionen eine Untergruppe anderer Sprachen merken könnten. Gute Antwort.

— jmort253

4

Das mag zwar nicht zielführend sein, aber ... Die Unterstützung von JavaScript [ECMAScript] durch Browser war von Anfang an durchweg sehr konsistent. Was inkonsistent war, ist die Implementierung des DOM (und der zugehörigen Methoden). Vom praktischen (und historischen) Standpunkt aus ist es schwierig, die beiden zu trennen - da der einzige wirkliche Nutzen von JS darin bestand, das DOM in einem Browser zu manipulieren -, aber mit dem Aufkommen von serverseitigem JS (Dinge wie NodeJS), Dies wird tatsächlich zu einer ziemlich wichtigen Unterscheidung.

— Josh3736

Genau das würde ich als Antwort schreiben, das Internet hat genug Standards, die nicht befolgt oder unterstützt werden. Die Tatsache, dass das Durcheinander, das wir haben, halb so gut funktioniert wie das, ist geradezu ein Wunder.

— Ryathal

1

Josh hat recht. Hier steckt man in der gespaltenen Vorstellung des einzelnen Browsers, wie Dinge gerendert werden und von JS darauf zugegriffen werden sollen, dass das Zeug hässlich wurde, aber der IE kümmert sich schließlich zumindest um langjährige proprietäre API-Probleme in dieser Hinsicht (auch wenn dies weiterhin der Fall ist in nahezu allen Bereichen hinter den neuesten zurückbleiben, da MS sich schicksalhaft entschlossen hat, ihren Browser mit ihrem Datei-Navigator zu verknüpfen (Jackasses).

— Erik Reppen

6

Browser müssen standardisiert sein, damit das, was Sie entwickeln, auf allen Browsern überall funktioniert.

Wenn Sie mehrere Sprachen haben, müssen Sie sicherstellen, dass sie alle sehr ähnlich funktionieren. Wenn Sie ein Webentwickler sind und eine Auswahl an Sprachen haben, die an einigen Standorten unterstützt werden oder nicht, dann ist dies ein zusätzlicher Kopfschmerz.

Javascript ist eine sehr flexible Sprache, es ist unerlässlich, es ist funktional, es kann OOP sein (nach einer Mode mit Prototypen) und es wird interpretiert. Jetzt mit anständigen Motoren wie in Chrome ist es einigermaßen in der Lage, einige gute Sachen zu machen. Zusätzliche Sprachen würden nur die Dinge hier zurückstellen, nur VBScript, IE, und alles, was darin geschrieben ist, ist an einen bestimmten Browser und eine bestimmte Plattform gebunden, Albtraum.

— Orbling
quelle

2

Der wichtige Punkt dabei ist "mit anständigen Motoren wie in Chrome". Wenn Sie etwas tun, das Sie auch nur ein bisschen belasten, humpelt sogar der IE8, als wäre ihm ein Bein gebrochen, während die neuesten Versionen von Firefox und Chrome, die ich seit jeher verwende (aus diesem Grund habe ich infact gewechselt), ohne einen Takt auslassen.

— Matthew Scharley

1

@ Matthew Scharley: IE ist im Allgemeinen träge, in der Tat scheint es mit jeder Version schlimmer zu werden. Sie müssen ihr Spiel verbessern, sonst haben sie es nicht mehr. Der einzige Grund, warum IE irgendeinen Halt hat, ist die Einbeziehung des Betriebssystems. Jetzt müssen sie beim ersten Gebrauch einen Selektor aufsetzen, der viel gesunken ist.

— Orbling

"Es kann OOP sein" ... Es ist OOP! Vererbung ist nicht das, was OOP definiert. Objekte sind.

— KaptajnKold

@KaptajnKold: Das ist überraschenderweise eine Frage von Debatten in akademischen Kreisen. Ich stimme zu, dass JS OOP-fähig ist, da es Objekte enthält, die jedoch von einigen nicht immer übermäßig verwendet werden. Das Prototypsystem unterscheidet sich auch erheblich vom üblichen OOP-Geschmack, was es weiter von der Standarddefinition einer "OOP-Sprache" entfernt. Wie bei den meisten Sprachen hängt es davon ab, wie Sie es verwenden - wenn ich es verwende, ist es OOP.

— Orbling

3

Anstatt diese in Browser zu integrieren, bauen die Hersteller gerne schwerfällige Browser-Plug-Ins (Java, Flash, Silverlight usw.). Dies garantiert plattformübergreifende Konsistenz.

— Kirk Broadhurst
quelle

Nun, es geht nicht darum, die Konsistenz zwischen Plattformen zu gewährleisten, sondern vielmehr darum, die Kontrolle zu gewährleisten. Wie bei dir steuerst du das Plugin und musst niemand anderem antworten.

— jhocking

Verglichen mit der schnellen Ausführung von schmutzigem Javascript sind "klobige" Plug-Ins weitaus besser. Früher habe ich mich negativ über das gesamte Download-Ding des Browser-Plugins gefühlt, aber es ist definitiv offener als "universell implementiertes Javascript".

— Milind R

2

Einer der Gründe ist, dass es für verschiedene Browser-Anbieter praktisch unmöglich ist, sich überhaupt auf eine Standard-Javascript-Implementierung zu einigen, und dass Javascript zumindest aus Sicht der Web-Sprache schon immer existiert. Die meisten Leute denken zu Recht, dass es praktisch unmöglich ist, eine andere clientseitige Sprache in das Ökosystem einzubinden und alle Anbieter dazu zu bringen, sie zu unterstützen, und die meisten Leute, die dies möglicherweise zustande bringen könnten, sind bereits in JavaScript-Standardisierungsprobleme verwickelt, die ich für viel besser halte Nutzung ihrer Zeit.

— davidk01
quelle

So ziemlich das, was ich sagen wollte. Der wichtige (in dieser Diskussion) Unterschied zwischen clientseitigen und serverseitigen Sprachen besteht darin, dass Browser die clientseitige Sprache implementieren müssen.

— jhocking

2

Es gibt mehrere Antworten, die behaupten, dass die Unterstützung mehrerer Sprachen es für Hersteller von Webbrowsern sehr unangenehm machen würde, sicherzustellen, dass sie mit allen Sprachen kompatibel sind. Das scheint mir falsch.

Java zum Beispiel ist ein sehr gut definierter Standard. Im Wesentlichen müssen Sie nur das Browser-DOM als Java-API verfügbar machen und die Java Virtual Machine (JVM) in Ihrem Webbrowser ausführen. Sie können festlegen, dass der Skriptcode entweder in Form von kompilierten und signierten JAR-Dateien oder als JavaScript-Quellcode bereitgestellt werden muss. Wenn der Browser auf JavaScript stößt, kann er entweder über einen dedizierten Interpreter (wie heute) oder über Rhino über die JVM ausgeführt werden. Wenn es auf JAR-Dateien stößt, erstellt es ein neues Klassenladeprogramm und eine neue Sicherheits-Sandbox, lädt den Java-Bytecode in den Speicher und führt ihn aus. Dies wäre vollständig abwärtskompatibel mit vorhandenen Webseiten und würde es dem Browser ermöglichen, mit einem einzigen Strich die Dutzende von Sprachen zu unterstützen, die auf der JVM ausgeführt werden.

Andere Vorteile:

Die JVM profitierte von einem Jahrzehnt der Leistungsverbesserungen. Es ist jetzt sehr schnell, stabil und ausgereift. Ich wette, Sie werden eine große Leistungsverbesserung gegenüber interpretiertem Javascript feststellen.
Da clientseitige Apps immer umfangreicher und komplexer werden, steigen die Vorteile strukturierter typisierter Sprachen wie Java und Scala.
Sie hätten Zugriff auf echtes Multi-Threading und über Scala eine für Multi-Core-Computing optimierte Sammlungsbibliothek.
Sie können jede der Tausenden von Open-Source-Java-Bibliotheken im Browser verwenden.
Über Bibliotheken wie openGL kann der Browser auf erweiterte Grafik- und Grafikkarten-Computing-Funktionen zugreifen.
Wenn Sie Java auf Client- und Serverseite ausgeführt hätten, könnten Sie weiterhin von der Client-Server-Kommunikation über eine extrem komprimierte binäre Objekt-Grafik-Serialisierung profitieren, die das Laden und Ausführen von Webseiten beschleunigt.

— Patrick Arnesen
quelle

1

Sie können JVM-Code bereits ausführen. Es heißt ein Java-Applet

— Raynos

1

Ich glaube, JavaScript wird als Standardsprache für das Web noch mehr an Bedeutung gewinnen. Wir sehen einen Anstieg des serverseitigen JavaScript. Hier einige Beispiele für Implementierungen dieser leistungsstarken Sprache auf dem Server:

POW Web Server SJS - Serverseitiges JavaScript für den POW Web Server, der als Firefox-Erweiterung oder als XULRunner-Anwendung ausgeführt wird. SJS spielt eine ähnliche Rolle wie PHP in Apache, da es eine Verbindung zu Datenbanken herstellen und clientseitigen Inhalt generieren kann.
NodeJS - Serverseitiges JavaScript, das ein ereignisbasiertes Modell verwendet. Es wurde mit Googles V8 JavaScript Engine erstellt . NodeJS wird als Tool zum Erstellen skalierbarer Netzwerkprogramme beworben. Ein "Hello World" Webserver kann in nur 6 kurzen Zeilen geschrieben werden!
Jaxer - Ein JavaScript-Server, der alle Skriptblöckerunat="server" als serverseitiges JavaScript interpretiert . Ganze Webanwendungen können in JavaScript geschrieben werden.
Rhino - JavaScript für Java - Mozilla hat diese serverseitige JavaScript-Implementierung erstellt, die auf Java ausgeführt wird. Es ist im Wesentlichen ein ähnliches Konzept wie Querces PHP für Java , Jython, JRuby und viele andere Abstraktionen anderer Sprachen, die auf der JVM ausgeführt werden. Rhino wird normalerweise zum Einbetten von JavaScript in Java verwendet, um Endbenutzern Skript-Tools zur Verfügung zu stellen. Es kann jedoch auch verwendet werden, um clientseitigen Code auf den Server zu verschieben, ohne die Geschäftslogik in einer anderen Sprache neu schreiben zu müssen!
JQuery Claypool - Serverseitiges JavaScript-Framework, das die Leistung von JQuery auf dem Server nutzt. Sehr cool! Es wurde mit der serverseitigen JavaScript-Implementierung eines Browsers von EnvJ entwickelt.
EnvJs - Ein Browser ohne Kopf, der auf Rhino aufbaut .

Viele dieser Implementierungen und Frameworks zeigen, dass JavaScript zu einer so starken Kraft in der Webentwicklung wird, dass die Verantwortlichen der Community bereits damit begonnen haben, JavaScript auf den Server zu verschieben. JavaScript ist eine äußerst leistungsfähige funktionale Programmiersprache, und im Laufe der Zeit werden wir feststellen, dass sie sich weiterentwickelt.

Zusammenfassend scheint es ein Widerspruch zu sein, die anderen Sprachen auf den Browser zu portieren, wenn wir stattdessen diese einzelne Browsersprache auf den Server portieren und diese Lücke auf einheitlichere Weise schließen können.

— jmort253
quelle

+1 für den Hinweis, dass JavaScript nicht auf den Browser beschränkt ist

— Gary Rowe

1

Es gibt verschiedene Beispiele für Tools, die andere Sprachen für Javascript kompilieren, darunter Haskel, Lisp und Python (wahrscheinlich auch andere). Wenn Sie also in einer dieser Sprachen arbeiten möchten, können Sie dies tun.

Und ich denke, einer meiner Professoren von der Universität hat eine Schema-Implementierung in Javascript geschrieben. Also, wenn Sie Schema mögen, können Sie das auch tun.

— Zachary K
quelle

0

Die Leute haben den Mangel an eingebauter Vielfalt auf zwei Arten umgangen: durch die Verwendung von Plugins wie Flash oder Java-Applets und durch das Erstellen von Layern, die JavaScript als "Maschinencode" verwenden, wie jquery oder google web toolkit. Wenn es einen neuen Entwicklungsstil gäbe, der populär genug wäre, würden die Leute einen Weg finden, dies zu erreichen.

Beachten Sie jedoch, dass bestimmte Kreise Ihren Namen im Internet für immer verfluchen, wenn Sie eine .net-Laufzeit in Javascript erstellen und diese jemals populär wird.

— Karl Bielefeldt
quelle

Schuld Webforms und IE. Sie würden weniger Web-UI-Entwickler verärgern, wenn Sie sie mit heißen Pokerspielern anstoßen würden. Nicht gut für die Markenassoziation.

— Erik Reppen