Kann ich jemals clientseitigen Browsercode in einer Sprache meiner Wahl codieren? [geschlossen]

15

Geschlossen . Diese Frage ist meinungsbasiert . Derzeit werden keine Antworten akzeptiert.

Möchten Sie diese Frage verbessern? Aktualisieren Sie die Frage, damit sie mit Fakten und Zitaten beantwortet werden kann, indem Sie diesen Beitrag bearbeiten .

Geschlossen vor 6 Jahren .

Ich bin ganz ehrlich: Ich hasse es, clientseitigen Code in JavaScript zu schreiben. Ich bin kein Fan dieser Sprache, um es gelinde auszudrücken.

Es scheint dumm zu mir , dass Browser eine Programmierung unterstützen Sprache , anstatt eine Zwischen virtuelle Maschine (wie CIL oder JVM). Letzteres würde es Programmierern ermöglichen, in einer Sprache ihrer Wahl (bis zu einem gewissen Grad) zu schreiben, anstatt in einer festen voreingestellten Sprache. Diese Sprache könnte sich schneller weiterentwickeln, da nur Änderungen an der CIL / JVM / was auch immer jedes größere Browser-Upgrade erfordern würde. Sprachfunktionen könnten hinzugefügt werden, ohne die alte Browser-Erfahrung zu beeinträchtigen.

Die enormen Aufwandsersparnisse von Zwischensprachen sind bekannt . Gibt es Initiativen, um das "Scripting" von Browsern in etwas anderem als JavaScript zu fördern, insbesondere in einer bereits entworfenen, entwickelten und optimierten virtuellen Maschine? Haben sie irgendeine Dynamik?

programming-languages browser

— Roman Starkov
quelle

Siehe auch: Warum gibt es keine anderen clientseitigen Skriptsprachen für Websites?

— gnat

11

Um Ihre Frage zu beantworten, werden Anstrengungen unternommen, um Javascript zugunsten einer kohärenteren Sprache für das Web-Scripting abzuschaffen. Google hat seiner Dart- Sprache viel Schub verliehen . Dart hat eine eigene VM, die bereits in Chrome eingebettet ist, aber ich bin mir nicht sicher, ob die anderen Browser diese bereits übernommen haben. Es gibt auch eine vielversprechende Sprache namens CoffeeScript .

Es gibt auch ein sehr ehrgeiziges Projekt namens HaXe, das darauf abzielt, eine ganze Reihe von Entwicklungsplattformen mit einer einzigen Sprache zu vereinen.

Glauben Sie mir, dass Sie nicht alleine sind, wenn Sie Javascript nicht mögen, aber ich befürchte, dass es nicht in naher Zukunft weitergehen wird - in der Tat scheint es eine Menge Schwung zu gewinnen, was mit Windows 8 HTML5 / JS-Apps usw., aber Alternativen wie denen von mir erwähnt fangen an aufzusteigen :)

— MattDavey
quelle

9

Alles in einer Sprache zu vereinen ist genau das Gegenteil von dem, was gewünscht wird. Es bleibt Ihnen nur die gleiche Situation wie jetzt, nur mit einer anderen Sprache anstelle von JavaScript. Der Punkt ist, dass auf bestehenden Bemühungen aufgebaut werden sollte: IL / CLR ist gut etabliert, verfügt bereits über leistungsstarke JITter für die meisten Plattformen und mehrere Compiler kompilieren bereits mehrere Sprachen. Um das Web ins 21. Jahrhundert zu bringen, müssen Browser dies nutzen, anstatt ständig zu versuchen, ihre eigenen neuen Sachen zu backen und von vorne zu beginnen.

— Timwi

3

@ Timwi, CIL ist zu schwer und es ist zu viel Bürokratie drin. Es wäre nicht sinnvoll, eine vollständige, aufgeblähte Bytecode-Datei mit einer dedizierten Klasse und allen umfangreichen Metadaten an jeden einzelnen onSomethingEvent-Handler anzuhängen - das Parsen und Interpretieren von 10 bis 20 Zeichen einer einfachen Skriptsprache ist wesentlich effizienter.

— SK-logic

1

@ SK-logic: Sie scheinen ein völlig falsches Bild von CIL und von Bytecode im Allgemeinen zu haben. Ich habe keine Ahnung, warum Sie glauben, dass binäre Metadaten im Vergleich zu einer Syntax auf hoher Ebene wie JavaScript "sperrig" sind. Am allermeisten habe ich keine Ahnung, warum der "Every On Something Event Handler". Es ist klar, dass C # -Programme nicht für jeden Ereignishandler in mehrere Assemblys kompiliert werden.

— Timwi

1

