Warum JavaScript statt einer standardmäßigen virtuellen Browsermaschine?

Lesezeit: 8 Minuten

Wäre es nicht sinnvoll, eine Reihe von Sprachen (Java, Python, Ruby usw.) über eine standardisierte virtuelle Maschine zu unterstützen, die im Browser gehostet wird, anstatt die Verwendung einer spezialisierten Sprache zu erfordern – eigentlich ein spezialisiertes Paradigma – nur für Client-Scripting?

Um den Vorschlag zu verdeutlichen, würde eine Webseite Bytecode anstelle einer höheren Sprache wie JavaScript enthalten.

Ich verstehe die pragmatische Realität, dass wir aus evolutionären Gründen jetzt einfach mit JavaScript arbeiten müssen, aber ich denke eher langfristig. Im Hinblick auf die Abwärtskompatibilität gibt es keinen Grund, dass Inline-JavaScript nicht gleichzeitig für einen bestimmten Zeitraum unterstützt werden könnte, und natürlich könnte JavaScript eine der Sprachen sein, die von der virtuellen Browsermaschine unterstützt werden.

  • Ich weiß nicht, warum das abgewählt wird. Ich dachte, es war eine gute Frage!

    – Benutzer4903

    17. September 2008 um 20:47 Uhr

  • Weil es mehr eine Beschwerde als eine Frage ist.

    – Müllmann

    22. September 2008 um 19:51 Uhr

  • Es liegt an der Idee, dass Javascript keine echte Sprache ist oder nicht so gut ist wie andere Sprachen. Beides trifft seit den Anfängen nicht zu, doch die „schmutzige“ Wahrnehmung besteht gegenwärtig fort.

    – Adam Davis

    7. Oktober 2008 um 21:49 Uhr

  • Wow, ich habe die SO-Community noch nie so komplett versagen sehen. Die einzigen Antworten, die sich überhaupt mit der hier vorgeschlagenen Idee befassen, sind ganz unten und werden heruntergestimmt, während die Antworten, die unnötigerweise „JS verteidigen“, die ganze Liebe bekommen. Diese Frage greift JS nicht an, sie befürwortet lediglich eine Wahl. Es heißt einfach: “Was auch immer Sie von JS halten mögen, wäre es nicht schön, auch andere Sprachen verwenden zu können, wenn Sie sie bevorzugen?”. Was stimmt nicht mit dir?

    – Jordi

    17. Dezember 2010 um 7:24 Uhr

  • Dies ist ein großes Problem mit StackOverflow, das Bearbeitungen bis weit in die Zukunft ermöglicht, nachdem mehrere Antworten bereitgestellt wurden. Die ursprünglich gestellte Frage ist für die Top-Antworten relevanter, während der Rest den “neuen Geist” der Frage nach den Änderungen anspricht.

    – Benutzer4903

    18. Dezember 2010 um 2:57 Uhr

Ich denke, JavaScript ist eine gute Sprache, aber ich hätte gerne die Wahl, wenn ich clientseitige Webanwendungen entwickle. Aus Legacy-Gründen stecken wir bei JavaScript fest, aber es gibt Projekte und Ideen, die versuchen, dieses Szenario zu ändern:

  1. Google Native-Client: Technologie zum Ausführen von nativem Code im Browser.
  2. Emscripten: LLVM-Bytecode-Compiler zu Javascript. Ermöglicht die Ausführung von LLVM-Sprachen im Browser.
  3. Idee: .NET-CLI im Browser, vom Schöpfer von Mono: http://tirania.org/blog/archive/2010/May-03.html

