© Maderla/Shutterstock.com
Von .NET zu TypeScript mit Node.js und Angular

Ein Umstieg für immer?


In den letzten 15 Jahren beherrschten Microservices Konferenzen und Artikel in Fachzeitschriften. Immer weniger große Monolithen oder native Desktopanwendungen wurden entwickelt, während der Wechsel zu Microbackends und die Verlagerung ins Web JavaScript und dem Framework Node.js viele neue Entwickler brachten. Mit TypeScript veröffentlichte Microsoft Anfang der 2010er-Jahre eine typsichere Variante – also höchste Zeit für einen Wechsel? Welche Gewohnheiten muss man aufgeben und welche neu erlernen?

Ein grundsätzlicher Paradigmenwechsel ist – egal wie gestaltet – immer ein zeitintensives und oft auch nervenraubendes Thema. Egal, ob es sich um eine neue Sprache, ein neues Framework oder ungewohnte Patterns handelt. Es gilt, viel zu lesen, auszuprobieren, hinzufallen und neu aufzustehen. Als .NET-Entwickler kann man auf ein Ökosystem zugreifen, das seit nahezu zwei Jahrzehnten existiert und in allen möglichen Bereichen optimiert wurde. Warum also nicht nur auf eine neue Sprache, sondern auch auf ein neues Framework, neue Werkzeuge und ungewohnte Patterns umsatteln? Bloß, weil es gerade angesagt und hip ist? Oder steckt vielleicht mehr dahinter?

Ja, auch ich habe diesen Wechsel zumindest teilweise und mit mehr und minder großem Erfolg durchlebt. Seit mittlerweile knapp 5 Jahren entwickle ich mobile Anwendungen oder Frontends ausschließlich als Angular/TypeScript-basierte Anwendungen. Seit knapp einem Jahr ist das Thema Node.js mit TypeScript im Back-end ein Thema meiner Arbeit. Es benötigt einige Zeit und auch etwas Selbstkritik, um sich auf diesen neuen Weg einzulassen. Natürlich wird das niemals ein harter Schnitt sein, sondern eher eine Koexistenz oder zusätzliche Alternative, je nach Sinnhaftigkeit in einem Projekt. Schaut man sich einige Zahlen und Studien aus den vergangenen Jahren an, wird schnell klar, dass JavaScript gegenüber C# (ganz zu schweigen von C++ oder C) eine viel weitere Verbreitung hat. Der Grund liegt ganz klar darin, dass moderne Anwendungen oft für das Web oder die mobile Nutzung entwickelt werden. All das basiert auf und funktioniert bestens mit JavaScript. Im aktuellen Stack Overflow Developer Survey 2020 [1] sprechen die Zahlen eine deutliche Sprache: 67,7 Prozent der Entwickler gaben an, mit JavaScript zu arbeiten – C# kam hier auf 31,4 Prozent, also weniger als die Hälfte. TypeScript lag mit 25,4 Prozent nur knapp dahinter und steht somit kurz davor, PHP einzuholen.

Die Webbranche, die noch vor weniger als 10 Jahren von PHP dominiert wurde, steht also davor, von einer von Microsoft mitbegründeten Sprache überholt zu werden? Natürlich kann man in diese Zahlen viel hineininterpretieren und es bleibt auch die Frage offen, welcher Entwickler wo sein Kreuzchen setzt. Einmal die Programmiersprache verwendet oder ein Tutorial ausprobiert und schon wählt man die entsprechende Sprache? Oder stecken zumindest mittelfristige Erfahrung und produktiver Einsatz dahinter? Fakt ist jedoch, dass auch die Frameworks .NET inkl. .NET Core in der Verbreitung nur noch knapp vor Node.js stehen. Demnach sprechen wir hier nicht nur vom Frontend, sondern inzwischen auch vom Backend, das von JavaScript beherrscht wird. Diese Tendenz ist bereits seit einigen Jahren zu beobachten. Denn Fakt ist natürlich auch, dass sich bei der Nutzung einer Sprache wie z. B. JavaScript oder TypeScript für das Frontend die Frage stellt, wieso nicht auch die gleiche Sprache für das Backend genutzt werden sollte. Performance- und funktionsseitig scheint Node.js schließlich nicht mehr sehr im Nachteil zu sein.

In diesem Artikel möchte ich Ihnen zeigen, wie so ein Umstieg gelingen kann, wo die unvermeidlichen Fallstricke lauern und was ich in den letzten Jahren als positiv und was als negativ erachtet habe.

Erstmal das Zuhause gemütlich machen

Das Zuhause eines jeden Entwicklers ist die Entwicklungsumgebung. Fast eineinhalb Jahrzehnte hieß mein Hauptsitz Visual Studio. Von 2005 bis 2019 wurde dieses Heim immer mehr perfektioniert, renoviert und so ausgestattet, dass ich sehr komfortabel meiner Arbeit nachgehen konnte. Die ersten Versuche und Projekte mit TypeScript und Angular unternahm ich ebenfalls in Visual Studio (damals in der Version 2015). Seitdem hat sich einiges bei der Unterstützung von TypeScript/JavaScript-Anwendungen und den Node.js-basierten Tools (worauf auch Angular basiert) getan. Aber zu dem Zeitpunkt war es gelinde gesagt mehr als nur frustrierend. Zeitweise arbeitete ich mit einem Editor und einer permanent geöffneten Konsole. Ging, machte aber auch nicht so wirklich viel Spaß. Also beschloss ich, auf das damals erst einige Monate alte Visual Studio Code umzusteigen – und siehe da, es wurde Licht! Ich habe meinen neuen (zunächst) Zweitwohnsitz gefunden. Anfangs eher als pragmatisch betrachtet, machten es tiefergehende Integrationen und Erweiterungen aus dem Marketplace unglaublich produktiv. Eine Erweiterung, die ich Umsteigern nahezu immer empfehle, ist C# to TypeScript von Adrian Wilczy´nski [2], gerade wenn man ggf. noch ein Backend oder zumindest Teile davon in der .NET/C#-Welt hat. DTOs/POCO-Objekte sind so mit einem Fingerschnips in die TypeScript-Welt konvertiert.

Wie muss man sich hierbei aber umstellen? Ganz klar, Visual Studio war auf die Entwicklung von .NET ausgelegt. Visual Studio Code ist im Prinzip eine allgemeingültige IDE, mit der sämtliche Programmiersprachen und Frameworks bedient werden können. Vorausgesetzt, sie sind von Haus aus unterstützt oder man installiert die richtigen Erweiterungen. Man merkt einfach, dass ein weitaus leichtgewichtigeres Konstrukt gebaut wurde, das sehr individuell angepasst werden kann. Genau diese Herangehensweise muss auch ein Entwickler verstehen, wenn er von Visual Studio kommt. Erst einmal ist das Ganze nur ein etwas besserer Editor.

Sich mit der Sprache ausdrücken

Eine neue Programmiersprache zu erlernen ist ähnlich dem Erlernen einer weiteren...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang