Moderne Frontend-Entwicklung mit TypeScript

Ein Plädoyer für TypeScript — oder warum und wie Sie Ihre Frontend-Entwicklung auf die nächste Stufe bringen und sich selbst und der Welt dabei etwas Gutes tun können.

Welcher Frontendentwickler kennt das nicht: Man startet den Browser, um die zu entwickelnde Anwendung in der Vorschau zu testen — und nichts geht. Und das ist auch nicht der seltene Sonderfall, sondern eine Standardsituation. Man sitzt vor dem leeren Bildschirm: "Ach du schöne weiße Seite", geht einem durch den Kopf, "welch unerwartete Überraschung". Nach einem tiefen Seufzer öffnet man die Browserkonsole, um herauszufinden, wo das Problem liegt, und man sieht es auch sofort: undefined is not a function oder cannot read property ‘map’ of undefined erwarten einen am häufigsten. "Na vielen Dank, JavaScript", denkt man sich und etwas frustriert geht es zurück in die IDE der Wahl, um das Problem zu finden und zu beheben.

Muss der Arbeitsalltag wirklich so aussehen? Dem ist nicht so, und wir werden zeigen, dass sich die tagtägliche Arbeit mit einen Wechsel auf TypeScript erheblich erleichtern und verbessern lässt. Am Ende dieses Blogposts werden Sie nicht nur wissen, welche Probleme JavaScript im Jahr 2019 (immer noch) hat, sondern auch, welche davon durch TypeScript effektiv adressiert werden und wie einfach es ist, TypeScript in Ihren Projekten einzusetzen — so einfach nämlich, dass Sie noch heute damit beginnen werden.

Alle Meinungen basieren auf unseren Erfahrungen mit TypeScript bei Bright IT. Wir arbeiten tagtäglich mit relevanter produktionsbereiter Software, die wir meistens für mittlere und große Unternehmen entwicklen, und verstehen, dass "Hallo Welt" oder Greenfield-Projekte mindestens eine Größenordnung weniger bewegliche Teile aufweisen als alle kommerziell entwickelten und verwalteten Projekte. Es freut uns insofern, unsere Erfahrungen aus dem 'echten' Leben mit TypeScript zu teilen. Und nun geh es auch endlich los!

Ein Leben nach var that = this;

Es ist nicht zu leugnen, dass JavaScript dank der Arbeit von ECMA in der Entwicklung und Standardisierung der JavaScript-Funktionen einen großen Schritt nach vorne gemacht hat. Modernes JavaScript sieht natürlich nicht mehr so aus wie früher. Viele schmerzhafte Probleme älterer Versionen wurden erfolgreich behoben, und es wurden viele neue Funktionen zur Verbesserung der Arbeit der Entwickler umgesetzt. Daher hat sich die Produktivität in den letzten Jahren auch durchaus verbessert. Dies alles war zwar entscheidend für den Fortschritt und den breiten Einsatz von JavaScript, es reicht aber beweitem nicht aus, um die Erwartungen echter Anwendungen zu erfüllen.

Von JavaScript-Skripts zu JavaScript-Apps

Für den größten Teil seines Lebens wurde JavaScript zum Erstellen einfacher Skripts oder Snippets eingesetzt, die man mehr oder weniger mit Copy-und-Paste im HTML-Code einfügt, um bereits vorhandenes Markup mit einem bestimmten Verhalten zu erweitern. Da diese Code-Snippets normalerweise klein waren, konnten man einfach über die paar Codezeilen drüberschauen, um eine Vorstellung davon zu bekommen, wie sie funktionieren, oder vielleicht ein paar Minuten länger, um den Code gründlich zu verstehen, wenn man das denn wollte.

In moderner Frontend-Entwicklung ist das jedoch keine Option mehr. Die ursprünglich einfachen Skripte haben sich zu voll ausgereiften Anwendungen weiterentwickelt, insbesondere mit dem Einsatz neuerer Frameworks und Bibliotheken, die den Prozess unterstützen und insgesamt einfacher machen als je zuvor. Single Page Applications (SPAs) sind das beste Beispiel für die Nutzung solcher Tools. SPAs sind—vereinfacht gesagt—Webanwendungen. Und zwar Webanwendungen die (so gewollt) vollständig in JavaScript erstellt sind. Sie verfügen über eigene Routing-, Status-, Persistenz- und Kommunikationswege gegenüber anderen Diensten. Und für bestimmte Anwendungsfälle sind sie auch wirklich fantastisch.

Das Problem mit dem Skriptteil

Vanilla JavaScript hat ein offensichtliches Skalierungsproblem. Es ist einfach nicht für eine ordnungsgemäße Anwendungsentwicklung geeignet. Im Gegensatz zu Skripten können Anwendungen nicht auf WORN-Weise (write once, read never) entwickelt werden. Sie werden normalerweise über Monate oder Jahre hinweg von mehreren Entwickler oder sogar ganzen Entwicklungsteams gewartet. Leider behebt JavaScript dabei selbst keines der Probleme, die durch einen solchen Workflow entstehen. Vielleicht (er)kennen Sie das Problem?