Ich denke, wir werden JavaScript noch lange haben, aber das wird sich früher oder später ändern. Es gibt so viele Entwickler, die bereit sind, andere Sprachen im Browser zu verwenden.

  • LLVM könnte eine Antwort auf all dies sein. Es gibt bereits eine große Anzahl von Sprachen (Python, Ruby, sogar Java) mit Unterstützung für die Kompilierung zu LLVM, und LLVM kann zu Javascript kompiliert werden, sodass wir zumindest automatische LLVM-Unterstützung in Browsern erhalten könnten, indem wir einfach zu JS kompilieren. Natürlich kann LLVM nicht für alle Programmierparadigmen und spezifischen Sprachen optimiert werden, sodass die Leistung nicht der von 100 % nativem entspricht, aber die JITs/Interpreter von Javascript waren selbst unter Berücksichtigung der jüngsten Fortschritte ohnehin immer langsam im Vergleich zu nativen .

    – Pepe Mandioka

    12. Oktober 2015 um 2:14 Uhr

  • Eine ziemlich subjektive Antwort, aber ich wollte nicht ablehnen, da Sie einige gute Punkte ansprechen (und die ursprüngliche Antwort ist ohnehin eher ein Diskussionsstarter).

    – Gerbrand

    18. Dezember 2010 um 13:52 Uhr

  • Ich glaube nicht, dass die VM im Browser zu schwer sein muss. Natürlich existiert es bereits als Silverlight und Applets. Letzteres konnte nicht an Popularität gewinnen, ich denke hauptsächlich wegen schlechtem Timing und technischen Dummheiten, die meistens behoben werden. Jede Sprache zwischen dem Skript-Tag (mit Einschränkungen) zuzulassen, wäre ziemlich cool und sicherlich nicht unmöglich oder unpraktisch.

    – Gerbrand

    18. Dezember 2010 um 13:55 Uhr

  • Schwere (MB)? Wahrscheinlich in Ordnung. Schwere (Komplexität)? Weg zu schwer. Auf jeder mehrsprachigen VM, die Sie haben, sitzen Sprachimplementierungen (z. B. JRuby/IronRuby, Clojure, Jython/IronPython) usw. Entweder die JVM frisst die Komplexität oder die Sprachimplementierer tun es.

    – der glückliche Idiot

    20. Dezember 2010 um 20:57 Uhr

  • Es würde einen unglaublichen Arbeitsaufwand erfordern, mehrere Sprachen für mehrere brandneue Plattformen (IE/Firefox/Safari…) neu zu implementieren. Und auch die Sprachen ändern sich. “Diese Seite ist nur in einem Ruby 1.9-Browser sichtbar”? Bitte nicht.

    – der glückliche Idiot

    20. Dezember 2010 um 21:07 Uhr

  • Ich glaube nicht, dass Sie die Frage richtig beantworten, Sie geben nur an, warum Sie der Meinung sind, dass andere Sprachen nicht für das geeignet sind, was Javascript im Moment im Browser tut. Ein universeller Bytecode, der für das Web geeignet ist, wäre etwas, in das andere Sprachen kompilieren, wenn diese Sprache nützlich ist, liegt es an ihrem Schöpfer, nicht am Web-Bytecode, viele Sprachen tun dies übrigens bereits, indem sie in Javascript (dh dart) kompilieren.

    – Timotheus

    5. Januar 2014 um 11:08 Uhr

Unter Windows können Sie andere Sprachen beim Scripting Host registrieren und sie für IE verfügbar machen. Beispielsweise wird VBScript standardmäßig unterstützt (obwohl es nie viel Popularität erlangt hat, da es für die meisten Zwecke noch schlechter als JavaScript ist).

Die Python-Win32-Erweiterungen erlaubten es, Python ganz einfach auf diese Weise zum IE hinzuzufügen, aber es war keine wirklich gute Idee, da Python ziemlich schwierig zu sandboxen ist: Viele Sprachfunktionen legen genügend Implementierungs-Hooks offen, um eine vermeintlich eingeschränkte Anwendung auszubrechen .

Es ist im Allgemeinen ein Problem, dass je mehr Komplexität Sie einer netzorientierten Anwendung wie dem Browser hinzufügen, desto größer ist die Wahrscheinlichkeit von Sicherheitsproblemen. Ein Haufen neuer Sprachen würde sicherlich auf diese Beschreibung passen, und dies sind neue Sprachen, die sich auch noch schnell entwickeln.

JavaScript ist eine hässliche Sprache, aber durch sorgfältige Verwendung einer ausgewählten Teilmenge von Funktionen und Unterstützung durch geeignete Objektbibliotheken kann sie im Allgemeinen einigermaßen erträglich gemacht werden. Es scheint, dass inkrementelle, praktische Ergänzungen zu JavaScript der einzige Weg sind, wie sich das Web-Scripting wahrscheinlich weiterentwickeln wird.

Ich würde auf jeden Fall eine von der Standardsprache unabhängige VM in Browsern begrüßen (ich würde es vorziehen, in einer statisch typisierten Sprache zu programmieren).

(Technisch) Es ist nach und nach durchaus machbar: Zuerst unterstützt es ein großer Browser und der Server hat die Möglichkeit, entweder Bytecode zu senden, wenn die aktuelle Anfrage von einem kompatiblen Browser kommt, oder den Code in JavaScript zu übersetzen und JavaScript im Klartext zu senden.

