Erstarken von proprietären Techniken, Teil 2

[molily]

Hallo zusammen,

Mitte letzten Jahres kritisierte ich die stille Weiterentwicklung der Netscape-JavaScript-Spezifikation durch die Mozilla Foundation.

Ich forderte damals, sie sollten doch, um Verwirrung zu vermeiden, diese Spezifikation unverändert lassen und ihre Änderungen JavaScript 1.6 nennen. Nun, dies geschah im November 2005: JavaScript 1.6. Das ist immerhin ehrlich, Mozilla ist damit der neue Herausgeber der proprietären JavaScript-Spezifikation und die JavaScript-Referenz im Mozilla Developer Center ist Gecko-spezifisch.

JavaScript 1.6 brachte nur einige Änderungen, vor allem neue Array-Methoden sowie eine kleine Syntaxerweiterung (for each). Firefox 2.0 führt nun JavaScript 1.7 ein, das mit weit mehr einschneidenden Erweiterungen einhergeht und sich immer grundlegender vom ECMAScript-Standard entfernt (siehe JavaScript und Webstandards).

Auch bei JavaScript 1.7 kann man sich darüber streiten, ob die Erweiterungen praktisch und nützlich sind - ich habe sie einmal durchgearbeitet und für mich sind sie keine Offenbarung. Sie stellen Alternativen dar, die in gewissen Fällen kürzere und elegantere Umseztungen ermöglichen (Brendan Eich zu Python-Ergänzungen für JavaScript). Die Dokumentation scheint mir noch unausgereift, sodass die Vorteile wahrscheinlich noch nicht ersichtlich werden.

Wie auch letztes Jahr ist zu vermuten, dass diese proprietären Erweiterungen keine Perspektiven haben. Die anderen Browser sind bei JavaScript 1.5 bzw. ECMAScript stehen geblieben und haben schon JavaScript 1.6 nicht mitgemacht. Es ist zu vermuten, dass diese Techniken im öffentlichen Web unbrauchbar bleiben. Selbst im homogenen Intranet setzt man zunehmend auf offene, standardisierte Technik, anstatt sich an einen Softwarehersteller und dessen proprietäre Formate zu binden.

Eine Weiterentwicklung von JavaScript in Form eines neuen ECMAScript-Standards ist sicher wünschenswert, die Erweiterungen sind wohl auch nur als Vorgeschmack auf JavaScript 2 bzw. ECMAScript Edition 4 gedacht. Brendan Eich, Erfinder von JavaScript und anscheinend Hauptentwickler der Erweiterungen, ist auch Mitglied der Arbeitsgruppe für ECMAScript (TC39-TG1). Leider tat sich dort trotz seines vermehrten Engagements noch nichts.

Mathias

[wahsaga]

hi,

Auch bei JavaScript 1.7 kann man sich darüber streiten, ob die Erweiterungen praktisch und nützlich sind - ich habe sie einmal durchgearbeitet und für mich sind sie keine Offenbarung. Sie stellen Alternativen dar, die in gewissen Fällen kürzere und elegantere Umseztungen ermöglichen [...]

Von dieser Eleganz und Verkürzung kann man ja nur dann profitieren, wenn man dann nicht wieder Workarounds für "den Rest" der Browser implementieren muss - also höchstens in einer definierten Umgebung wie bspw. einem Intranet.

Die Dokumentation scheint mir noch unausgereift, sodass die Vorteile wahrscheinlich noch nicht ersichtlich werden.

Dass die Implementation vor der sauberen Dokumentation erfolgt, ist ja ein gängiges Problem. Aber da kann ja noch nachgebessert werden.

Wie auch letztes Jahr ist zu vermuten, dass diese proprietären Erweiterungen keine Perspektiven haben. Die anderen Browser sind bei JavaScript 1.5 bzw. ECMAScript stehen geblieben und haben schon JavaScript 1.6 nicht mitgemacht.

Insbesondere bei den unterschiedlichen Aktualisierungszyklen hat man von solchen Neuerungen erst mal wenig.
Selbst wenn ein Opera oder Safari schnell mitziehen würden - die Weiterentwicklung des Internet Explorers vollzieht sich ja eher in Dekaden, als in Monaten. Selbst wenn Microsoft also einen fremden Quasi-Standard für implementierungswürdig hielte, wäre er aller Voraussicht nach erst in ferner Zukunft nutzbar.

Es ist zu vermuten, dass diese Techniken im öffentlichen Web unbrauchbar bleiben. Selbst im homogenen Intranet setzt man zunehmend auf offene, standardisierte Technik, anstatt sich an einen Softwarehersteller und dessen proprietäre Formate zu binden.

Für Spezialaufgaben, die in Javascript gelöst werden müssen/sollen, und die dabei performancekritisch sind, wären solche Erweiterungen/Neuerungen ggf. interessant (so sie denn auch hinsichtlich der Performance Verbesserungen brächten, und nicht nur das Coding etwas simplifizierten).

Eine Weiterentwicklung von JavaScript in Form eines neuen ECMAScript-Standards ist sicher wünschenswert, die Erweiterungen sind wohl auch nur als Vorgeschmack auf JavaScript 2 bzw. ECMAScript Edition 4 gedacht. Brendan Eich, Erfinder von JavaScript und anscheinend Hauptentwickler der Erweiterungen, ist auch Mitglied der Arbeitsgruppe für ECMAScript (TC39-TG1). Leider tat sich dort trotz seines vermehrten Engagements noch nichts.

Und bis sich "dort" etwas täte, ein neuer Standard ausführlich formuliert und abgesegnet wäre, würde wohl auch wieder ziemlich viel Zeit vergehen, und bis zu Implementierungen dann nochmal mehr.
In so fern fände ich einen "Alleingang" teilweise vertretbar - allerdings nur dann, wenn dadurch dann nicht wieder Inkompabilitäten zu zukünftigen Standards entstehen (blöd nur, dass diesbezüglich kaum jemand verlässilich in die Zulunft zu schauen vermag). Wenn ein solcher, vielleicht auch auf Grund von Problemen in diesen aktuellen Vor-Implementation, dann wieder gewisse Interfaces, Methoden etc. abweichend definieren würde - dann müssten die Geckos irgendwann wohl einen "Schnitt" machen, und man hätte hier wieder eine Bruchstelle, die "Browserweichen" erfordert, und damit letztendlich wieder zusätzlichen Aufwand.

gruß,
wahsaga