@ Timwi, ich esse ECMA-335 zum Frühstück, also weiß ich nur zu gut, wie sperrig die CIL ist. DOM-Knoten werden häufig dynamisch generiert. Es gibt keine Möglichkeit, einem vorhandenen Modul in CIL etwas hinzuzufügen - Sie müssen ein neues Modul definieren. Und Sie können einer Klasse nichts hinzufügen - Sie müssen eine neue Klasse definieren (mit den anhängenden umfangreichen Metadaten). Und vergleichen Sie einfach die Kosten für das Lesen, JITen und Ausführen von CIL mit dem Parsen, Ausführen und sofortigen Verwerfen einer winzigen Textzeichenfolge. In vielen Fällen ist eine Ad-hoc-Interpretation weitaus effizienter als jede Art von Zusammenstellung.

— SK-logic

2

@ Timwi, Sie schlagen vor, den Bytecode als gemeinsamen Nenner und als Kommunikationsformat zu verwenden, oder? Mein Punkt ist, dass die aktuelle Spezifikation der CIL so ziemlich nutzlos ist. ExpandoObject ist irrelevant. Und Ihre Sicht auf die Analyse von Komplexität ist verdeckt. Das CIL-Modul enthält eine eigene Assembly-Referenztabelle, eine Metadaten-Token-Tabelle und erst dann Klassen und Methoden. Vergleichen Sie den Aufwand für das Lesen und JIT all dieser sperrigen Dinge mit der Interpretation einer Zeichenfolge einer trivialen Hochsprache. Die Parsingkosten sind hier nahezu Null. Probieren Sie einfach beide Ansätze aus und vergleichen Sie sich.

— SK-logic

5

Javascript selbst kann als Zwischensprache angesehen werden und definiert eine virtuelle Maschine, in die andere Sprachen kompiliert werden können. In Projekten wie GWT setzt sich dieser Gedanke bereits durch. Es ist vielleicht nicht das, was Sie von Grund auf neu entwerfen würden, aber es wird bereits Realität, dass Sie "Ihre Lieblingssprache" in Javascript kompilieren könnten.

— John Snelson
quelle

5

Im Wesentlichen nein. Sie sind ziemlich fest mit Javascript.

Allerdings hat es in der Vergangenheit Anstrengungen gegeben, andere Sprachen (Java-Applets, VBScript usw.) an Bord zu bringen. Jede dieser Sprachen hat nie wirklich die Anziehungskraft erlangt, die Javascript hat, weil Javascript integriert ist .

Die einzige Möglichkeit, das zu erstellen, worauf Sie sich beziehen, besteht darin, eine Skriptsprache zu erstellen, die auf einer virtuellen Maschine ausgeführt, clientseitig kompiliert und dann ausgeführt wird. Dann müsste jeder Browser die virtuelle Maschine in eine eigene Codebasis implementieren, damit der gesamte Code auf allen Browsern ausgeführt wird. Dann müssten Sie sicherstellen, dass Sie eine Art von Standards haben, damit alle Browser die Befehle auf die gleiche Weise ausführen. Natürlich, wenn Browser unabhängig erstellt werden, würde es wahrscheinlich Macken geben, die die Entwickler beachten müssten.

Aber jetzt haben wir gerade Javascript beschrieben.

Am Ende haben Sie also die Wahl zwischen:

gewöhne dich an Javascript
Versuchen Sie, eine Sprache zu verwenden, die bis zu Javascript kompiliert wird. (Denken Sie daran, dass Sie immer noch das Javascript überprüfen möchten, was wiederum Option 1 betrifft.)
Verwenden Sie eine Sprache, die als Plug-In für den Browser vorhanden ist, z. B. Actionscript (Flash), ActiveX, Java-Applet, .NET (SilverLight). Dies vermeidet das Problem mit mehreren Anbietern / Implementierungen der Sprache, integriert jedoch nicht die Sprache.

Wenn Sie eine integrierte Sprache möchten, müssen Sie im Wesentlichen Javascript verwenden.

— Richard
quelle

2

Eine andere Möglichkeit wäre, eine Sprache zu verwenden, die zu Javascript kompiliert und dieses verwendet.

— Jetti

@Jetti Denkst du an CoffeeScript ? Es ist das Motto - es ist "Goldene Regel", wie sie es nennen - "Es ist nur Javascript" . Aber wenn Sie etwas schreiben, das im Wesentlichen Javascript ist, schreiben Sie dann nicht wirklich Javascript? Es ist, als würde man argumentieren, dass jQuery kein Javascript ist, weil es sauberer und benutzerfreundlicher ist.

— Richard

2

Werfen Sie einen Blick auf diese Liste von Sprachen, die zu Javascript kompilieren

— Jetti

@ Jetti Vielleicht würden sie gut funktionieren. Angesichts der Eigenartigkeit der browserübergreifenden Unterstützung wäre ich nervös, wenn ich eines davon empfehlen und das tatsächlich erzeugte Javascript nicht verifizieren würde.

— Richard

1

Abgesehen davon, dass Javascript eine absolut schreckliche Zwischensprache ist und sehr schwer durchgängig auszuführen ist.

— Milind R

4

Tatsächlich hassen Sie kein Javascript, wie in den Ecma-Standards beschrieben, aber Sie hassen die schreckliche Implementierung in verschiedenen Browsern , mit ihren Macken, Fehlern und WTFS. Server-seitiges Javascript macht eigentlich Spaß. Das DOM-Modell ist auch die Ursache für 80% der Schmerzen von clientseitigem Javascript.

Wenn Sie dennoch eine andere Sprache verwenden möchten, können Sie GWT verwenden , mit dem Sie im Grunde Java schreiben und dann in (hässliches) Javascript kompilieren können, oder CoffeeScript , ein syntaktischer Zucker über JS, der in JS kompiliert wird.

— Clement Herreman
quelle

9

Ich kann nicht für Romkyns sprechen, aber ich hasse JavaScript selbst ( zusätzlich zu den von Ihnen erwähnten Problemen). Es ist nicht objektorientiert, hat keine statische Typisierung, keine nützliche Fehlerbehandlung und kein nützliches Framework für moderne Funktionen. Es ist auch inkonsistent und unhandlich. Und übrigens, die am meisten gehasste Merkmal von JS, Semikolon Insertion, ist in dem ECMA - Standard.

— Timwi

1

@ Timwi, es ist funktionsbasiert und Sie können OO-Code schreiben, wenn Sie möchten. Statische Eingabe ist nett, aber wenn Ihr Code gut geschrieben ist (kleine Funktionen, richtiges Scoping), ist es selten ein Problem. Was das Einfügen von Semikolons angeht, empfinde ich das als leichte Belästigung. Es hat mich immer nur einmal gebissen, weil ich {ein Objekt in verschiedenen Zeilen zurückgebracht und geöffnet habe . Welcher "Rahmen moderner Funktionalität" fehlt Ihrer Meinung nach?

— CaffGeek

2

JavaScript selbst ist nicht die beste Sprache (um es höflich auszudrücken). Ich interessiere mich nicht für objektorientierte Dinge (je weniger, desto besser), für das dynamische Typsystem (es wird leider wirklich für eine solche Skriptsprache benötigt), sondern für das Vorhandensein von Anweisungen und das Fehlen von Eigenem Listen und Tupel sind nervig. Sowohl zum Schreiben in JavaScript als auch zum Implementieren von Compilern, die auf JavaScript abzielen.

— SK-logic

2

@Timwi: Du siehst das nicht als schlecht an, obwohl es nicht immer der Fall ist. Bitte sehen Sie OOP nicht als die Silberkugel der Entwicklungsparadigmen. Funktionale Ansätze wie JS oder Scala sind ebenfalls großartig. Sie können OOP in JS verwenden, aber der Hauptunterschied besteht darin, dass es sich um eine prototypbasierte Programmierung handelt und nicht um eine klassenbasierte Programmierung. OOP ist ein weit gefasster Name und beschränkt sich nicht auf Java / C #. Prototypbasiert unterscheidet sich von klassenbasiert und ist genauso leistungsfähig wie klassenbasiert.

— Clement Herreman

2

@ClementHerreman: JavaScript ist nicht auf die Clientseite beschränkt, aber in dieser Diskussion geht es um die Clientseite. JavaScript ist auf Prototypen beschränkt, was im Vergleich zu IL ein Nachteil ist, mit dem Sie so ziemlich jede Sprache verwenden können.

— Timwi

2

Diese Frage taucht von Zeit zu Zeit auf.

Warum haben wir nicht andere Sprachen in Skript-Tags anstatt nur Javascript?

Damals führte IE VB als Alternative zu Javascript ein. Ich denke, man kann schon sehen, wie das zur Hölle der Standards führen würde, wenn es sich durchsetzen würde ...

Warum also nicht eine gemeinsame Standard-Zwischensprache?

Es gibt einen alten Podcast von Brendan Eich, der erklärt, warum er in naher Zukunft keine Zwischenbytecode-Sprache sieht:

http://www.aminutewithbrendan.com/pages/20101122

http://news.ycombinator.com/item?id=1893686

Das Grundproblem besteht darin, dass die Zwischensprache (wie CIL und die JVM-Bytecodes) versucht, generisch zu sein, sich jedoch meist als zu niedrig und zu stark an die ursprünglichen Hochsprachen gebunden herausstellt, die für sie kompiliert wurden. Beispielsweise können Sie in der JVM keine rekursiven Tail-Funktionen implementieren. Welche anderen Sprachfunktionen oder Implementierungsoptionen können wir nicht implementieren, wenn wir zu früh mit einer Bytecode-Abstraktion auf niedriger Ebene koppeln?

Mittlerweile ist Javascript eine flexible Hochsprache mit erweiterter Semantik und mehreren, unterschiedlichen, effizienten Implementierungen. Was wir in Zukunft vielleicht sehen werden, ist Javascript selbst als Zwischensprache. Leider ist dies etwas unausgereift und einige Sprachen sind seit heute für JS kompilierbar.

— hugomg
quelle

Aber dieses Argument gilt für JavaScript genauso wie für JVM und CIL, nicht wahr? :) Das einzige, was für JavaScript gilt, ist, dass es bereits von allen Browsern unterstützt wird.

