Wie hat mich Typescript enttäuscht und ist es das wert?

Bevor ich anfange, möchte ich erwähnen, dass ich ein TypeScript-Fan bin. Dies ist meine Hauptprogrammiersprache für Front-End-Projekte in React und für alle Back-End-Arbeiten, die ich in Node mache. Ich bin komplett für Typescript, aber es gibt Momente, die mich stören und über die ich diesen Artikel erzählen wollte.

Ich habe in den letzten drei Jahren für viele verschiedene Unternehmen ausschließlich über TypeScript geschrieben. Meiner Meinung nach macht TypeScript also zumindest etwas richtig oder schließt bestimmte Anforderungen.

Trotz seiner Unzulänglichkeiten ist TypeScript in das Mainstream-Entwicklungs-Frontend eingestiegen und belegt laut dem HackerRank-Kompetenzbericht den siebten Platz in der Liste der beliebtesten Programmiersprachen.

Jedes Entwicklerteam, egal ob groß oder klein, das in TypeScript schreibt oder nicht, ist aus Sicherheitsgründen immer die Mühe wert:

• Stellen Sie sicher, dass gut geschriebene Komponententests so viel Code wie möglich in der Produktion abdecken.
• Verwenden Sie die Paarprogrammierung: Ein zusätzliches Paar Augen hilft dabei, schwerwiegendere Dinge als nur Syntaxfehler zu erkennen
• Erstellen Sie qualitativ einen Codeüberprüfungsprozess und identifizieren Sie Fehler, die der Computer nicht finden kann
• Verwenden Sie Linter - wie zB Eslint

Obwohl TypeScript zusätzlich eine zusätzliche Sicherheitsstufe hinzufügt, liegt es meiner Meinung nach in dieser Hinsicht weit hinter anderen Sprachen zurück. Ich werde erklären warum.

TypeScript ist kein zuverlässiges Typsystem

Ich denke, dies ist möglicherweise das Hauptproblem bei TypeScript, aber lassen Sie mich zunächst herausfinden, was zuverlässige und unzuverlässige Typsysteme sind .

Robustes Typensystem

Ein zuverlässiges Typensystem stellt sicher, dass Ihr Programm nicht in ungültige Zustände gerät. Wenn der statische Typ eines Ausdrucks beispielsweise eine Zeichenfolge ist und zur Laufzeit ausgewertet wird, erhalten Sie garantiert nur eine Zeichenfolge .

In einem zuverlässigen Typsystem werden Sie weder zur Kompilierungszeit noch zur Laufzeit in einer Situation sein, in der der Ausdruck nicht mit dem erwarteten Typ übereinstimmt.

Natürlich gibt es verschiedene Grade an Zuverlässigkeit sowie verschiedene Interpretationen von Zuverlässigkeit. TypeScript ist einigermaßen zuverlässig und fängt Tippfehler ab:

// Type 'string' is not assignable to type 'number' const increment = (i: number): number => { return i + "1"; } // Argument of type '"98765432"' is not assignable to parameter of type 'number'. const countdown: number = increment("98765432"); 

Unsicheres Typensystem

Maschinenschrift meldet absolut offen, dass 100% ige Zuverlässigkeit nicht sein Zweck ist. Sogar die "Nicht-Ziel" -Nummer 3 in der TypeScript -Liste "Nicht-Ziel" besagt eindeutig:

Ein zuverlässiges oder „nachweislich korrektes“ Typensystem zu haben, ist nicht unser Ziel. Stattdessen bemühen wir uns um ein Gleichgewicht zwischen Genauigkeit und Leistung.

Dies bedeutet, dass es keine Garantie dafür gibt, dass die Variable zur Laufzeit von einem bestimmten Typ ist. Ich kann dies anhand des folgenden, etwas erfundenen Beispiels veranschaulichen:

 interface A { x: number; } let a: A = {x: 3} let b: {x: number | string} = a; bx = "unsound"; let x: number = ax; // unsound axtoFixed(0); // WTF is it? 

Der obige Code funktioniert nicht, da bekannt ist, dass ax eine Zahl aus der Schnittstelle A ist. Leider verwandelt es sich nach ein paar Finten mit Neuzuweisung in einen String und dieser Code wird kompiliert, jedoch mit Fehlern zur Laufzeit.

Leider kompiliert dieser Ausdruck ohne Fehler:

 axtoFixed(0); 

Dass Zuverlässigkeit nicht das Ziel der Sprache ist, ist wahrscheinlich eines der größten Probleme von TypeScript. Ich bekomme zur Laufzeit immer wieder viele Laufzeitfehler, die der tsc- Compiler nicht abfängt , aber die der Compiler bemerkt hätte, wenn ein zuverlässiges Typsystem in TypeScript existiert hätte. TypeScript ist jetzt ein Fuß im Lager der "zuverlässigen" Sprachen und der andere Fuß im Lager der "unzuverlässigen". Dieser Ansatz mit halben Maßen basiert auf jedem Typ, den ich später erörtern werde.

Ich bin frustriert darüber, dass die Anzahl der Tests, die ich schreibe, mit dem Übergang zu TypeScript nicht abgenommen hat. Als ich gerade anfing, entschied ich fälschlicherweise, dass ich die lästige Routine reduzieren könnte, eine große Anzahl von Unit-Tests zu schreiben.