Es gibt bereits einige experimentelle Sprachen, die zu JavaScript kompiliert werden, aber eine definierte VM würde (vielleicht) eine bessere Leistung ermöglichen.

Ich gebe zu, dass der “Standard”-Teil ziemlich knifflig wäre. Außerdem würde es Konflikte zwischen Sprachfunktionen (z. B. statische vs. dynamische Typisierung) in Bezug auf die Bibliothek geben (vorausgesetzt, das neue Ding würde dieselbe Bibliothek verwenden). Daher glaube ich nicht, dass es (bald) passieren wird.

Wenn Sie das Gefühl haben, sich die Hände schmutzig zu machen, dann wurden Sie entweder einer Gehirnwäsche unterzogen oder spüren immer noch die Nachwirkungen der „DHTML-Jahre“. JavaScript ist sehr leistungsfähig und eignet sich gut für seinen Zweck, nämlich die clientseitige Skripterstellung für Interaktivität. Aus diesem Grund hat JavaScript 2.0 einen so schlechten Ruf. Ich meine, warum Pakete, Schnittstellen, Klassen und dergleichen, wenn dies eindeutig Aspekte serverseitiger Sprachen sind. JavaScript eignet sich gut als prototypbasierte Sprache, ohne vollständig objektorientiert zu sein.

Wenn es Ihren Anwendungen an Nahtlosigkeit mangelt, weil die Kommunikation zwischen Server und Client nicht gut ist, sollten Sie die Architektur Ihrer Anwendungen überdenken. Ich habe mit extrem robusten Websites und Webanwendungen gearbeitet und nie gesagt: “Hmm, ich wünschte wirklich, JavaScript könnte (xyz) tun.” Wenn es das könnte, dann wäre es nicht JavaScript – es wäre ActionScript oder AIR oder Silverlight. Ich brauche das nicht, und die meisten Entwickler auch nicht. Das sind nette Technologien, aber sie versuchen, ein Problem mit einer Technologie zu lösen, nicht mit einer … nun ja, einer Lösung.

  • Wie können Sie sagen, dass JavaScript nicht vollständig objektorientiert ist? Es ist sicherlich eine der objektorientiertesten Sprachen, die ich kenne. Alles in JavaScript ist ein Objekt – sogar Funktionen. Es ist nur so, dass OOP in JavaScript nicht wie OOP in vielen anderen Sprachen aussieht.

    – René Saarsoo

    18. September 2008 um 20:23 Uhr

  • OOP ist JavaScript nicht inhärent. Sie haben keine Pakete, Schnittstellen, abstrakten Klassen oder das Überladen von Methoden in den Kern eingebaut, und Sie können ein Objekt nicht erweitern – nur den Prototyp eines Objekts, wodurch es technisch prototypbasiert und nicht OOP-basiert ist.

    – Benutzer4903

    19. September 2008 um 16:14 Uhr

  • Voll daneben. “Protyp” ist ein Entwurfsmuster (Gamma et. al., S. 117–126). Wie Sie sich erinnern werden, drehen sich Entwurfsmuster um allgemeine Entwürfe in der objektorientierten Programmierung. Und nur weil die Sprache nicht die gleichen Funktionen wie andere OOP-Sprachen hat, heißt das nicht, dass sie nicht OOP ist.

    – Müllmann

    22. September 2008 um 19:50 Uhr

  • Sie liegen nicht völlig falsch, ich denke, der beste Weg, es auszudrücken, ist, dass JS kein klassenbasiertes OO ist, sondern ein prototypisches OO.

    – Juan Mendes

    3. Dezember 2010 um 0:22 Uhr

  • 1. Javascript ist vollständig OOP. Bei OOP geht es um Objekte, nicht um Klassen. 2. Sie können ein Objekt in JavaScript erweitern, das ist der springende Punkt der prototypischen objektorientierten Programmierung. 3. Du beantwortest die Frage nicht, die Frage greift JS nicht an, fragt nur nach einer Wahl. Ich denke, JS ist eine großartige Sprache, aber ich hätte gerne andere Möglichkeiten, wenn ich im Browser programmiere.

    – Manuel Céron

    17. Dezember 2010 um 9:44 Uhr

1283350cookie-checkWarum JavaScript statt einer standardmäßigen virtuellen Browsermaschine?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy

Contact - Terms and Conditions - Privacy Policy