Mit JavaScript kann man unseren Autor jagen.DC Studio | shutterstock.com JavaScript blickt zwar auf eine lange Geschichte zurück, wurde im Jahr 1995 jedoch über einen Zeitraum von nur circa sieben Tagen entwickelt (was will man da schon erwarten?). Zunächst hieß die Programmiersprache LiveScript. Dann preschte der Java-Zug vorbei – und die Entwickler nutzten die Gelegenheit aufzuspringen. JavaScript war geboren (hatte aber nie wirklich etwas mit Java zu tun). In den Jahren danach revolutionierte JavaScript die Entwicklung von Webapplikationen und ist heute eine der meistgenutzten Coding-Sprachen weltweit. Und dennoch: Ich bin kein Fan. Eher im Gegenteil: JavaScript ist meiner Meinung nach keine Sprache, mit der man heute noch entwickeln sollte. TypeScript ist hingegen eine völlig andere Geschichte und vereint sämtliche Vorteile von JavaScript mit einem ausdrucksstarken und mächtigen Typsystem. Warum Entwickler angesichts dessen noch auf die Idee kommen, JavaScript TypeScript vorzuziehen, erschließt sich mir nicht. Schließlich können Developer mit TypeScript nicht nur in ihrem individuellen Tempo loslegen. Jeder JavaScript-Code ist zugleich TypeScript-Code. Als Entwickler müssen Sie also nicht einmal die Art und Weise ändern, wie sie Code schreiben. 7 schwache “Argumente” gegen TypeScript Umso unverständlicher ist es für mich, im Alltag mit diversen, fadenscheinigen Einwänden konfrontiert zu werden, die einige Developer regelmäßig gegen TypeScript vorbringen. Zum Beispiel die folgenden, die ich bei dieser Gelegenheit direkt entkräften werde. 1. “Diese ganzen Typen sind nur im Weg” Zugegebenermaßen kann es tatsächlich dazu kommen, dass das Typ-System Hürden aufwirft. Was dieses „Argument“ jedoch außer Acht lässt: Nicht selten muss irgendein armer Teufel sich daran versuchen, herauszufinden, was Sie sich gedacht haben, als Sie den Code vor sechs oder zwölf Monaten geschrieben haben. In der Regel sind Sie selbst übrigens dieser bedauernswerte Tropf. Das Typ-System ermöglicht Ihnen, ihre Intention mit Hilfe von Code klar und prägnant auszudrücken und diese für die gesamte Codebasis durchsetzen. Insbesondere bei Applikationen, an denen viele Entwickler arbeiten, ist das ein eklatanter Vorteil, der kognitive Energie, Zeit und damit Geld spart. 2. “JavaScript ist besser für Quick Prototyping geeignet” Ok, guter Punkt. Bedenken Sie dabei aber: In der Praxis kommt es leider selten vor, dass so ein Prototyp beiseitegelegt wird und anschließend die Arbeit an der „echten“ Applikation beginnt. Vielmehr entwickelt sich Letzteres meistens aus Ersterem. Was zur Folge hat, dass grundlegende Entscheidungen von qualitativ schlechter Ausprägung über die Lebensdauer des Projekts erhalten bleiben. Anders ausgedrückt: Schnell etwas zusammenschustern zu können, ist keine Tugend. 3. “JavaScript ist einsteigerfreundlich” Wenn Sie angehende Entwickler mit schlechten Angewohnheiten (siehe Punkt 1) ausstatten wollen, ist das sicher zutreffend. 4. “Die Tipparbeit nimmt überhand” Mal ganz abgesehen davon, dass kein Dev, der etwas auf sich hält, so ein Argument ernsthaft vorbringen sollte: Tastaturarbeit steht in jedem Fall an. Entweder während der Entwicklung oder eben im Nachgang, in Form von Wartungs-, Änderungs- und Reparaturarbeiten. Keinen klaren, präzisen Code schrieben zu wollen, weil es zu viel Arbeit ist, ist schlicht faul. 5. “Der TypeScript-Compiler findet nur kleine Fehler” Der TypeScript-Compiler findet Fehler, die sich bis zur Deployment-Phase halten können, wenn sie nicht durch Testing abgefangen werden. Ein Problem möglichst früh im Entwicklungszyklus zu erkennen, ist immer von Vorteil. 6. “Diese ganzen Typen erzeugen zu viele Fehler” Es handelt sich hierbei um eine Funktion: TypeScript ist präzise – und Präzision ist wünschenswert, wenn es darum geht, Software zu entwickeln. JavaScript hingegen hält nur zahllose Wege bereit, sich mit Mehrdeutigkeiten und Ungenauigkeiten in die Nesseln zu setzen. Das Ergebnis manifestiert sich in verbuggtem Code. 7. “Unit-Testing gewährleistet, dass mein Code ordnungsgemäß funktioniert” Unit-Testing und testgetriebene Entwicklung im Allgemeinen sind auf jeden Fall Konzepte, die adaptiert werden sollten. Insofern scheint dieser Einwand zunächst griffig. Bis man sich daran erinnert, dass Unit-Testing auch mit TypeScript geht. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
JavaScript können Sie vergessen!
Mit JavaScript kann man unseren Autor jagen.DC Studio | shutterstock.com JavaScript blickt zwar auf eine lange Geschichte zurück, wurde im Jahr 1995 jedoch über einen Zeitraum von nur circa sieben Tagen entwickelt (was will man da schon erwarten?). Zunächst hieß die Programmiersprache LiveScript. Dann preschte der Java-Zug vorbei – und die Entwickler nutzten die Gelegenheit aufzuspringen. JavaScript war geboren (hatte aber nie wirklich etwas mit Java zu tun). In den Jahren danach revolutionierte JavaScript die Entwicklung von Webapplikationen und ist heute eine der meistgenutzten Coding-Sprachen weltweit. Und dennoch: Ich bin kein Fan. Eher im Gegenteil: JavaScript ist meiner Meinung nach keine Sprache, mit der man heute noch entwickeln sollte. TypeScript ist hingegen eine völlig andere Geschichte und vereint sämtliche Vorteile von JavaScript mit einem ausdrucksstarken und mächtigen Typsystem. Warum Entwickler angesichts dessen noch auf die Idee kommen, JavaScript TypeScript vorzuziehen, erschließt sich mir nicht. Schließlich können Developer mit TypeScript nicht nur in ihrem individuellen Tempo loslegen. Jeder JavaScript-Code ist zugleich TypeScript-Code. Als Entwickler müssen Sie also nicht einmal die Art und Weise ändern, wie sie Code schreiben. 7 schwache “Argumente” gegen TypeScript Umso unverständlicher ist es für mich, im Alltag mit diversen, fadenscheinigen Einwänden konfrontiert zu werden, die einige Developer regelmäßig gegen TypeScript vorbringen. Zum Beispiel die folgenden, die ich bei dieser Gelegenheit direkt entkräften werde. 1. “Diese ganzen Typen sind nur im Weg” Zugegebenermaßen kann es tatsächlich dazu kommen, dass das Typ-System Hürden aufwirft. Was dieses „Argument“ jedoch außer Acht lässt: Nicht selten muss irgendein armer Teufel sich daran versuchen, herauszufinden, was Sie sich gedacht haben, als Sie den Code vor sechs oder zwölf Monaten geschrieben haben. In der Regel sind Sie selbst übrigens dieser bedauernswerte Tropf. Das Typ-System ermöglicht Ihnen, ihre Intention mit Hilfe von Code klar und prägnant auszudrücken und diese für die gesamte Codebasis durchsetzen. Insbesondere bei Applikationen, an denen viele Entwickler arbeiten, ist das ein eklatanter Vorteil, der kognitive Energie, Zeit und damit Geld spart. 2. “JavaScript ist besser für Quick Prototyping geeignet” Ok, guter Punkt. Bedenken Sie dabei aber: In der Praxis kommt es leider selten vor, dass so ein Prototyp beiseitegelegt wird und anschließend die Arbeit an der „echten“ Applikation beginnt. Vielmehr entwickelt sich Letzteres meistens aus Ersterem. Was zur Folge hat, dass grundlegende Entscheidungen von qualitativ schlechter Ausprägung über die Lebensdauer des Projekts erhalten bleiben. Anders ausgedrückt: Schnell etwas zusammenschustern zu können, ist keine Tugend. 3. “JavaScript ist einsteigerfreundlich” Wenn Sie angehende Entwickler mit schlechten Angewohnheiten (siehe Punkt 1) ausstatten wollen, ist das sicher zutreffend. 4. “Die Tipparbeit nimmt überhand” Mal ganz abgesehen davon, dass kein Dev, der etwas auf sich hält, so ein Argument ernsthaft vorbringen sollte: Tastaturarbeit steht in jedem Fall an. Entweder während der Entwicklung oder eben im Nachgang, in Form von Wartungs-, Änderungs- und Reparaturarbeiten. Keinen klaren, präzisen Code schrieben zu wollen, weil es zu viel Arbeit ist, ist schlicht faul. 5. “Der TypeScript-Compiler findet nur kleine Fehler” Der TypeScript-Compiler findet Fehler, die sich bis zur Deployment-Phase halten können, wenn sie nicht durch Testing abgefangen werden. Ein Problem möglichst früh im Entwicklungszyklus zu erkennen, ist immer von Vorteil. 6. “Diese ganzen Typen erzeugen zu viele Fehler” Es handelt sich hierbei um eine Funktion: TypeScript ist präzise – und Präzision ist wünschenswert, wenn es darum geht, Software zu entwickeln. JavaScript hingegen hält nur zahllose Wege bereit, sich mit Mehrdeutigkeiten und Ungenauigkeiten in die Nesseln zu setzen. Das Ergebnis manifestiert sich in verbuggtem Code. 7. “Unit-Testing gewährleistet, dass mein Code ordnungsgemäß funktioniert” Unit-Testing und testgetriebene Entwicklung im Allgemeinen sind auf jeden Fall Konzepte, die adaptiert werden sollten. Insofern scheint dieser Einwand zunächst griffig. Bis man sich daran erinnert, dass Unit-Testing auch mit TypeScript geht. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
JavaScript können Sie vergessen! Mit JavaScript kann man unseren Autor jagen.DC Studio | shutterstock.com JavaScript blickt zwar auf eine lange Geschichte zurück, wurde im Jahr 1995 jedoch über einen Zeitraum von nur circa sieben Tagen entwickelt (was will man da schon erwarten?). Zunächst hieß die Programmiersprache LiveScript. Dann preschte der Java-Zug vorbei – und die Entwickler nutzten die Gelegenheit aufzuspringen. JavaScript war geboren (hatte aber nie wirklich etwas mit Java zu tun). In den Jahren danach revolutionierte JavaScript die Entwicklung von Webapplikationen und ist heute eine der meistgenutzten Coding-Sprachen weltweit. Und dennoch: Ich bin kein Fan. Eher im Gegenteil: JavaScript ist meiner Meinung nach keine Sprache, mit der man heute noch entwickeln sollte. TypeScript ist hingegen eine völlig andere Geschichte und vereint sämtliche Vorteile von JavaScript mit einem ausdrucksstarken und mächtigen Typsystem. Warum Entwickler angesichts dessen noch auf die Idee kommen, JavaScript TypeScript vorzuziehen, erschließt sich mir nicht. Schließlich können Developer mit TypeScript nicht nur in ihrem individuellen Tempo loslegen. Jeder JavaScript-Code ist zugleich TypeScript-Code. Als Entwickler müssen Sie also nicht einmal die Art und Weise ändern, wie sie Code schreiben. 7 schwache “Argumente” gegen TypeScript Umso unverständlicher ist es für mich, im Alltag mit diversen, fadenscheinigen Einwänden konfrontiert zu werden, die einige Developer regelmäßig gegen TypeScript vorbringen. Zum Beispiel die folgenden, die ich bei dieser Gelegenheit direkt entkräften werde. 1. “Diese ganzen Typen sind nur im Weg” Zugegebenermaßen kann es tatsächlich dazu kommen, dass das Typ-System Hürden aufwirft. Was dieses „Argument“ jedoch außer Acht lässt: Nicht selten muss irgendein armer Teufel sich daran versuchen, herauszufinden, was Sie sich gedacht haben, als Sie den Code vor sechs oder zwölf Monaten geschrieben haben. In der Regel sind Sie selbst übrigens dieser bedauernswerte Tropf. Das Typ-System ermöglicht Ihnen, ihre Intention mit Hilfe von Code klar und prägnant auszudrücken und diese für die gesamte Codebasis durchsetzen. Insbesondere bei Applikationen, an denen viele Entwickler arbeiten, ist das ein eklatanter Vorteil, der kognitive Energie, Zeit und damit Geld spart. 2. “JavaScript ist besser für Quick Prototyping geeignet” Ok, guter Punkt. Bedenken Sie dabei aber: In der Praxis kommt es leider selten vor, dass so ein Prototyp beiseitegelegt wird und anschließend die Arbeit an der „echten“ Applikation beginnt. Vielmehr entwickelt sich Letzteres meistens aus Ersterem. Was zur Folge hat, dass grundlegende Entscheidungen von qualitativ schlechter Ausprägung über die Lebensdauer des Projekts erhalten bleiben. Anders ausgedrückt: Schnell etwas zusammenschustern zu können, ist keine Tugend. 3. “JavaScript ist einsteigerfreundlich” Wenn Sie angehende Entwickler mit schlechten Angewohnheiten (siehe Punkt 1) ausstatten wollen, ist das sicher zutreffend. 4. “Die Tipparbeit nimmt überhand” Mal ganz abgesehen davon, dass kein Dev, der etwas auf sich hält, so ein Argument ernsthaft vorbringen sollte: Tastaturarbeit steht in jedem Fall an. Entweder während der Entwicklung oder eben im Nachgang, in Form von Wartungs-, Änderungs- und Reparaturarbeiten. Keinen klaren, präzisen Code schrieben zu wollen, weil es zu viel Arbeit ist, ist schlicht faul. 5. “Der TypeScript-Compiler findet nur kleine Fehler” Der TypeScript-Compiler findet Fehler, die sich bis zur Deployment-Phase halten können, wenn sie nicht durch Testing abgefangen werden. Ein Problem möglichst früh im Entwicklungszyklus zu erkennen, ist immer von Vorteil. 6. “Diese ganzen Typen erzeugen zu viele Fehler” Es handelt sich hierbei um eine Funktion: TypeScript ist präzise – und Präzision ist wünschenswert, wenn es darum geht, Software zu entwickeln. JavaScript hingegen hält nur zahllose Wege bereit, sich mit Mehrdeutigkeiten und Ungenauigkeiten in die Nesseln zu setzen. Das Ergebnis manifestiert sich in verbuggtem Code. 7. “Unit-Testing gewährleistet, dass mein Code ordnungsgemäß funktioniert” Unit-Testing und testgetriebene Entwicklung im Allgemeinen sind auf jeden Fall Konzepte, die adaptiert werden sollten. Insofern scheint dieser Einwand zunächst griffig. Bis man sich daran erinnert, dass Unit-Testing auch mit TypeScript geht. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
