Wie wir gesehen haben, ist TypeScript nichts weiter als eine JavaScript-Erweiterung, die ein statisches Typsystem sowie Klassen und einige andere Features aus der näheren ECMAScript-Zukunft mit sich bringt. Das Release von TS kann man zum Anlass nehmen, um eine ganze Reihe von Fragen aufzuwerfen. Braucht man sowas? Wird sich das durchsetzen? Und warum macht sich Microsoft die Mühe? Die Beantwortung dieser Fragen ist natürlich zu einem gewissen Grad Kaffeesatzleserei, aber ich glaube ich habe eine halbwegs originelle Idee zu dem Ganzen. Also an die Arbeit!

Ist Typescript überhaupt ernst zu nehmen?

Die wichtigste Frage vorweg: hat Typescript überhaupt die Chance, jemals etwas anderes zu werden als ein Dart-artiges Ghetto? Aus zwei Gründen möchte ich das nicht ausschließen:

  1. Der Einsatz von TypeScript steht vor keiner großen Hürde
  2. Ich vermute, dass es eine echte Nachfrage nach den Features von TS gibt

Der erste Punkt ist ziemlich offensichtlich. Während Dart das Ziel hat, irgendwann eine eigene Laufzeitumgebung in jedem Browser zu haben (was nie passieren wird) und bis dahin JavaScript als Krücke benutzt, ist bei TypeScript das Endziel JavaScript selbst. Der Vergleich hinkt also ziemlich. Wie wir gesehen haben, produziert der TS-Compiler schönes normales JS, das in jedem Browser läuft und das man so ähnlich auch von Hand schreiben würde. Die Idee, mit TypeScript ein Programm zu schreiben, ist also erst mal nicht wesentlich verrückter, als das gleiche mit CoffeeScript zu machen. Und das ist immerhin die elftpopulärste Sprache auf Github. Dem Einsatz steht also an sich nichts im Wege.

Das mit der Nachfrage ist etwas komplizierter. Zwar bin ich selbst schon der Meinung, dass man als Webentwickler diesen ganzen Typsystem-Krams und auch einige ES6-Features nicht wirklich braucht, aber ich weiß auch, dass es da draußen sehr sehr viele Entwickler gibt, die das ganz anders sehen.

Webentwickler sind vom Mars, C#-Entwickler von der Venus

Als ich vor zwei Jahren angefangen habe, den HTML5-Erklärbären zu spielen, durfte ich vor allem Webentwicklern und -Designern die Wunder von HTML5 erklären. Mittlerweile habe ich vor allem das Vergnügen mit „normalen“ Softwareentwicklern, die ganzen Tag lang Java oder C# schreiben … und die stammen aus einem ganz anderen Universum als der durchschnittliche JS-Ninja.

Das Arbeitsgerät des typischen (Frontend-) Webentwicklers ist ein Texteditor, wahlweise nerdig (Vim, Ecmacs) oder etwas stylisher (Sublime Text, TextMate) aber eben ein Texteditor. Außerhalb von Frontend-Kreisen wird so etwas als vielleicht zum Schreiben von Einkaufszetteln geeignet angesehen, aber zum Programmieren nimmt man doch bitte eine richtig dicke IDE mit integriertem Debugger und toller Autovervollständigung und Refactoring-Tools und und und. Ein Frontend-Nerd erwartet von seinen Zielplattformen (Browsern) gar nicht erst, dass sie sich einheitlich oder überhaupt berechenbar verhalten und jongliert entsprechend mit einen ganzen Reihe von Workarounds, Polyfill-Scripten oder speziellen Techniken wie Progressive Enhancement oder Responsive Design. Ist man das nicht gewohnt, bekommt man sehr schnell den Eindruck, es herrsche einfach nur absolutes Chaos, verglichen mit z.B. der heilen Silverlight-Welt, in der alles (Sprache, API, IDE, Dokumentation) aus einer Hand kommt und entsprechend aufeinander abgestimmt ist. Während der Frontend-Entwickler so etwas wie $() für eine komplett ausreichende API hält, fragen sich andere, wie sie denn von diesem Ding eine Klasse ableiten können. Und zu guter letzt sind außerhalb der Webentwickler-Welt viele Dinge rund um Softwareentwicklung quasi-standardisiert. Man arbeitet objektorientiert (d.h. mit Klassen) in entweder Java, C# oder etwas, das den beiden eher ähnlich ist. Jedenfalls arbeitet man nicht mit so einem komischen Scheme-Abkömmling wie JavaScript oder so einem komplett eigenen Dingens wie CSS.

Es besteht einfach ein gewisser kultureller Unterschied. Und TypeScript ist, würde ich behaupten, Microsofts Versuch, dem Otto Normalsoftwareentwickler das Thema Webentwicklung bekömmlicher zu gestalten, den kulturellen Graben etwas überbrückbarer zu machen. Irgend etwas in der Richtung musste man bei Microsoft machen, denn bisher geriet die Kommunikation zum Thema HTML5 (und damit Webentwicklung) äußerst unglücklich.

Die Kommunikation Microsofts zu HTML5 und TypeScript