— Roman Starkov

Der Punkt ist subtiler - Javascript wird in einer höheren Ebene als die meisten Zwischensprachen beschrieben, sodass Implementierungen mehr Spielraum bei der Auswahl der zu treffenden Aktionen erhalten. (Natürlich ist dies nicht alles ein Meer von Rosen - ich wollte nur darauf hinweisen, dass wir nicht die ersten sind, die über eine IL für das Web nachdenken und dass es nicht so einfach ist)

— hugomg

1

Ja. Sie können Dart, Coffeescript und Java bereits zu Javascript kompilieren. Sie haben Emscripten, ein Compiler-Backend für LLVM zum Generieren von Javascript-Bytecode (und LLVM beherrscht, glaube ich, einige Sprachen).

Aber anders als das Kompilieren zu JS, nicht in kurzer Zeit. IE6 ist 10 Jahre alt und immer noch munter. Ich hoffe, dass aktuelle Browser (die keine anderen Sprachen unterstützen) nicht so lange überleben, aber sie werden ein paar Jahre lang verfügbar sein, was zu dem schwindelerregenden Zyklus "Wir müssen immer noch Browser unterstützen, die nur Javascript unterstützen, wir müssen also "Javascript" verwenden, viel schwieriger als CSS3 - Ihre Website funktioniert möglicherweise ohne CSS3, aber versuchen Sie, es ohne clientseitiges Scripting zum Laufen zu bringen.

— Alex
quelle

0

Sie könnten nur Glück haben. Dies ist der erste Absatz eines Beitrags im webkit-dev-Forum:

Viele Sprachen werden heute mit JavaScript kompiliert, um im Web ausgeführt zu werden. Als Alternative haben wir versucht, verschiedene Sprachlaufzeiten in WebKit so zu aktivieren, dass sie neben JavaScript auch auf Webseiten ausgeführt werden können ...

Sie können den Rest der Nachricht hier anzeigen .

— pgfearo
quelle

0

JavaScript ist die Seele des Browsers. Aus diesem Grund wird bei den meisten neuen Versuchen JavaScript generiert (CoffeeScript ist ein klares Beispiel).
In GWT codieren Sie Ihre clientseitige Logik in der Programmiersprache Java, und das Toolkit generiert JavaScript.

ClojureScript ist ein interessantes Projekt, wenn Sie sich in Lisp-Codierung befinden.

So sieht es aus, egal was, JavaScript ist hier zu bleiben. (COBOL des Webs vielleicht?).

— Chiron
quelle

0

"Jeder Kunde kann ein Auto in jeder gewünschten Farbe lackieren lassen, solange es schwarz ist." -- Henry Ford

Es gibt bereits eine Reihe von Compilern, die auf Javascript abzielen, und Sie können jede Sprache auswählen , die auf Javascript kompiliert wird.

In Ihrem Link zum Wert von Zwischensprachen werden diese im Zusammenhang mit der Implementierung einer Compiler-Suite erläutert, nicht bei der Bereitstellung von Code, der über ein Netzwerk versendet und auf einem Client-Computer ausgeführt wird. Javascript ist vielleicht nicht das beste Format dafür, aber was auch immer ist, es sieht nicht so aus wie CIL- oder Java-Bytecodes.

Wenn Sie Javascript hassen, empfehlen wir Ihnen, in den Bereich Embedded, Scientific oder Spieleentwicklung zu wechseln, in dem C, Fortran und C ++ die Hauptrolle spielen. Branchen-Apps bewegen sich sehr stark im Web, und das bedeutet mehr Javascript, nicht weniger.

— Sean McMillan
quelle