Alternativen zu JavaScript

Question

Zurzeit ist JavaScript die einzige vollständig unterstützte Sprache und der De-facto-Standard für die Manipulation des DOM-Baums im Browser. Es sieht so aus, als ob es tiefgreifende Designprobleme hat, die es zu einem Minenfeld von Bugs und Sicherheitslücken für den Anfänger machen.

Kennen Sie eine bestehende oder geplante Initiative zur Einführung einer besseren (neu gestalteten) Sprache jeglicher Art (nicht nur Javascript) für die Manipulation von DOM-Bäumen und HTTP-Anfragen in Browsern der nächsten Generation? Wenn ja, wie sieht der Fahrplan für ihre Integration in, sagen wir, Firefox aus, und wenn nein, aus welchen Gründen (abgesehen von der Interoperabilität) sollte JavaScript die einzige unterstützte Sprache auf der Browser-Plattform sein?

Ich habe bereits jQuery verwendet und habe auch "javascript: the good parts" gelesen. Die Vorschläge sind in der Tat gut, aber was ich nicht verstehen kann, ist: warum nur javascript? Auf der Serverseite (Ihrer bevorzugten OS-Plattform) können wir einen DOM-Baum mit jeder Sprache manipulieren, sogar mit Fortran. Warum wird auf der Client-Seite (der Browser-Plattform) nur Javascript unterstützt?

Answer 1

Das Problem mit Javascript ist nicht die Sprache selbst - es ist eine sehr gute, prototypische und dynamische Sprache. Wenn Sie von einem OO-Hintergrund kommen, gibt es ein bisschen von einer Lernkurve, aber es ist nicht die Sprache die Schuld.

Die meisten Leute nehmen an, dass Javascript wie Java ist, weil es eine ähnliche Syntax und einen ähnlichen Namen hat, aber eigentlich ist es viel mehr wie Lisp. Es ist eigentlich ziemlich gut für die DOM-Manipulation geeignet.

Das eigentliche Problem besteht darin, dass es vom Browser kompiliert wird, und das bedeutet, dass es je nach Client auf sehr unterschiedliche Weise funktioniert.

Nicht nur das eigentliche DOM ist je nach Browser unterschiedlich, sondern auch die Leistung und das Layout unterscheiden sich erheblich.

---

Bearbeiten nach Klarstellung in der Frage

Angenommen, mehrere interpretierte Sprachen würden unterstützt - Sie haben immer noch die gleichen Probleme. Die verschiedenen Browser wären immer noch fehlerhaft und hätten unterschiedliche DOMs.

Außerdem müsste für jede Sprache ein Dolmetscher in den Browser eingebaut oder irgendwie als Plug-in installiert werden (den man vor dem Aufruf der Seite überprüfen könnte). Es hat ewig gedauert, Javascript in Einklang zu bringen.

Sie können kompilierte Sprachen nicht auf dieselbe Weise verwenden - dann führen Sie eine ausführbare Datei ein, die nicht so einfach auf ihre Funktion hin überprüft werden kann. Viele Benutzer würden sich dafür entscheiden, es nicht laufen zu lassen.

OK, wie wäre es also mit einer Art Sandkasten für den kompilierten Code? Klingt für mich nach Java Applets. Oder ActionScript in Flash. Oder C# in Silverlight.

Wie wäre es mit einer Art IL-Norm? Das hat mehr Potenzial. Entwickeln Sie in welcher Sprache Sie wollen und kompilieren Sie es dann zu IL, die der Browser dann JITs.

Außer, dass Javascript irgendwie schon dieses IL ist - sehen Sie sich nur an GWT . Es ermöglicht Ihnen, Programme in Java zu schreiben, sie aber als HTML und JS zu verteilen.

---

Bearbeiten nach weiterer Klärung der Frage

Javascript ist bzw. war nicht die einzige Sprache, die von Browsern unterstützt wurde: In den dunklen Zeiten des Internet Explorers konnte man zwischen Javascript und VBScript wählen, um es im IE auszuführen. Technisch gesehen hat der IE nicht einmal Javascript ausgeführt - er hat JScript (hauptsächlich um zu vermeiden, dass Sun für das Wort java Oracle ist immer noch Eigentümer des Namens Javascript ).

