© ecco/Shutterstock.com
Die besten Tricks und Kniffe mit nativer JavaScript-Syntax

Gewusst, wie!


In JavaScript herrscht kein Mangel an syntaktischem Zucker, doch die schiere Menge der Möglichkeiten macht es manchmal schwer, überhaupt zu erkennen, was das ein oder andere Feature überhaupt zu leisten im Stande ist – im Großen wie im Kleinen. Gerade auf der Ebene einfachster Ausdrücke und simpelster Einzeiler verbergen sich viele Möglichkeiten, die nicht jeder kennt!

Die Zeiten vor ECMAScript 6 bzw. ECMAScript 2015 müssen ausgesprochen finster gewesen sein. Zu diesem Eindruck komme ich jedenfalls, wenn ich mir die raketengleiche Entwicklung anschaue, die das Image von JavaScript seither genommen hat. War die Programmiersprache einst noch schwerpunktmäßig mit ihrer Aufgabe als Witzfigur befasst, ist sie mittlerweile unter ihresgleichen akzeptiert. Dabei hat sich eigentlich gar nicht so viel wirklich geändert. JavaScript ist immer noch eine primär imperative, dynamisch typisierte und ziemlich objektorientierte Sprache und seit der Witzfigur-Ära hat sich trotz vieler neuer Features an der Art und Weise, wie wir JS schreiben, nicht sonderlich viel getan. Nur ganz wenige Features haben die Standardherangehensweise an typische JS-Herausforderungen wirklich auf den Kopf gestellt. So löst etwa der JS-Mainstream, seitdem es async/await gibt, asynchrone Aufgaben auf eine gänzlich neue Weise (imperativ, statt funktional mit Promises oder chaotisch mit Callbacks). Selbst die Einführung von Klassen hat nicht wirklich einen vergleichbaren Effekt gehabt, denn wer „richtiges“ OOP wollte, konnte das auch zu Zeiten von ES3 haben – nur eben mit einer handgestrickten Implementierung des Klassenkonzepts.

Entscheidend sind auch die Kleinigkeiten

Was sagt es uns, wenn wir Kleinigkeiten wie eine einheitliche Klassensyntax oder Syntaxbonbons wie Destructuring und Arrow Functions ebenso abfeiern wie die Einführung des eigentlich viel revolutionäreren async/await? Es sagt uns, dass die sogenannten Kleinigkeiten wichtig sind. Es macht einen Unterschied, dass es eine Standardlösung für Klassen-OOP gibt, denn es reduziert mentalen Overhead – es gibt einfach ein Problem weniger zu lösen. Und es macht einen Unterschied, wenn wir mit Destructuring Objekte zerlegen können, denn es macht Code kompakter – es gibt weniger Zeilen, die geistigen Arbeitsspeicher belegen. Kleinigkeiten können den Unterschied machen. Und diese Kleinigkeiten müssen nicht immer offizielle Features sein. Wer hin und wieder auch mal in der physischen Welt Dinge (um)baut, weiß, dass großartige Werkzeuge und erlesen...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang