App-Entwicklung mit JavaScript, Teil 1: Vorsicht zerbrechlich?

ÜberKreuz  –  5 Kommentare
Anzeige

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

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.

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.

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.

JavaScript-Debugging in Chrome: Kein Guesswork

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.

Das moderne JavaScript stelle ich kommende Woche vor.

Anzeige