Wie wir ja alle wissen ist HTML5 das nächste große Ding. Das erzählen jedenfalls alle und auch Mircosoft hat fleißig an der Hypemaschine mitgekurbelt. So erklärte man 2011 HTML5 und JavaScript zu „first class citizens“ von Windows 8, kündigte für die Zukunft einen pluginfreien IE an und überhaupt sei HTML5 ja das nächste große Ding. Das alles mag ja soweit auch stimmen, was allerdings als Botschaft bei vielen Entwicklern angekommen ist, ist: bald gibt es auf Windows nur noch HTML5. Das wird so extrem sicher nicht der Fall sein, aber das ist eben das, was viele verstanden haben. Ich weiß das, weil die, die das so verstehen (oder deren Chefs es so verstehen) am Ende bei mir am Telefon oder im HTML5-Seminar auftauchen.

Diese Entwickler sehen sich dann, wenn sie zum ersten Mal so richtig mit Frontend-Entwicklung in Kontakt kommen, einem ganzen Haufen von Unglaublichkeiten ausgesetzt:

  • Nichts funktioniert in allen Browsern (und schon gar nicht HTML5)
  • Es gibt keine Tools und keine (mit der Realität in näherer Verbindung stehende) Dokumentation von „offizieller Seite“. Nicht mal eine definitive „offizielle Seite“ gibt es!
  • Die einzige zur Verfügung stehende Programmiersprache ist ein verbuggter Scheme-Abkömmling
  • Essentials wie Modulsysteme oder eine brauchbare DOM-API müssen mit komischen Open-Source-Libraries hingewürgt werden

Wenn man glaubte, in die goldene Zukunft aufzubrechen und sich stattdessen erst mal mit diesen Problemen konfrontiert sieht, fragt man sich natürlich, ob man da nicht gewaltig verschaukelt wurde. Damit kann man vielleicht einen News-Ticker scripten, aber eine richtige Webapp bauen, das kann doch gar nicht funktionieren! Natürlich kann das funktionieren und wenn es der Zeitplan hergibt, demonstriere ich das auch immer mit Erfolg, doch die Gelegenheit bietet sich eben nicht immer. Und dann gibt es Ärger. Und ich schätze mal, dass Microsoft selbst noch sehr häufiger Ärger abbekommt als ich.

Der Unmut entsteht nicht, weil die Web-Plattform/HTML5 zu nicht taugt, sondern weil der Problemkomplex Web-Frontend ein eigenes Universum darstellt – und wenn man darauf nicht vorbereitet ist, wird es eben schwer. Diese „Vorbereitung“ könnte einerseits natürlich darin bestehen, althergebrachte Vorstellungen und Herangehensweisen über Bord zu werfen und viel neues zu lernen … oder wenn der Berg nicht zum Propheten kommt, kommt eben der Prophet zum Berg. Heißt in diesem Fall: statisches Typsystem, Klassen und Module kommen nach JavaScript.

TypeScript wird von MS als „application scale“ betitelt, weil es „application scale“ für viele Entwickler einfach vorstellbarer macht. Braucht man als alteingesessener JavaScript-Ninja diese Vorstellbarmachung nicht mehr, braucht man TypeScript auch nicht.

Braucht man das Typsystem von Typescript? Braucht man die ES6-Features?

Nein, aber wie wir gesehen haben, geht es auch nicht darum. Ziel ist vielmehr, allen Entwicklern, die nicht auf der Web-Ecke kommen, einen gemütlicheren Zugang zur Webentwicklung zu verschaffen. TypeScript ist ein recht eleganter Weg, auf eigene Faust Dinge wie Klassen und ein statisches Typsystem umzusetzten und trotzdem ein Endprodukt zu schaffen (kompliliertes JavaScript) das sich wunderbar in die offene Web-Plattform einfügt.

Im Detail kann man natürlich darüber streiten, ob die Features von TS jetzt wirklich alle total überflüssig sind. Je nachdem wie man drauf ist, sind Klassen und native Module auch JS-Ninjas schon ganz wünschenswert oder total überflüssig. Vermutlich würden aber trotzdem die wenigsten freiwillig mit einem Entwickler zusammenarbeiten, der ohne seinen Babysitter-Compiler seine Datentypen nicht unter Kontrolle bringt. Das alles unterstelle ich jetzt einfach mal – wiedersprecht mir in den Kommentaren wenn ihr es anders seht.

Aber wenn jemand glaubt, Klassen, statische Typen und eine IDE wären eine total absolut unverhandelbare Grundvoraussetzung um vernünftig („application scale“) zu entwickeln, dann ist TypeScript sicher etwas, das ihm ein besseres Gefühl gibt. Und genau das scheint mir das Ziel zu sein, eine angenehmere Umgebung für Besucher aus dem anderen Universum.

Fazit

So wie ich das sehe, soll TypeScript alle jenen das Leben erleichtern die aus anderen Universen in den Webfrontend-Bereich vordringen. Dass hier unterstützende Maßnahmen durchaus gefordert sind, kann ich bestätigen und daher kann ich mir auch gut vorstellen, dass TypeScript eine rege Nutzerschaft finden wird. Ob nun eine eigene Extra-Programmiersprache die bestmögliche Hilfestellung ist, würde ich mal offen lassen. Theoretisch könnte eine Inflation an Projekten wie TypeScript die JavaScript-Welt fragmentieren und vielleicht wäre das ungut. Und an sich könnte man selbst als kulturgeschockter Entwickler schauen, wie denn der Rest der Welt mit der Webplattform klarkommt, statt es sich im vertrauteren TypeScript gemütlich zu machen. Könnte!

Ich persönlich habe jedenfalls nicht das Gefühl, TypeScript zu brauchen. Aber da es ja auch nicht für mich gemacht ist und nicht meine Probleme zu lösen versucht, passt das schon.