TypeScript stellt den aktuellen Stand der Dinge in Frage, indem es argumentiert, dass die Senkung der kognitiven Kosten bei der Verwendung von Typen wichtiger ist als die Zuverlässigkeit.

Ich verstehe, warum TypesScript einen solchen Pfad gewählt hat und es gibt eine Meinung, dass TypeScript nicht so beliebt wäre, wenn die Zuverlässigkeit des Typsystems zu 100% garantiert wäre. Diese Meinung hat sich nicht bewährt - die Dart-Sprache gewinnt zusam- men mit der weit verbreiteten Verwendung von Flutter rasch an Beliebtheit. Und es wird argumentiert, dass Typzuverlässigkeit das Ziel von Dart ist.

Die Unsicherheit und die verschiedenen Möglichkeiten, die TypeScript bietet, machen es weniger effizient und im Moment leider nur "besser als nichts" . Ich würde mich freuen, wenn mit zunehmender Beliebtheit von TypeScript mehr Compiler-Optionen verfügbar werden und erfahrene Benutzer nach 100% iger Zuverlässigkeit streben können.

TypeScript garantiert keine Typprüfung zur Laufzeit

Die Typprüfung zur Laufzeit ist nicht der Zweck von TypeScript, daher wird mein Wunsch wahrscheinlich niemals in Erfüllung gehen. Die Laufzeitüberprüfung ist beispielsweise hilfreich, wenn Sie mit JSON-Daten arbeiten, die von API-Aufrufen zurückgegeben wurden. Es wäre möglich, eine ganze Kategorie von Fehlern und viele Komponententests loszuwerden, wenn wir diese Prozesse auf der Ebene des Typsystems steuern könnten.

Da wir zur Laufzeit nichts garantieren können, kann dies leicht passieren:

 const getFullName = async (): string => { const person: AxiosResponse = await api(); //response.name.fullName may result in undefined at runtime return response.name.fullName } 

Es gibt einige Hilfsbibliotheken wie io-ts , was großartig ist, aber das kann bedeuten, dass Sie Ihre Modelle duplizieren müssen.

Furchterregende Art irgendeine und strenge Wahl

Der Typ any bedeutet "any", und der Compiler ermöglicht die Operation oder Zuweisung einer Variablen dieses Typs.

TypeScript funktioniert gut für kleine Dinge, aber die Leute neigen dazu, den Typ auf etwas zu setzen, das länger als eine Minute dauert. Ich habe kürzlich an einem Angular-Projekt gearbeitet und eine Menge Code wie diesen gesehen:

 export class Person { public _id: any; public name: any; public icon: any; 

Mit TypeScript können Sie das Typsystem vergessen.

Sie können die Art von allem mit jedem brechen:

 ("oh my goodness" as any).ToFixed(1); // remember what I said about soundness? 

Die Option strict enthält die folgenden Compiler-Optionen, die alles zuverlässiger machen:

• --strictNullChecks
• --noImplicitAny
• --keinimpliziertesDies
• - immerStrict

Es gibt auch eine Regel für eslint @ typescript -eslint / no-explicit-any .

Das Verteilen von Code kann die Zuverlässigkeit Ihres Codes beeinträchtigen.

Fazit

Ich muss wiederholen, dass ich ein TypeScript-Fan bin und es in meiner täglichen Arbeit verwende, aber ich habe das Gefühl, dass es unvollkommen ist und der Rummel darum nicht ganz gerechtfertigt ist. Airbnb behauptet, TypeScript habe dazu beigetragen, 38% der Fehler zu vermeiden . Ich bin sehr skeptisch in Bezug auf den so genau angegebenen Prozentsatz. TypeScript verbessert oder kombiniert nicht alle vorhandenen Methoden für guten Code. Ich muss noch eine Menge Tests schreiben. Man könnte argumentieren, dass ich mehr Code schreibe, also muss ich so viele Tests schreiben. Ich bekomme immer wieder unerwartete Laufzeitfehler.

TypeScript bietet nur eine grundlegende Typprüfung, und die Tatsache, dass Zuverlässigkeit und Typprüfung zur Laufzeit nicht ihre Aufgabe sind, lässt TypeScript in der Welt der halben Sachen zwischen der besten Welt und der Welt, in der wir jetzt programmieren, zurück.

TypeScript ist großartig dank der guten Unterstützung von IDEs wie vscode, bei denen wir während des Druckvorgangs visuelles Feedback erhalten.


TypeScript-Fehler in vscode

TypeScript verbessert auch Refactoring- und Code-Breaking-Änderungen (z. B. Änderungen an Methodensignaturen), die beim Start des TypeScript-Compilers sofort erkannt werden.
TypeScript bietet eine gute Typprüfung und ist definitiv besser als keine Typprüfung oder einfache Eslint-Prüfung, aber ich bin der Meinung, dass TypeScript viel besser sein kann und die erforderlichen Compiler-Optionen diejenigen zufrieden stellen können, die mehr von der Sprache wollen.

Abonnieren Sie unseren Instagram-Entwickler