Aufgrund dieses Konflikts zwischen dem, was JavaScript im Vergleich zu dem, für das es heute eingesetzt wird, ursprünglich gemacht wurde, ist es schließlich unmöglich, selbst mittelgroße JavaScript-Anwendungen ohne (zumindest gelegentlichen) Schmerz und Kampf zu betreiben. Wenn Sie sich davor fürchten, Dateien zu verschieben, sie umzubenennen oder ein ganzen Verzeichnisbaum neu zu strukturieren, wissen Sie nur zu gut, wovon ich spreche. Wenn Sie darüber nachdenken, eine bestimmte Kernfunktion zu überarbeiten, wissen Sie genau, worauf ich hinaus will. In einem Setup muss etwas grundlegend falsch sein, wenn man die Reihenfolge oder Anzahl der Argumente in einer Funktion zum Beispiel nicht einfach ändern kann.

BetterJavaScript™

Die Design-Prinzipien von TypeScript zeigen deutlich die generelle Denkweise dahinter. Die Absicht von TypeScript besteht nicht darin, eine weitere neue Sprache zu definieren, die JavaScript ähnelt, sondern JavaScript mit Typen zu verbessern—und zwar so, dass sie mit der Funktionsweise von JavaScript übereinstimmt.

Puristen mögen sagen, dass einen dieser Ansatz dazu zwingt, TypeScript auf einem wenig optimalen Fundament aufzubauen—ein durchaus valides Argument. JavaScript ist nicht dafür bekannt, auf das beste Design unter allen Programmiersprachen zu bauen, und es ist wohl schwer, dagegen grundsätzlich zu argumentieren. Wenn man jedoch etwas pragmatischer an das Problem herangeht und dem von TypeScript eingeschlagenen Weg folgt, kann man einige grundlegende Probleme effektiv in Angriff nehmen, ohne sich dabei neue zu schaffen. Es ist jedoch nicht von der Hand zu weisen, das die Leistungsfähigkeit von TypeScript durch diesen Ansatz nicht unbegrenzt ist. Doch das Bestreben, den einen heiligen Gral zu finden, während man mit den alltäglichen oft fast lächerlichen Problemen von JavaScript zu kämpfen hat, ist wohl auch nicht der produktivste Weg. Verstehen Sie mich nicht falsch, ScalaJS, ReasonML oder WebAssembly sind großartig und treiben das Web auf jeden Fall voran—aber sie sind nicht so einfach zugänglich wie TypeScript oder nicht im entferntesten so leicht in existierende Systeme integrierbar wie TypeScript.

Zeit für Types(cript)

TypeScript löst viele der Probleme, die JavaScript mit sich bringt, aber vor allem löst es die wohl grundlegende Aufgabe, eine echte Anwendung zu betreiben. Selbst bei einer 'relaxed' Konfiguration gibt der TypeScript-Compiler wertvolle Rückmeldung, z. B. über das Aufrufen einer Funktion mit der falschen Anzahl an Argumenten (ja, Javascript macht das nämlich grundsätzlich nicht) oder das versehentliche Zuweisen von String auf Zahl (implizite Konvertierungen sind selbst in stark typisierten Sprachen wie Scala verpönt und man möchte wirklich niemals 1 zu "ein Glas voll Wasser" addieren).

Wenn Sie mit dem Feedback zufrieden sind, das Ihnen TypeScript liefert—und ich bin mir ziemlich sicher, dass sind Sie, und das eher früher als später—können Sie recht einfach weitere Features nutzen. Wenn Sie das tun, bedeutet das jedoch auch, dass TypeScript bei der Bewertung der Korrektheit des Codes strenger sein wird. Der Compiler lässt bestimmte Klassen von Fehlern beim Kompilieren dann nicht (mehr) durch. Das bedeutet, dass Sie möglicherweise auch gewarnt werden, wenn ein erwarteter Wert nicht vorhanden ist (und zwar überall), oder Sie vergessen haben, wirklich alle Cases in Ihrem Code sauber zu implementieren.

Bei all diesen Beispielen handelt es sich auch nicht um imaginäre, künstliche Probleme. Sie sind so reell, dass jeder JavaScript-Entwickler viele Male tagtäglich vor ihnen steht. Also warum sollte man TypeScript nicht diese Arbeit erledigen lassen?

Passt in jede Umgebung

Sie verfügen vielleicht bereits über hunderte, wenn nicht tausende von JavaScript-Dateien, die Sie unmöglich über Nacht in TypeScript konvertieren können—und das müssen Sie auch gar nicht. TypeScript kann schrittweise eingesetzt werden und dieser Ansatz funktioniert in der Praxis auch wirklich. Natürlich würden man am liebsten mit dem vollen Funktionsumfang von TypeScript durchstarten. In bestehenden Projekten ist das jedoch nicht wirklich realistisch, denn die laufende Fehlerbehebung und Weiterentwicklung kann man nicht einfach so stoppen, nur weil man den gesamten vorhandenen Code erst migrieren möchte.

