App-Entwicklung mit JavaScript, Teil 1: Vorsicht zerbrechlich?
JavaScript genießt nicht bei allen Entwicklern einen guten Ruf. Nicht ganz grundlos, denn die Sprache weist manche Stolperfallen und Unhandlichkeiten auf. Die Skriptsprache entwickelt sich jedoch ständig weiter. Richtig angewandt wird sie zu einem starken Werkzeug für Cross-Plattform-Entwicklung, mit dem Entwickler einen hohen Speed aufnehmen können.
- Christian Liebel
JavaScript genießt bei einigen Softwareentwicklern keinen guten Ruf. Nicht ganz grundlos, denn die Programmiersprache weist die ein oder andere Stolperfalle und Unhandlichkeit auf. Die dynamische Typisierung stößt manche klassische Anwendungsentwickler mit C++-, Java- oder .NET-Hintergrund vor den Kopf. JavaScript lässt sich jedoch extrem vielseitig programmieren, versierte Entwicklerteams können einen extrem hohen Speed aufnehmen, und die Sprache entwickelt sich stets weiter.
App-Entwicklung mit JavaScript
- Teil 1: Vorsicht zerbrechlich?
- Teil 2: Evolution einer Sprache
- Teil 3: Aber bitte mit Typen
- Teil 4: Eine universelle Sprache
JavaScript erblickte im Jahr 1995 erstmals das Licht der Welt – ursprünglich unter dem Namen LiveScript, später wurde es wohl aus Marketinggründen nach dem damals populär werdenden Java benannt. JavaScript hat mit dieser Sprache jedoch wenig zu tun, sondern wird stattdessen zur Umsetzung clientseitiger Dynamik auf Websites eingesetzt. Die schwach dynamisch typisierte Sprache rangiert regelmäßig unter den Top 10 des TIOBE-Index. Eine gewisse Magie scheint also von dieser Skriptsprache auszugehen, auch wenn die Meinungen darüber auseinandergehen.
Eine Sprache mit Stolperfallen
Manche klassische Anwendungsentwickler mit Java- oder .NET-Hintergrund verbinden mit JavaScript ein Spielzeug mit manchen Stolperfallen: Die dynamische Typisierung mit erzwungener Typumwandlung, das unrühmliche with-Statement und die (tendenziell) gefährliche eval-Funktion können zu einem instabilen Laufzeitverhalten führen. Gerne wird auch die Evaluation einiger Ausdrücke in JavaScript als Beispiel für dessen Inkonsistenz herangezogen. Auf den ersten Blick erscheinen einige Ergebnisse wenig sinnvoll und sorgen oft für Lacher. Raten Sie mit:
> [] + []
""
> true + true == true
false
> Array(16).join("wtf" - 2) + " Batman!";
"NaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaN Batman!"
Es darf in dieser Diskussion jedoch nicht vergessen werden, dass JavaScript ursprünglich zur clientseitigen Eingabevalidierung erfunden wurde – und nicht etwa, um damit Large-Scale Applications (LSA) zu implementieren. Zudem haben viele Entwickler ihre ersten Gehversuche mit der standardisierten JavaScript-Fassung ECMAScript 3 aus dem Jahr 1999 gemacht. Nachdem Version 4 sogar ausfiel, erschien erst zehn Jahre später ECMAScript 5. In dieser Fassung wurde etwa der Strict Mode eingeführt (Opt-In), der einige Fehlerquellen beseitigt und den Weg für spätere Fassungen von ECMAScript ebnete. Doch auch mit dieser Ausgabe bleiben einige Stolperfallen bestehen.
Keine Typen, hohe Verantwortung
Es bleibt also wie in allen Sprachen in der Verantwortung der Entwickler, die Details und auch die "bad parts" ihrer Programmiersprache genau zu kennen. Wenn ein Programmierteam die Sprache durchdrungen und die Schnittstellen sauber definiert hat, kann es eine gewaltige Geschwindigkeit aufnehmen: JavaScript lässt sich situativ entweder prozedural, objektorientiert oder funktional verwenden. Code kann wesentlich kürzer geschrieben werden. Das Fehlen von Typen vermeidet Type-Casts und andere Spagate, die man aus statisch typisierten Sprachen kennt.
Dank Single-Page-Application-Frameworks gilt das nicht nur für kleinere Prototypen, sondern auch für LSA. Und es gilt nicht nur für eine Plattform, sondern für all die Geräte, auf denen JavaScript ausgeführt werden kann: Das sind nicht nur Browser auf faktisch allen Plattformen, sondern auch die JavaScript-Ausführungsumgebung Node.js. Gekrönt wird das durch ausgezeichnete Debugging-Tools, zum Beispiel die Chrome Developer Tools: Hier sehen wir Call-Stacks, Breakpoints und Watches. Kein printf-Debugging oder Guesswork.
ECMAScript 5 war jedoch noch nicht das Ende der JavaScript-Evolution. Als Nächstes folgt mit ECMAScript 2015 eine der größten Umwälzungen von JavaScript aller Zeiten. Dieser Standard brachte viele Sprachkonstrukte ins Web, die dort schmerzlich vermisst wurden. Eine Skriptsprache wird erwachsen und nimmt es mit Java oder C# problemlos auf.
