Umbenennung von neuem ECMAScript-2016-Feature sorgt für Diskussion in der Community

Community oder Spezifikation: wer gibt die Ausrichtung von JavaScript an?
Keine Kommentare

Gerade einmal zwei neue Features bringt die für dieses Jahr geplante Veröffentlichung von ECMAScript 2016 mit sich: den Exponention Operator und Array.prototype.includes. Gerade letzteres sorgte in der Community jedoch für einige Aufregung, denn ursprünglich hieß die Methode Array.prototype.contains – und überschnitt sich so mit der Benennung einer Methode in der MooTools-Library.

Da stellt sich natürlich die Frage, ob eine einzelne Library (beziehungsweise die Community) die Richtung der Sprache treiben darf oder ob nicht lieber die Entscheidungsgewalt bei den Entwicklern der Sprachspezifikation liegen sollte und sich entsprechende Tools der Feature-Benennung der Spezifikation beugen müssen. Wenig verwunderlich ist, dass es dazu innerhalb der Community bereits einige Diskussion gibt. So zeigen etwa Tim Severin und Moritz Kröger, was sie von der Entscheidung des TC39-Komittees zur Umbenennung von Array.prototype.contains halten.

Nur zwei neue Features für ECMAScript 2016

Mit der Veröffentlichung von ECMAScript 2015 im vergangen Jahr wurden dem JavaScript-Standard zahlreiche neue Features spendiert. Dass es für die diesjährige Version gerade einmal zwei neue Features geben wird, sorgte bei einigen Mitgliedern der JavaScript-Community darum für einige Überraschung, immerhin hatte man zumindest auch auf die Einführung des Async-Functions-Features gehofft. Gleichzeitig freut man sich jedoch, dass Entwickler so die Chance haben, sich schneller auf die Neuerungen von ECMAScript 2016 einzustellen.

Lesen Sie mehr zu den neuen Features in ECMAScript 2016

Dass es nur wenige neue Features in die neue Sprachversion geschafft haben, ermöglicht Entwicklern jedoch den Fokus auf ein anderes Problem: die Umbenennung von Array.prototype.contains zu Array.prototype.includes. So galt der ursprüngliche Name als nicht-webkompatibel, weil er sich mit einer Benennung innerhalb der JavaScript-Library MooTools überschnitten hat und so dafür hätte sorgen können, dass zahlreiche Websites nicht mehr korrekt angezeigt werden.

Spezifikation vs. Library

Was zwar auf den ersten Blick logisch klingt, provoziert bei näherer Betrachtung allerdings eine Grundsatzfrage: Darf eine Library die Ausrichtung einer ganzen Programmiersprache vorgeben oder sollten nicht eher die Library-Entwickler notwendige Änderungen vornehmen, um sich an die Sprache anzupassen?

Umbenennung – nein, danke!

JavaScript ist eigentlich eine leicht zu verstehende und flexible Sprache und eignet sich genau deshalb, so erklärt Tim Severin, als erste oder zweite Programmiersprache. Wer allerdings mehr als eine Sprache beherrscht, dem dürfte bekannt sein, dass die Programmierwelt keine einheitliche Vorgehensweise hat, um zu überprüfen, ob ein Array-Item oder Substring bereits in einem Array oder String existiert.

So nutzen Java und C# zum Beispiel .contains(), während Ruby .include() verwendet. Nochmal anders sieht es etwa in PHP (in_array() oder strstr()) oder Python (in-Operator) aus.

JavaScript Days 2019

JavaScript Testing in der Praxis (Teil 1 + 2)

mit Dominik Ehrenberg (Crosscan) und Sebastian Springer (MaibornWolff)

Fortgeschrittene schwarze Magie in TypeScript

mit Peter Kröner (‚Webtechnologie-Erklärbär‘)

Im Gegensatz dazu nutzen bei JavaScript fast alle der beliebtesten Frameworks und Libraries .contains(). Während sich Entwickler mit ihrer Arbeit in anderen Programmiersprachen meist auf eine bestimmte Version konzentrieren können ohne nennenswerte Breaking Changes zu provozieren, sieht die Sache im Web – und damit bei JavaScript – ganz anders aus. So sind Deprecations und Breaking Changes hier ein großes Problem, das in vielen nicht mehr korrekt funktionieren Websites resultieren kann, und jede Entscheidung, die die Sprachentwickler machen, ist dauerhaft.

Andererseits darf man nicht vergessen, dass es unzählige JavaScript-Libraries und -Frameworks gibt und fast täglich neue Tools aus dem Boden gestampft und als eierlegende Wollmilchsau verkauft werden. Genau diese Vielfalt sorgt dafür, dass man den gelegentlichen Breaking Changes nicht aus dem Weg gehen kann, meint Severin:

with the diversity of existing libraries, breaking changes will occur.

Problematisch sieht Severin auch die daraus resultierende Inkonsistenz: Fängt man an, Designentscheidung auf Basis der Befindlichkeit einer Library zu machen, könnte das in Zukunft zu unzähligen schlechten – und nicht behebbaren – Designentscheidungen führen, wenn die auch nur ein Prozent des Webs brechen könnten. Darum plädiert Severin dafür, dass das TC39 den Standard so hoch wie möglich halten sollte, um JavaScript möglichst zukunftssicher zu gestalten:

Choosing between breaking 1% of the web using a poorly designed library vs. focus on the future and durability of the language, I’d rather choose the latter.

Don’t break the web!

Von jeher spielte Accessibility im Web eine große Rolle. So funktionieren Websites, die in alten Standards geschrieben wurden, auch heute noch – wenn auch vielleicht nicht so gut, wie eine mit aktuellen Standards erstellte Seite. Vor allem in den vergangenen Jahren wurde JavaScript dafür immer mehr zu einer Notwendigkeit, und viele Entwickler haben sich notgedrungen für das Erlernen der Sprache entschieden.

Allerdings war JavaScript, so beschreibt Moritz Kröger, lange Zeit nicht so Feature-reich wie heutzutage. Tatsächlich sind viele der mit ECMAScript 2015 eingeführten Features mehr ein syntaktisches Sahnehäubchen als tatsächliche Notwendigkeit – selbst wenn sie vor allem für eine bessere Abwärtskompatibilität sorgen sollen. Gleichzeitig sorgten die zahlreichen Libraries und Frameworks dafür, dass Lücken, die durch das Fehlen entsprechender Features in JavaScript selbst entstanden, geschlossen wurden. Naturgemäß waren hier einige Libraries erfolgreicher als andere, trotzdem trugen sie langfristig zur Gestaltung des Webs und der Sprachspezifikation bei.

Viele der neuen ECMAScript-Features sind darum im Prinzip nur die Antwort auf das, was die Libraries bereits lange vor der Aufnahme der entsprechenden Features als Funktionalität zur Verfügung stellten. Darum, so denkt Kröger, ist es durchaus sinnvoll, diesen Umstand beim Erstellen eines neuen JavaScript-Features für die Sprachspezifikation zu bedenken und – falls nötig – Umbenennungen vorzunehmen, um die Kompatibilität für bestehende Funktionalitäten nicht zu gefährden:

we shouldn’t start to break the web just because of naming preferences. Consistency matters, but keeping the web accessible does more.

Gleichzeitig muss sich das TC39 Komitee über die Ausrichtung der Sprachspezifikation klar werden. Der Fokus sollte hierbei auf dem Fixen von echten Mängeln in der Sprache liegen und nicht, so erklärt Kröger, „[in] adopting more syntactic sugar from other languages.“

Keine eindeutige Lösung

Eines wird bei der Betrachtung der Frage deutlich: eine einheitliche Meinung dazu, ob eine Library die Ausrichtung der Sprachspezifikation lenken darf, gibt es nicht. Beide Seiten bieten gute Argumente dafür bzw. dagegen. Eine Sache, die dabei jedoch außer Acht gelassen wurde, ist die Relevanz der betroffenen Library – und die ist, glaubt man den Kommentaren zum Artikel von Severin und Kröger, eher fraglich.

So sind sich die meisten der Kommentatoren darüber einig, dass die MooTools-Library längst nicht mehr so beliebt ist, wie zu vergangenen Zeiten und deswegen bei einer Überschneidung mit den Naming-Conventions in JavaScript deutlich weniger Chaos anrichten dürfte, als Überschneidungen mit anderen Libraries oder Frameworks. So wäre zum Beispiel eine Überschneidung mit jQuery eine deutlich größere Katastrophe, die man lieber vermeiden sollte.

Doch egal, welchen Standpunkt man letztendlich vertritt, eine für alle befriedigende Lösung dürfte es kaum geben – und einen eindeutigen Gewinner im Kampf der Richtungsgeber Community vs. Spezifikation ebenso wenig.

Aufmacherbild: Balance Concept. Quality vs Quantity von Shutterstock / Urheberrecht: RazvanDP

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -