Warum gibt es nichts anderes als JavaScript im Browser Frontend?
Es gibt Dart-Flutter, C#-Blazor soweit ich weiß, aber ich nehme an, es ist nur JavaScript unter der Haube.
Ähnlich wie, wenn man React Native Code schreibt, wird es in die native mobile Sprache umgewandelt => Kotlin, Swift etc..
Weil soweit ich weiß, versteht der Browser nichts anderes als HTML, CSS und JavaScript.
Es gibt da nur die V8-Engine / andere JavaScript-Engines.
Aber warum?
Wieso ist es nicht theoretisch möglich, einfach mit einer neuen Sprache die für cross platform entwickelt wurde, einen onclick-Event Listener zu nutzen?
In einer ganz eigenen Engine.
Heißt nicht, das sie JavaScript irgendetwas die nächsten 5 Jahre streitig machen könnte, aber wenn diese Sprache direkt Typisierung unterstützen würde, ohne TypeScript und auch noch für andere Dinge besser geeignet wäre als JavaScript (wurde halt nicht dafür designed, ganz egal ob Electron, Native existiert) wie Desktopanwendungen, Mobil, etc..
PHP nehme ich erst garnicht auf, das macht alleine gar nichts im Frontend, ist eine Backendsprache und alleine sinnlos auf Websites, bis auf bisschen HTML generieren, das auch nur vom Server kommt.
Klar, wenn du ewig lange Weiterleitungen willst, die furchtbar sind und überhaupt nicht interaktive Websites, dich auf Formulare beschränkst, dann kriegst du das auch ohne JavaScript hin, etwas Schreckliches zu programmieren.
Mit WebAssembly kenne ich mich gar nicht aus. Ob da Event Listener, usw. möglich sind. Aber alleine von der Einstiegshürde und Komplexität die ich höre, ist das keine Alternative.
Assembly ist auch keine Alternative zu C++. Dafür gibt es Rust.
5 Antworten
Es gibt Dart-Flutter, C#-Blazor soweit ich weiß, aber ich nehme an, es ist nur JavaScript unter der Haube.
Bei Dart trifft das zu, bei Blazor ist es eine Kombination aus WebAssembly (WASM) und JavaScript.
Weil soweit ich weiß, versteht der Browser nichts anderes als HTML, CSS und JavaScript.
Wenn man sich einmal auf die gebräuchlichsten Webbrowser konzentriert (Chrome, Edge, Firefox, Opera, Safari), dann kann man die Liste noch um GLSL (Shading Language für WebGL), SVG, WASM, XHTML und XML erweitern.
Wieso ist es nicht theoretisch möglich, einfach mit einer neuen Sprache (...) einen onclick-Event Listener zu nutzen?
Das ist möglich. Ein paar Beispielprojekte dafür gab es auch schon in der Vergangenheit:
- Adobe Flash (Plugin; Programmierung mit ActionScript)
- Dart (sollte ein nativer Ersatz für JavaScript werden, hat es aber nie über eine Previewversion im Chromium-Browser geschafft)
- Java Applets (anfangs wurde die VM direkt in NetScape und IE integriert, in späteren Versionen und anderen Browsern wurde sie als extra Plugin ausgelagert)
- MS Silverlight (Plugin; Programmierung mit .NET-Sprachen)
Letzten Endes wurde ihr Support aber aufgrund von Sicherheitsaspekten und Wartungsaufwand eingestellt. Für einen Ausgleich auf funktionaler Ebene haben sich HTML, CSS und JavaScript weiterentwickelt (siehe bspw. Canvas API, CSS Animationen, Mediaelemente audio und video).
Aber warum?
Würde ein Browserentwickler heute damit anfangen, eine neue Sprache (als JavaScript-Ersatz) in seinen Browser zu integrieren, stände er vor dem Problem, künftig doppelten Aufwand betreiben zu müssen: Einmal für den Support von JavaScript und einmal für den Support der eigenen Sprache. Letztere müsste den gleichen Funktionsumfang wie JavaScript abdecken, um mindestens gleichwertig zu sein.
Das sind meines Wissens auch wesentliche Gründe, wieso die DartVM ihren Weg nicht in Chrome gefunden hat. Zum einen war die Sprache Dart selbst sowie die darumliegende Technologie für ein stabiles Endprodukt noch nicht weit genug entwickelt. Zum anderen ist der Einbau einer solchen neuen Engine nicht gerade einfach und birgt Nachteile: Eine zunehmende Komplexität des Browserprojekts und einen Performance-Overhead (mehr benötigter Speicherplatz, evt. eine langsamere Ausführungsgeschwindigkeit - wobei das bei der DartVM nicht der Fall war).
Als zusätzliche Frage stände im Raum, inwiefern die Konkurrenz (Apple, Microsoft, Mozilla) auf die Einführung von Dart in Chrome reagiert hätte, denn grundsätzlich stand man einer Einbindung in die eigenen Browser ablehnend gegenüber. Es wäre zumindest wieder ein erster Schritt entgegen einheitlicher Browserstandards gewesen, was Google vermeiden wollte. Für einen Webentwickler besteht auch kein großer Anreiz eine geplante Webanwendung mit einer extra Sprache noch einmal nur für Browser XY zu entwickeln, wenn es bereits eine Technik gibt, mit der er alle wichtigen Browser auf einmal bedienen kann.
(...) aber wenn diese Sprache direkt Typisierung unterstützen würde, (...)
Das ist etwas, was eher während der Entwicklungszeit von Bedeutung ist. Daher sind die aktuellen Lösungen (Dart, TypeScript, ...) ausreichend. Die Kompilierung ist hierbei kein Hindernis, darum kann sich ein Ressourcenbundler vor dem Deployment kümmern.
(...) und auch noch für andere Dinge besser geeignet wäre (...) wie Desktopanwendungen, Mobil, etc..
Für eine Sprache, die im Web eingesetzt werden soll, sind andere Anwendungsfelder nicht relevant. Der Browser selbst ist doch schon ein gutes Mittel, um Anwendungen mit grafischer Oberfläche auf verschiedene Plattformen zu bringen.
Es ist besser, den Fokus auf ein einzelnes Feld zu legen, denn bereits da ist es schwer, sich gegen bestehende Konkurrenz durchzusetzen. JavaScript hat eine große, aktive Community (denke nur an NPM mit seiner Vielzahl an JavaScript-Bibliotheken), mehrere Unternehmen kümmern sich um den Fortschritt des Standards (s. ECMA-International). Wenn ein Entwickler die Wahl zwischen einer Technologie mit großer Auswahl an Support hat und einem Nischenprojekt, wird Letzteres so gut wie immer verlieren.
Außerdem gibt (und gab) es schon genügend technologische Ansätze, um cross-platform zu entwickeln (s. C++/Qt, Dart, Java, Kotlin, .NET). Neben dem hohen Aufwand ist das allerdings auch ein ständiger Kampf gegen die Interessen anderer Unternehmen.
Mit WebAssembly kenne ich mich gar nicht aus. Ob da Event Listener, usw. möglich sind.
Ja, allerdings erfolgt der Zugriff auf das DOM derzeit noch indirekt über JavaScript.
Aber alleine von der Einstiegshürde und Komplexität die ich höre, ist das keine Alternative.
Normalerweise schreibt man WASM-Code nicht händisch, sondern lässt ein Modul, welches in einer höheren Programmiersprache (C, C++, C#, Java, Rust, ...) geschrieben wurde, über eine Toolchain (wie z.B. Emscripten) generieren.
Wenn man sich da nun also darauf aufbauende Technologien wie Blazor (für .NET), cheerpj (für Java) oder Yew (für Rust) anschaut, kann man von einer moderaten Lernkurve sprechen.
Vorteile von WASM gegenüber JavaScript können dann in der Lade- und Ausführungsgeschwindigkeit liegen. An sich ist die Idee hinter WASM aber eher, rechenintensive Aufgaben aus JavaScript auszulagern. Wie oben bereits erwähnt gibt es keine direkte Schnittstelle zum DOM.
Gibt es schon, z.B. flash player mit Actionscript.
Browser unterstützen halt nur JS und wasm(web Assembly). Du kannst ja nicht von jedem Browser-Hersteller verlangen dass er da dutzende Sprachen implementiert. Das wäre ein riesen aufwand. Dann würden die Browser auch noch mehr RAM schlucken als jetzt schon. Und bringt halt auch nicht wirklich was.
Ich glaube du verstehst den Sinn von web assembly auch garnicht. Ich denke das ist das Hauptproblem bei deinen Überlegungen.
Das ist eine Assembler Sprache, du kannst also deinen c++ code zu wasm kompilieren anstatt zu x86 assembly wie sonst. Du führst ja nie c++ code aus, du kompilierst ihn zuerst zu einer anderen Sprache.
Das ist ja normal dass man hochsprachen runter in eine assembly Sprache kompiliert. Kompilieren heißt nichts weiter als eine Programmiersprache in eine andere umzuwandeln. Assemblercode schreibt man sehr selten manuell. Du kompilierst einfach irgendwelchem Code zu Assembler.
C# blazor ist z.B. auch web Assembly
C, C++, rust, Go, C#, lua, Cobol, java, typescript, lisp, Pascal, perl, ruby, r, python, swift und viele weitere kannst du zu wasm Kompilieren und im Browser ausführen. Das ist ja gerade der Sinn.
Über Assembly wusste ich nur das es am Hardware nähsten ist/performant ist, direkt aber dafür nur für eine Architektur immer geschrieben.
Das stimmt so nicht. Am hardwarenächsten ist maschinencode. Assembly ist aber meist eine Art Zwischenschritt, noch für Menschen lesbar aber sehr hardware nah.
Nicht immer ist es nur für eine Architekttue, aber oftmals.
man könnte es doch mal versuchen mit einem Speziellen „GutefrageScript“ Browser für diese Sprache die man neu und besser entwickelt als JavaScript vor 20-30 Jahren.
Könnte man machen. Aber bringt wenig und ist ein mega Aufwand. Und Java-Script braucht man halt auch noch, außer man will dass der browser nur für gf funktioniert. Und außerdem muss man die Website dann auch in js und in gfscript Version anbieten.
JavaScript kann zur Dynamisierung von Webinhalten genutzt werden. Über das "Warum" in der Eingangsfrage kann ich nur vermuten, dass die Implementierung von zahlreichen weiteren Client-seitigen Sprachen einen Browser erheblich aufblähen würde. JavaScript ist sicherlich auch ein von Tradition und Standardisierung geprägter Einsatz, da u.a. auch sicherheits- sowie performanzrelevante Aspekte berücksichtigt werden müssen.
Der Vorteil von JavaScript liegt vor allem in der Fähigkeit auch asynchron arbeiten zu können. Das macht das Programmieren ein Stück komplexer, aber den Ablauf schneller, da Prozesse zeitparallel ablaufen (vereinfacht).
Gibt es, die meisten modernen Browser unterstützen auch WebAssembly (wasm). Und JavaScript wird auch kontinuierlich weiterentwickelt und ist an sich keine schlechte Sprachen. Dass JS keine strikte Typisierung hat stört mich nicht, mit TypeScript und co ist das kein Problem.
Allgemein gibt es keine "schlechten Programmiersprachen", nur schlechte Entwickler, die nicht wissen, welche Sprache sich für welchen Einsatzzweck am Besten eignet.
Du scheinst Dich aber sehr gut auszukennen. Wie hast Du Dir all das Fachwissen angeeignet?
Geh mal oben auf "Postfach" und schau in unseren Chat, da hatten ich das schonmal geschrieben
Entschuldige, aber leider habe ich den Chatverlauf gelöscht.
Du könntest auch PyScript verwenden.
Sonst wüsste ich nicht, welches mal noch benutzen kann. Ich meine JS ist auch eine gute Programmiersprache, die auch sehr beliebt für Frontend/Backend ist.
Ich kannte FlashPlayer nur aus meiner Zeit als 8 Jähriger „Web“ Gamer.
Bevor ich von Webentwicklung mitbekommen habe gab es schon Html5 als Ersatz also wusste auch nie ganz was der Player sein soll / wie er funtkioniert und kann.
ActionScript habe ich mal gehört aber nie damit befasst, wie die ganzen anderen Script arten.
Über Assembly wusste ich nur das es am Hardware nähsten ist/performant ist, direkt aber dafür nur für eine Architektur immer geschrieben.
Das nicht aus nullen und einser besteht aber dennoch katastrophal geschrieben wird.
Web Assembly wusste ich auch nur das es am performantesten ist/ für richtiges hochleistungs zeug.
ich erinnere mich das gelesen zu haben was du da ansprichst. C++ code in assembly code umwandeln und dann ausführen im browser.
TypeScript in Assembly weiss ich jetzt nicht ob man das wirklich, ich kann typescript und das ist eigentlich nur in Js umgewandelt und ist im Endeffekt nur Typisierunge Deko / Zwangsjacke für den Programmierer damit er sich an dinge hält mit paar netten features in der Ide/Konsole die einem viele fehler anzeigen.
bei grossen Projekten den überblick behalten usw. Privat oder für kleine Sachen aber überflüssig.
Vielleicht hab ich da falsche Vorstellungen aber man könnte es doch mal versuchen mit einem Speziellen „GutefrageScript“ Browser für diese Sprache die man neu und besser entwickelt als JavaScript vor 20-30 Jahren.
Das es gleich in Chrome’s neuem Update erhältlich wird ist sowieso unrealistisch oder das so eine Neue Sprache Javascript auch nur in den nächsten 5 Jahren 1% Konkurrenz macht.
Eher nach dem Motto einfach machen und gucken wie es sich entwickelt 10 Jahre später.
Dann bräuchte man bei so einer Sprache kein TypeScript-Extra mehr weil die Sprache das selbst kann und zb die Features aus Sass implementieren, dann bräuchte man nichtmehr in Css umwandeln weil der neuartige browser das auch von haus aus kann.
Ohne Fortschritt wären wir heute noch auf Spielaffe und würden uns ärgern weil der FlashPlayer nicht installiert ist.
Manche wollten letztes Jahr noch Python in den Browser holen, da wuede das extremst gehyped Python script aber da war klar das bringt wird, man hört auch nichts mehr davon.