Thomas Bandt

Über mich | Kontakt | Archiv

TypeScript: nice

Nachdem kurz nach der Veröffentlichung das Büro kollektiv angefangen hatte zu sabbern, habe ich mir heute dann auch mal Anders Hejlsberg' Präsentation seiner neuesten Kreation namens TypeScript angeschaut:

Ich muss dazu sagen, dass ich insbesondere in den vergangenen anderthalb Jahren in der Agentur - ohne es bewusst zu wollen - ganz massiv in die Entwicklung mit JavaScript reingerutscht bin. Es begann mit - rückblickend - ein bisschen jQuery für einen webbasierten Produktkonfigurator und gipfelte in einer komplett offline-fähigen und deshalb enorm JavaScript-lastigen mobilen HTML5-Applikation, die es inzwischen sogar mittels PhoneGap zur quasi-nativen Android- und iOS-App gebracht hat. Ich weiß also, was es bedeutet, in Projekten zu arbeiten, die mehr als nur ein bisschen JavaScript-Magic für das Hauptmenü beinhalten.

Und ich weiß auch, was die bisherige Entwicklung mit JavaScript in der Microsoft-Welt mit sich brachte - in meinen Augen schon eine ganze Menge Komfort. Visual Studio als IDE, gewürzt mit ReSharper für leidlich gutes IntelliSense, dazu ASP.NET MVC und Combres für Komprimierung und Bundeling der im Projekt bis zu 100 JavaScript-Dateien.

Alleine mit dem letzten Punkt war ich schon sehr zufrieden, kann man doch so arbeiten, wie man es auch mit "richtigen Sprachen" wie C# gewohnt ist: pro Klasse eine Datei. Der Output bestand dann trotzdem aus einer zusammengefassten .js-Datei, sozusagen dem Kompilat.

Einmal tief im Projekt drin, hat mir so die Entwicklung durchaus Spaß gemacht. Positiv ausgedrückt arrangiert man sich, mit etwas mehr Distanz könnte man es aber auch als Stockholm-Syndrom klassifizieren.

Denn die wirklichen Paintpoints sind mit den besten Werkzeugen nicht zu beseitigen, liegen sie doch in JavaScript selbst begründet. Durch die Dynamik der Sprache, die ihr auch zu vielen Vorteilen verhilft, entstehen während der Entwicklungszeit auch viele Probleme. Es gibt faktisch keine Klassen, keine Namespaces, Refactoring endet z.B. beim Umbenennen von Objekten ab einer bestimmten Komplexität letztlich doch immer bei Suchen & Ersetzen.

Lange Rede, kurzer Sinn: alles nicht so wirklich schön. Sobald man wieder mit einer typsicheren Sprache wie C# arbeitet, merkt man das auch ganz schnell.

Das hat man sich auch bei Microsoft gedacht und den Schöpfer von C# auf das Problem angesetzt. Sicher kein unkluger Schachzug, nachdem man sich nach Rohrkrepierern wie Silverlight nun mal der Realität um HTML5 und JavaScript stellen muss.

Herausgekommen ist dabei etwas, das im besten Fall auf breite Zustimmung über den kleinen Microsoft-Entwickler-Kosmos hinweg stoßen könnte.

Denn TypeScript ist ein Superset von JavaScript, das die gröbsten Mängel beseitigt und insbesondere ein statisches Typsystem, Klassen und Namespaces (Module) einführt. Und dabei keinerlei Insellösung schafft: denn heraus kommt "Plain JavaScript". Und last but not least: alles ist tatsächlich Open Source unter der Apache-2.0-Lizenz zu bekommen.

Meine größte Skepsis rührte vor der intensiven (ersten) Beschäftigung damit vor allem aus zwei Punkten: man ist "gelockt" in der Microsoft-Welt und stößt ein neues Teammitglied hinzu, ist es sehr unwahrscheinlich, dass es TypeScript beherrscht (schon gute JS-Entwickler sind ja kaum zu bekommen).

Doch beide Sachen sind unbegründet. Zum Einen erzeugt die tsc.exe ja echtes JavaScript. So lange man also nicht Tausendzeiler produziert, sondern seinen Code - wie in C# auch - sinnvoll organisiert und aufgliedert, entstehen viele kleine JS-Files, die sich erstens so auch gut debuggen, aber auch lesen und verstehen sowie ohne einen TypeScript-Compiler auf anderen Plattformen wiederverwenden lassen. Also selbst, wenn man einmal der Microsoft-Welt den Rücken kehrt und fortan nur noch am Mac mit VIM entwickelt - es ist nichts verloren.

Der andere Punkt: TypeScript ist quasi JavaScript, erweitert um ein paar echte Benefits. Wer also JS beherrscht, wird TypeScript vermutlich sofort verstehen und mögen. Auch lassen sich vorhandene Libraries wie jQuery, knockout.js usw. direkt integrieren und verwenden.

Bleibt zu hoffen, dass diese Vorteile bei allem üblichen Microsoft-Bashing auch zum Vorschein kommen, und sich TypeScript auch außerhalb des Microsoft-Ökosystems etablieren kann. Erste Anzeichen für eine Entwicklung dieser Art gibt es ja schon :-).

Ich bin jedenfalls sehr gespannt, wie es weitergeht.

PS: Visual Studio 2012 unterstützt zwar mit dem TypeScript-Plugin entsprechende Projekttemplates, der Compiler muss momentan aber noch von Hand angeworfen werden. Abhilfe schaffen die Web Essentials 2012 - hat man die installiert, genügt das Abspeichern des *.ts-Files, um das *.js-Gegenstück automatisch neu zu erzeugen.

Kommentare

  1. Ingo (Taichi) schrieb am Donnerstag, 4. Oktober 2012 16:44:00 Uhr:

    Danke für Combres, brauch gerade sowas.
  2. Michael schrieb am Samstag, 24. November 2012 08:50:00 Uhr:

    Um etwas für meine persönliche "Weiterbildung" zu tun möchte ich diese Frage los werden. Dazu zitiere ich erst mal folgende Aussage:

    "... Komprimierung und Bundeling der im Projekt bis zu 100 JavaScript-Dateien.
    Alleine mit dem letzten Punkt war ich schon sehr zufrieden, kann man doch so arbeiten, wie man es auch mit "richtigen Sprachen" wie C# gewohnt ist: pro Klasse eine Datei. Der Output bestand dann trotzdem aus einer zusammengefassten .js-Datei, sozusagen dem Kompilat."

    Was ist denn die Idee hinter dem Konzept "pro Klasse eine Datei" wenn diese einzelnen Bausteine letzten Endes doch miteinander verwoben sind und über Zusatztools in einem Paket verschnürt werden?

    Mein Entwicklungsschwerpunkt liegt bisher auf Object Pascal (Embarcadero Delphi, ehemals CodeGear, ehemals Borland) und den damit bereitgestellten Entwicklungsumgebungen. Die dortigen Strukturen haben kein Problem damit mehrere Klassen in eine Quelltext Datei zu legen. Gemäß dieser Erfahrung stelle ich es mir "wahnsinnig umständlich" vor, sich in einer Entwicklungsumgebung ständig von TabSheet zu TabSheet zu hangeln um ggf. an die einzelnen Baustellen zu gelangen.

    Freundliche Grüße
    Michael
  3. Thomas schrieb am Samstag, 24. November 2012 12:34:00 Uhr:

    Die Idee dahinter ist Übersichtlichkeit. Es ist im Gegenteil eher "wahnsinnig umständlich", innerhalb einer einzigen Datei navigieren zu müssen, die Code für womöglich völlig unterschiedliche Aufgaben beinhaltet, die miteinander gar nichts zu tun haben.
  4. Michael schrieb am Montag, 26. November 2012 18:02:00 Uhr:

    Hmm, dann ist der Grund kein "technischer" sondern eher einer, der durch die Technik der verwendeten Entwicklungsumgebung geprägt wird.

    Da ich in der Delphi IDE mit einem Handgriffe bei der Variablendeklaration und mit einem zweiten Handgriff bei der Klassen Deklaration bin, ist es für die Arbeitsweise, mit der ich "groß gezogen" wurde, kein Probem, wenn diese Inhalte sich in einer Datei bündeln.
    Im Dephi ist die Bündelung grob "zweckgebunden". Z.B. wäre alles, was mit der Erstellung und Bearbeitung von 2D Grafiken bzw. 2D Zeichenflächen zu tun hat, in einer Datei gebündelt.

    Da ich weder in meinem beruflichen noch in meinem privaten Umfeld mit großen, auf Web Technologien basierenden, Projekten zu tun hatte, ist die Problematik, wie sie hier beschrieben wurde für mich einfach noch nie gegeben gewesen.
    Mal sehen wo mich meine Selbstversuche hintreiben und ob ich diesen organisatorischen Hintergedanken auf für mich "entdecken" werde oder sogar muss ;-).
  5. Thomas schrieb am Montag, 26. November 2012 20:03:00 Uhr:

    In JavaScript ist es übrigens auch durchaus üblich, alles in sehr wenige, große Dateien zu packen - einfach weil das Bundeling bis vor Kurzem noch nicht überall Usus war und zu viele Scripts zu viele HTTP-Requests beim Seitenaufruf erzeugen, was ihn enorm verlangsamen kann.


« Zurück  |  Weiter »