Das Problem war, dass VBScript Eigentum von Microsoft war, aber auch, dass es einfach nicht sehr gut war. Während Javascript immer mehr Funktionen hinzufügte und in anderen Browsern (z. B. FireBug) erstklassige Debugging-Tools zur Verfügung standen, blieb VBScript auf den IE beschränkt und war so gut wie nicht debugging-fähig (Entwicklungswerkzeuge für IE4/5/6 gab es nicht). In der Zwischenzeit entwickelte sich VBScript auch zu einem ziemlich mächtigen Skripting-Tool im Betriebssystem, aber keine dieser Funktionen war im Browser verfügbar (und wenn doch, wurden sie zu massiven Sicherheitslücken).

Es gibt immer noch einige unternehmensinterne Anwendungen, die VBScript verwenden (und einige nutzen diese Sicherheitslücken), und sie verwenden immer noch IE7 (sie haben IE6 nur eingestellt, weil MS ihn endlich abgeschafft hat).

Es war ein Albtraum, Javascript auf den heutigen Stand zu bringen, und es hat 20 Jahre gedauert. Es gibt immer noch keine konsistente Unterstützung. Sprachfunktionen (die 1999 spezifiziert wurden) fehlen immer noch in einigen Browsern, und es werden viele Zusatzmodule benötigt.

Das Hinzufügen einer alternativen Sprache zum Dolmetschen in Browsern ist mit zwei großen Problemen verbunden:

• Alle Browserhersteller dazu zu bringen, den neuen Sprachstandard zu implementieren - etwas, das sie für Javascript in 20 Jahren immer noch nicht geschafft haben.

• Eine zweite Sprache verwässert möglicherweise die Unterstützung, die Sie bereits haben, so dass (zum Beispiel) IE eine zweitklassige Javascript-Unterstützung hat, aber (wieder) ein großartiges VBScript. Ich möchte wirklich nicht Code in verschiedenen Sprachen für verschiedene Browser schreiben.

Es sollte beachtet werden, dass Javascript noch nicht "fertig" ist - es wird immer noch weiterentwickelt, um in neuen Browsern besser zu werden. Die neueste Version ist den Implementierungen in den Browsern um Jahre voraus und sie arbeiten an der nächsten.

Answer 2

Kompilieren in Javascript

Im Moment scheint die Verwendung einer Sprache, die sich mit Javascript kompilieren lässt, die einzige realistische Möglichkeit zu sein, alle Plattformen zu erreichen und gleichzeitig intelligenteren Code zu schreiben, und das wird wahrscheinlich noch lange so bleiben. Bei jedem neuen Angebot wird es immer einen Grund geben, warum ein oder mehrere Anbieter sich nicht beeilen, es zu liefern.

(Aber ich glaube nicht, dass das wirklich ein Problem ist. Javascript ist inzwischen sehr gut optimiert worden. Maschinencode ist auch unsicher, wenn er von Hand geschrieben wird, funktioniert aber gut als Kompilierziel und Ausführungssprache).

So viele Möglichkeiten

Es gibt eine ständig wachsende Anzahl von Sprachen, die sich mit Javascript kompilieren lassen. Eine ziemlich umfassende Liste finden Sie hier:

• Liste der Sprachen, die zu JS kompiliert werden können auf dem Coffeescript-Wiki

Erwähnenswert

Ich werde einige erwähnen, die ich für bemerkenswert halte (wobei ich zweifellos einige Perlen vernachlässigt habe, die mir nicht bekannt sind):

• Spinne erschien im Jahr 2016. Es behauptet, die besten Ideen von Go, Swift, Python, C# und CoffeeScript zu übernehmen. Es ist nicht typsicher, aber es hat einige kleinere Sicherheitsmerkmale .

• Ulme : Haskell ist vielleicht die intelligenteste Sprache von ihnen allen, und Elm ist eine Variante von Haskell für Javascript. Es ist sehr typbewusst und prägnant und bietet Funktionale reaktive Programmierung als eine saubere Alternative zu reaktiven Vorlagen oder MVC-Spaghetti. Aber es kann ziemlich ein Schock für prozedurale Programmierer .

• Google's Weiter ist auf Prägnanz, Einfachheit und Sicherheit ausgerichtet. Go-Code kann in Javascript kompiliert werden durch GopherJS .

• Dart war der spätere Versuch von Google, Javascript zu ersetzen. Es bietet Schnittstellen und abstrakte Klassen durch eine C/Java-ähnliche Syntax mit optionaler Typisierung.

• Haxe ist wie das ActionScript von Flash, kann aber mehrere Sprachen anvisieren sodass Ihr Code in Java-, C-, Flash-, PHP- und Javascript-Programmen wiederverwendet werden kann. Es bietet typsichere und dynamische Objekte.