Es geht auch nicht nur darum, dass bloss JavaScript- und TypeScript-Dateien in einem Projekt nebeneinander bestehen können. Das gesamte JavaScript-Ökosystem ist immens, die Anzahl an Bibliotheken und Tools ist riesig, und man möchte das alles wohl kaum aufgeben, nur weil die Sprache alleine besser ist. Dies ist ein weiterer Bereich, in dem TypeScript punkten kann, es ist nämlich so konzipiert, dass es in das gesamte Ökosystem passt und sich nicht als Gegenspieler behaupten will. Webpack, Babel, npm, React oder Vue.js—was auch immer Ihnen in den Sinn kommt. TypeScript macht das Arbeiten damit sogar noch besser, und das liegt ganz einfach an der zusätzlichen Typisierung, welche die automatische Vervollständigung in Ihrer IDE dazu bringt, endlich auch im Frontend-Teil zu funktionieren.

Weniger Hin und Zurück zwischen IDE und Browser

Bei der Frontend-Entwicklung geht es nicht um die Funktionalität, sondern hauptsächlich um den Benutzer. Natürlich ist die Funktionalität für den Abnehmer der Anwendung am wichtigsten und ohne sie ist eine Website lediglich ein simpler Online-Katalog oder eine Broschüre. Da jedoch viele Anforderungen oder Erwartungen—entweder von Benutzern oder aus dem Fachbereich—nicht funktionaler Natur sind, ist es schwierig, diese ohne einen Webbrowser zu testen. Idealerweise hat man stets eine Live-Vorschau. Wir haben unsere Versuche, Tests für „das Design sieht gut aus“ oder „die Animationen sind ansprechend und flüssig“ deshalb bereits vor einiger Zeit aufgegeben.

Kurze und schnelle Feedbackschleifen zwischen Code und Vorschau sind für eine erfolgreiche Frontend-Entwicklung am neuesten Stand der Technik absolut entscheidend. Und genau das kann man effizienter gestalten. Mit TypeScript kann man sich als Entwickler länger auf den Code konzentrieren, da der Compiler einen dazu auffordert, Probleme automatisch aufzuspüren, BEVOR man diese je manuell im Browser überprüfen muss. Ist das nicht toll?

Nur einen Schritt entfernt ...

Der größte Benefit von TypeScript, der es auch wirklich von anderen Verbesserungsvorschlägen an JavaScript in der Frontend-Entwicklung abhebt, ist, dass man meistens nur einen sehr kleinen Schritt von seiner Anwendung entfernt ist. Ja, in echten Projekten, nicht in irgendeinem 'Hallo Welt' Projekt.

Insbesondere nachdem Babel 7 erstklassige Unterstützung für TypeScript mit @babel/preset-typescript eingeführt hat, kann man TypeScript einfach in die vorhandene Build-Kette aufnehmen und die Erweiterung einer beliebigen Datei von ".js" in ".ts" ändern. Man füge noch die am wenigsten restriktive "tsconfig.json" hinzu (unbedingt "allowJs": true setzen) und schon ist man bereit. Soeben hat die Arbeit mit TypeScript begonnen!

Bright IT + TypeScript = <3

Wenn dieser Artikel irgendwie nach Werbung für TypeScript klingt, müssen wir zugeben, dass das nicht von der Hand zu weisen ist. Es handelt sich jedoch nicht um einen gesponserten Beitrag (übrigens ist TypeScript zu 100% Open Source, unterstützt von Microsoft)—es ist lediglich unsere ehrliche Meinung dazu, wie wir glauben, dass die Dinge getan werden sollten, und warum.

Wir arbeiten mit TypeScript seit 2017 und das mit Begeisterung. Mittlerweile ist es ein unumstrittener Standard in unserer Frontend-Entwicklung. Die IDE-Unterstützung ist großartig, die Toolchain JustWorks™ und wir hatten bisher keinerlei Probleme damit (nichts, was mit einer einfachen Google-Suche nicht gelöst werden konnte). Die Vorteile, die TypeScript mit sich bringt, sind immens. Sobald man es einmal selbst erlebt hat, setzte sich das Gefühl fest, dass in JavaScript etwas von Natur aus gefehlt hat.

Wir empfehlen, TypeScript auszuprobieren und die Frontend-Entwicklung damit auf eine neue Stufe zu heben. Und falls gewünscht, helfen wir Ihrem Unternehmen wie immer gerne dabei, auf den richtigen Pfad zu finden. Wenn Sie Fragen oder Zweifel haben, zögern Sie nicht, sich an uns zu wenden.

Und noch ein letzter Kommentar. Unsere Kollegen, die hauptsächlich mit Scala arbeiten, sind jetzt viel öfter daran interessiert, auch mal in den Frontend-Code zu wechseln und einen Beitrag zu leisten. Ist das nicht ein Zeichen dafür, dass an TypeScript etwas dran ist? Probieren Sie es selbst aus. Undefined is not a function, das passiert Ihnen nie wieder.