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?
4 Stimmen
Google Dart, Script#, CoffeeScript, JSX (beide verschiedene Implementierungen von JS), JavaScript Harmony usw. Siehe diesen Link für mehr github.com/jashkenas/coffee-script/wiki/
2 Stimmen
"Warum nur Javascript? Auf der Serverseite (Ihrer bevorzugten OS-Plattform) können wir einen DOM-Baum mit jeder Sprache manipulieren, sogar mit Fortran. Warum unterstützt die Client-Seite (die Browser-Plattform) nur Javascript?" Auf der Server-Seite können Sie installieren, was immer Sie wollen, aber ich kann Ihre Kunden nicht zwingen, zusätzliche Plugins/Addons zu installieren, auch wenn wir so viele Bugs und Sicherheitsprobleme mit Javascript haben, raten Sie mal, wie viele Bugs und Sicherheitsprobleme wir haben würden, wenn wir ein paar mehr hinzufügen?
6 Stimmen
@Peter Ich kann nicht erkennen, ob Ihr Argument ernst gemeint ist oder ein Witz. Es ist trivial einfach für die Leute, Plattformen zu installieren, wenn sie wollen. Wenn eine Alternative zu Javascript verfügbar wäre und gut funktionieren würde, dann würden kommerzielle Anbieter von den Nutzern verlangen, dass sie das herunterladen, was für die Ausführung benötigt wird - so wie sie es schon immer mit Flash und eine Zeit lang auch mit Silverlight getan haben. Von all den Gründen, warum es auf der Client-Seite keine Alternativen geben könnte, ist die Schwierigkeit, sicherzustellen, dass die Nutzer über die eigene Plattform verfügen, keiner von ihnen von Bedeutung.
1 Stimmen
@ely: Und es ist gut ausgegangen? Blitzlicht? Java-Applets? Silverlight? Ich hatte noch nicht einmal eine Instanz von Silverlight installiert.
0 Stimmen
@SebastianMach Ja, diese Laufzeiten von Drittanbietern haben sehr gut funktioniert und zu einer großen Markteroberung und zu Gewinnen für ihre Mutterunternehmen geführt. Ich würde sogar sagen, dass DRM-Tech wahrscheinlich das erfolgreichste (aus Unternehmenssicht) Laufzeit-Framework ist, und seine Präsenz ist jetzt größer denn je, im Browser und anderswo. Eine andere Sache, die man bei dieser Argumentation bedenken sollte, ist, dass jeder eine Browser-Laufzeitumgebung zur Manipulation des DOM erstellen kann. Es hat sich einfach nicht gelohnt, dies mit einer anderen Sprachvariante zu tun. Javascript hat die Landnahme nur zufällig gewonnen.
0 Stimmen
@ely: Ja, die Eigentümer könnten durch ihre Laufzeiten bezahlt werden. Aber hat sich Flash für die kleinen Ziegel und Mörtel bezahlt gemacht? Diese Websites waren teuer, von Suchmaschinen nicht indizierbar und heutzutage oft genug einfach kaputt. Wenn selbst Nicht-IT-Leute in meinem sozialen Umfeld sich beschweren "igitt, Flash, ..., na ja, dann suche ich mir eben ein anderes", dann ist es wohl nicht die richtige Technik für den alten Laden.