• Opalang fügt syntaktischen Zucker zu Javascript hinzu, um die direkter Datenbankzugriff , intelligente Fortsetzungen, Typprüfung und Unterstützung bei der Trennung von Client und Server. (Gebunden an NodeJS und MongoDB.)

• GorillaScript , "eine Kompilier-zu-JavaScript-Sprache, die den Benutzer unterstützen und gleichzeitig versuchen soll, einige häufige Fehler zu vermeiden." ähnelt Coffeescript, ist aber umfassender und bietet eine Reihe zusätzlicher Funktionen, um die Sicherheit zu erhöhen und sich wiederholende Boilerplate-Muster zu reduzieren.

• LiteScript liegt irgendwo zwischen Coffeescript und GorillaScript. Es bietet eine async/yield-Syntax für "Inline"-Callbacks und eine Überprüfung auf Variablentippfehler.

• Microsofts TypScript ist eine kleine Obermenge von Javascript, mit der Sie Typbeschränkungen für Funktionsargumente festlegen können, was einige Fehler abfangen könnte. Ähnlich BetterJS ermöglicht es Ihnen, Einschränkungen anzuwenden, allerdings in reinem Javascript, entweder durch Hinzufügen zusätzlicher Aufrufe oder durch Angabe von Typen in JSDoc-Kommentaren. Und jetzt hat Facebook angeboten Durchfluss die zusätzlich eine Typinferenz durchführt.

• LiveScript ist ein Ableger von Coffeescript, der wegen seiner Kürze beliebt war, aber für mich nicht sehr lesbar aussieht. Wahrscheinlich nicht das Beste für Teams.

Wie soll man wählen?

Wenn Auswahl eine alternative Sprache, gibt es einige zu berücksichtigende Faktoren :

• Wenn andere Entwickler in Zukunft zu Ihrem Projekt stoßen, wie lange werden sie brauchen, um sich einzuarbeiten und diese Sprache zu lernen, oder wie groß ist die Wahrscheinlichkeit, dass sie sie bereits kennen?

• Verfügt die Sprache über zu wenige Funktionen (der Code wird immer noch voller Standardformulierungen sein) oder über zu viele Funktionen (es wird lange dauern, sie zu beherrschen, und bis dahin ist ein Teil des gültigen Codes möglicherweise nicht entzifferbar)?

• Verfügt es über die Funktionen, die Sie für Ihr Projekt benötigen? (Braucht Ihr Projekt Typüberprüfung und Schnittstellen? Braucht es intelligente Fortsetzungen, um verschachtelte Rückrufe zu vermeiden? Gibt es eine Menge Reaktivität? Muss es in Zukunft vielleicht auf andere Umgebungen ausgerichtet werden?)

Die Zukunft...

Jeff Walker hat geschrieben eine Serie, die zum Nachdenken anregt von Blogbeiträgen über "das Javascript-Problem", einschließlich der Frage, warum er glaubt, dass weder TypScript noch Dart noch Coffeescript angemessene Lösungen anbieten. Er schlägt einige wünschenswerte Merkmale für eine verbesserte Sprache in die Schlussfolgerung .

Answer 3

Sollte JavaScript die einzige unterstützte Sprache auf der Browser-Plattform sein?

Ja und nein. Es gibt eine Alternative namens Dart von Google, die zu JavaScript kompiliert und genau wie jQuery versucht, die DOM-Manipulation etwas einfacher zu machen. Es kann Spaß machen, damit zu experimentieren, probieren Sie es aus.

• Von Google siehe Die Dartsprache
• Von Microsoft siehe TypeScript-Sprache

Siehe auch

• Ulme
• Kal

Answer 4

Es ist wahr, dass Javascript zu einem bestimmten Zeitpunkt notorisch schwer zu handhaben war, aber die Webentwicklungsgemeinschaft hat seitdem einen langen Weg zurückgelegt. Stattdessen würde ich Sie ermutigen, einen Blick zu werfen auf jQuery . Es ist einfach und abstrahiert von den verschiedenen Problemen.

Und es gibt wirklich keine Alternativen, die in allen Bereichen funktionieren. Flash kommt mir in den Sinn, aber auch das ist ein ECMA-Skript und für die meisten Dinge wahrscheinlich überflüssig.

Answer 5

Kurzfristig würde ich Dinge wie jQuery verwenden, um die Browser-Inkompatibilitäten zu verbergen. Langfristig können Technologien wie Silverlight oder Adobe AIR dieses Minenfeld in der Zukunft ganz anders gestalten (aber immer noch ein Minenfeld).