TypeScript (und JSDoc) vs. JavaScript

Einführung

Selbst im Jahr 2024, 12 Jahre nach der Veröffentlichung von TypeScript und 17 Jahre nach der Veröffentlichung von JSDoc, wissen viele Menschen immer noch nicht, warum sie ein statisches Typisierungstool in ihrem JavaScript-Projekt verwenden sollen, selbst nachdem es zum Standard in JavaScript/ NodeJs-Community.

In diesem Artikel erkläre ich, was TypeScript und JSDoc sind und warum Sie eines davon in Ihren Projekten verwenden sollten.

Was sie sind

TypeScript und JSDoc sind Tools, die JavaScript eine statische Typisierung ermöglichen. Unten finden Sie ein Beispiel für beide.

Wie Sie sehen können, ist TypeScript normalerweise weniger ausführlich als JSDoc, aber andererseits erfordert JSDoc keinen Build-Schritt, es funktioniert direkt mit Kommentaren im JavaScript-Code.

Typoskript

convert-string-to-int.ts (TYPESCRIPT-Datei!)

JSDoc

convert-string-to-int.js (JAVASCRIPT-Datei!)

Vorteile

Bevor ich über die Vorteile spreche, muss ich sagen: Egal wie viele Artikel Sie lesen oder wie gut diese Artikel sind, es gibt keine Möglichkeit zu beschreiben, wie viel besser die Entwicklererfahrung ist, wenn Sie mit statischer Typisierung arbeiten.

Niemandkann mit Worten oder Argumenten erklären, wie gut es ist, mit einer Codebasis zu arbeiten, die eine statische Typisierung anstelle einer untypisierten hat, nicht einmal der beste Dichter.

Ich werde, wie viele andere auch, versuchen, dieses Gefühl in Fakten und Daten zu übersetzen, aber ich stelle sicher, dass es nicht ausreicht, das genaue Gefühl zu beschreiben.

Vermeiden Sie Fehler in der Produktion

Dies ist ohne Zweifel der größte Vorteil des statischen Tippens. Es gibt nicht genug Worte, um zu beschreiben, wie hilfreich es ist, sowohl im Hinblick auf die Vermeidung von Nacharbeiten als auch auf das Sparen von Geld.

Um Dinge schnell zu liefern, vor allem Hotfixes, haben wir am Ende nicht die Zeit, Unit-Tests zu schreiben oder alle möglichen Abläufe einer Lösung zu testen. Wenn Sie mit reinem JavaScript arbeiten, gibt es keine Möglichkeit, Folgendes sicherzustellen:

• Alle Variablen, die Sie verwenden, sind vorhanden

• Alle von Ihnen verwendeten Variablen werden deklariert

• Sie verwenden zulässige Methoden für diesen Typ (z. B. Sie können „map“ in einer Zahlenvariablen verwenden)

• Wenn Sie äquivalente Variablen vergleichen (Sie sollten keine Zahl mit einem Array vergleichen)

Wenn Sie Ihren Code nicht besonders gut testen, müssen Sie erneut daran arbeiten, um einen Fehler zu beheben, und verbringen wertvolle Zeit mit etwas, das Sie vorher hätten abhusten können. Durch diese Dinge verursachte Fehler klingen vielleicht dumm, aber sie passieren am häufigsten.

Mit statischer Typisierung sorgen Sie für eine sicherere und schnellere Entwicklung, verringern die Menge an Fehlern in der Produktion erheblich und ermöglichen es dem Entwickler, sich nur auf das zu konzentrieren, was wirklich Wert liefert: die Geschäftslogik.

Keine unnötigen Tests

Bei den meisten Legacy-Projekten und Cloud-intensiven Projekten (Projekte, bei denen viele Ressourcen ausschließlich in der Cloud verfügbar sind) ist es schwierig, den Code lokal auszuführen, oder noch schlimmer, Sie müssen ihn bereitstellen, um ihn ohne Mocks ausführen zu können.

Der Prozess, Dinge lokal auszuführen, kann für die Entwickler sehr zeitaufwändig und anstrengend sein, und die Möglichkeit, ihn zu vermeiden, spart viele Ressourcen (Zeit, Geld, Geduld, Cloud-Ressourcen usw.).

Mit der statischen Typisierung ist der Code sehr vorhersehbar, und Sie können alles entwickeln, indem Sie wissen, was in jedem Teil des Codes passiert, und die Ausführung sehr einfach verfolgen, sodass Sie den Code nur einmal ausführen müssen dient dazu, nach Abschluss der Entwicklung wirklich zu testen, ob alles wie erwartet funktioniert.

Keine veralteten Dokumente

Wenn wir versuchen, eine Dokumentation über eine Funktion zu schreiben und Beispiele für Eingabe/Ausgabe hinzuzufügen, ist sie in den meisten Fällen (wenn nicht sogar in allen Fällen) im Handumdrehen veraltet. Entwickler denken nie daran, die Dokumente zu aktualisieren, und Scrum Master möchten nie genug Zeit dafür einplanen.

Bei statischer Typisierung ist der Code ein Live-Dokument. Es wird nie veraltet sein, denn wenn Entwickler den Code aktualisieren, aktualisieren sie auch die Dokumente.

Vermeiden Sie Probleme mit CommonJs/ES-Modulen

Nach der Implementierung von ES-Modulen in NodeJs begannen viele Bibliotheken mit der Migration auf diese neue Art des Codeschreibens, sodass ihre neuen Versionen (sicherer, zuverlässiger, leistungsfähiger und mit mehr Funktionen) nicht mit älteren Versionen von JavaScript kompatibel sind. wodurch Sie mit unsicheren veralteten Versionen stecken bleiben.

Raten Sie mal, was sowohl mit CommonJs- als auch mit ES-Modulen kompatibel ist, ohne dass Sie etwas an Ihrem Code ändern müssen (nur ein paar Zeilen in der Konfiguration)? Genau, TypeScript (leider denke ich, dass JSDoc diesen Vorteil nicht hat).

Automatische Vervollständigung und Vermeidung von Schreibfehlern

Anstatt sich jede Eigenschaft und Methode merken zu müssen, die etwas hat, können Sie die statische Eingabe und Ihre Lieblings-IDE für Sie erledigen!

Dies verkürzt die Entwicklungszeit, weil:

• Sie müssen nicht hin und her gehen, um die Eigenschaften von etwas abzufragen

• Sie können nur die ersten Buchstaben der Eigenschaft/Methode eingeben und die Eingabetaste drücken (oder den richtigen Vorschlag auswählen und dann die Eingabetaste drücken), dann wird die Eingabe automatisch vervollständigt

Es vermeidet auch das falsche Schreiben von Wörtern, was mehr Fehler in der Produktion verursacht, als es sollte.

Weniger Wissensverlust und keine Zeitverschwendung

Es kommt häufig vor, dass in einem Projekt verschiedene Entwickler bestimmte Teile des Codes schreiben, und was für die Person, die es schreibt, sehr offensichtlich erscheint, ist möglicherweise nicht für jeden intuitiv.

Wenn andere Entwickler an einer neuen Sache arbeiten, die von einer anderen Person geschrieben wurde, müssen sie einige Zeit damit verbringen, sie zu verstehen, bevor sie Änderungen vornehmen können. Durch die Verwendung statischer Typisierung können Entwickler VIEL Zeit sparen, indem sie die Werte der Variablen und den Ausführungsfluss verstehen.

Wenn der Entwickler, der diesen Code geschrieben hat, das Unternehmen/Team verlässt, wird dies keine so großen Auswirkungen haben, wie es hätte sein können, da sich die gesamte Dokumentation direkt auf dem Code befindet. Leicht zu finden und leicht zu verstehen.

Entwickler müssen sich auch weniger auf die Paarprogrammierung verlassen, um an einem Projekt arbeiten zu können. Wenn es gut geschrieben und einfach genug ist, können sie möglicherweise Verbesserungen/Änderungen vornehmen, ohne mit jemandem im Projekt zu sprechen, was absurd ist ihre Effizienz.

Modern und attraktiv für Entwickler

TypeScript ist laut der Stack Overflow Developer Survey eine der beliebtesten Sprachen. Hier sind die Ergebnisse von 4 aufeinanderfolgenden Jahren:

2020:

2021:

2022:

2023:

JSDoc ist in der Umfrage nicht vorhanden, daher liegen mir keinerlei Daten vor, die darauf schließen lassen, dass es sich um eine gute Option handelt. Das Einzige, was ich sagen kann, ist, dass HTMX es verwendet, aber es ist eine sehr einfache Bibliothek.

Andererseits können wir aus dieser Umfrage sagen, dass Entwickler in den letzten Jahren größtenteils TypeScript gegenüber JavaScript bevorzugt haben.

Flexibel

Sie müssen nicht alles eingeben. TypeScript und JSDoc können den Typ der meisten Dinge erraten, was es viel einfacher und weniger ausführlich macht als andere Sprachen wie Java oder C.

Für TypeScript verwenden Sie im schlimmsten Fall einfach „any“. „any“ ist der Joker-Typ, er repräsentiert alles, und aus diesem Grund sollten Sie es um jeden Preis vermeiden, aber wenn Sie wenig Zeit haben oder nicht durch den Mangel blockiert werden möchten eines Typs haben Sie diese Option.

Für JSDoc: Kommentieren Sie einfach nichts, es ist reines JavaScript!

Kein unnötiger Refactor mehr

Ich erkläre mehr darüber im Abschnitt „Es hat eine hohe Lernkurve“, aber ich werde hier einige Spoiler veröffentlichen.

Codebasen mit unverständlichem Code müssen umgestaltet werden, und Codebasen, die nicht über eine ordnungsgemäße Dokumentation verfügen (die unserer Meinung nach unmöglich zu pflegen ist, wenn sie vom Code getrennt ist), weisen eine größere Anzahl von Abschnitten auf, die unmöglich ohne sie zu verstehen sind viel Graben und Zeit zum Analysieren.

Refaktorierungen sollten nicht erfolgen, weil Ihr Code nicht verständlich ist, sondern aufgrund von Leistungsproblemen oder Änderungen in der Geschäftslogik. Das Gleiche zweimal tun zu müssen, ist für alle schlecht: die Entwickler, die Benutzer und die Investoren.

Mehr Unabhängigkeit für Entwickler

Bei langlebigen Projekten ist es üblich, dass mehrere Personen daran arbeiten, und es dauert immer einige Zeit (sowohl für den Neuling als auch für die erfahreneren Entwickler), bis Neulinge mit dieser Codebasis vertraut sind.

Mit statischen Typen können wir die benötigte Zeit VIEL verkürzen, da Entwickler zumindest die Grundlagen des Codes alleine verstehen können und nur die Hilfe anderer Entwickler benötigen, um komplexere Geschäftslogiken zu verstehen (sofern diese nicht in der dokumentiert sind). Code, aber das ist ein Thema für einen anderen Artikel).

Es macht es einfacher, Neulinge in die Projekte einzubeziehen, verkürzt ihre Lernkurve erheblich und ermöglicht es ihnen, mit geringerem Risiko, etwas kaputt zu machen, an dem Projekt zu arbeiten, was die Effizienz Ihres Teams als Ganzes erhöht.

Nachteile

Komplexerer Build-Schritt

Der einzige Nachteil von TypeScirpt besteht darin, dass sein Build-Schritt komplexer ist (denn seien wir ehrlich, heutzutage haben ALLE JavaScript-Projekte bereits einen Build-Schritt, sodass es nur ein wenig komplexer wird).

Möglicherweise benötigen Sie geeignete Plugins oder Adapter, um Ihren Build-Prozess mit TypeScript zu integrieren, aber heutzutage verfügen wir über eine Reihe ausgereifter und produktionsbereiter Bibliotheken, Plugins, Tools und alles, was Sie brauchen, damit es funktioniert.

Ich werde nicht lügen, es kann Ihnen beim ersten Mal einige Probleme bereiten, wie die meisten anderen Tools im JavaScript-Ökosystem, aber nicht genug, um die Profis zu überholen.

Wenn Sie sich dafür entscheiden, JSDoc anstelle von TypeScript zu verwenden, ist dieser einzige Nachteil von TypeScript verschwunden, aber ein neuer erscheint: JSDoc funktioniert nicht sehr gut mit komplexeren Typen, wenn Sie keine Klassen verwenden, um sie darzustellen.

Argumente entlarven

Es hat eine hohe Lernkurve

Statisches Tippen erfordert, dass Sie ein paar weitere Dinge schreiben, aber die Lernkurve hängt nicht von der zusätzlichen Zeichenfolge ab, die Sie schreiben müssen, sondern davon, wie schwierig es ist, damit zu arbeiten diese Codebasis.

Ohne statische Typisierung benötigen Sie VIEL mehr Kontext, um zu verstehen, was im Code passiert, welche Werte eine Variable hat und welche Geschäftslogik angewendet wird.

Sehen wir uns ein Beispiel an:

function processOrders(orders) {
 // Logic here
}

Können Sie allein anhand dieser Informationen bestimmen, welche Werte Bestellungen haben? Sie sagen vielleicht Es ist ein Array!, aber wissen Sie was? Sie liegen falsch. Bestellungen ist ein Objekt. Welche Eigenschaften hat es? Viel Glück dabei, mindestens eine Minute damit zu verbringen, sich den Code anzusehen, um es herauszufinden.

Sind die Eigenschaften optional? Existieren sie immer? Sind es Objekte, Arrays oder Strings? Verfügt ein anderes Mitglied Ihres Teams über dieses Wissen oder ist die Person, die diesen Code geschrieben hat, schon lange nicht mehr da?

Statisches Tippen allein reduziertdie Lernkurve um einen enormen Betrag.

Mit reinem JavaScript müsste jede Person, die an etwas im Zusammenhang mit Verarbeitungsaufträgen arbeitet, denselben Prozess durchlaufen:

• Sich selbst fragen, was Befehle sind

• Verbringen Sie viel Zeit mit der Logik des Prozesses und versuchen, es herauszufinden

• Wenn es ein bestimmtes Verhalten von Prozessaufträgen erfordert, fragen Sie wahrscheinlich andere Teammitglieder nach weiteren Details und investieren Sie auch ihre Zeit

Lass es uns in Zahlen ausdrücken, damit es mehr Spaß macht:

• Ein Team von 5 Leuten, von denen jeder 100.000 $/Jahr verdient

• Nehmen wir an, sie müssen einmal alle 6 Monate mit Prozessaufträgen arbeiten, genug Zeit, um bestimmte Details zu vergessen

• Sie verbringen 5 Minuten damit, ALLES herauszufinden, was sie brauchen (Ja, ich bin hier sehr, sehr optimistisch)

• Ein Projekt hat normalerweise Tausende oder zumindest Hunderte von Funktionen, die alle ProcessOrders ähneln, aber wir betrachten hier nur ein kleines Projekt mit nur 10 Funktionen.

• 5 Entwickler * 10 Minuten / Jahr * 10 Funktionen = 500 Minuten pro Jahr

Wenn jeder Entwickler 88 Cent pro Minute verdient, würde es 440 $ kosten, nur herauszufinden, was 10 Funktionen empfangen und zurückgeben. Dies ist unproduktive Zeit, die keinen Wert generiert, im BESTEN Fall eines fiktiven Szenarios, in dem Ihr magisches Projekt nur 10 Funktionen hat, und nicht in der realen Welt, in der ein Projekt Tausende davon hat.

Jetzt mit TypeScript:

interface Orders {
 ids: Array<number>
 skipTypes?: Array<string> // Skip orders if they have specific types
}

interface ProcessedOrders {
 total: number
 success: number // Amount of orders that were succesfully
 processed skipped: number // Amount of skipped orders based on input filters
}

function processOrders(orders: Orders): Promise<ProcessedOrders> {
  // Logic here
}

Ich weiß, dass dies eine schrecklich unintuitive Funktion ist, aber das passiert im Code. Das sollte nicht sein, aber es tut es, daher ist es besser, es zumindest dokumentieren zu lassen.

Im Gegensatz zur reinen JavaScript-Version haben Sie hier den gesamten Kontext, den Sie benötigen, um alles zu verstehen, was die Funktion empfängt und zurückgibt, ob optional oder nicht, und das Grundprinzip dessen, was die Funktion tut .

Nach all dem kann man immer noch über viele Dinge argumentieren, wie zum Beispiel Es ist ein Problem mit sauberem Code, nicht mit JavaScripts! oder Es ist ein Mangel an Dokumentation Problem, nicht mit JavaScripts Problem!,aber ich versichere Ihnen, dass all diese Dinge VERSCHIEDENE Probleme sind, die ja im Code vorkommen und die ich vielleicht in anderen Artikeln anspreche, aber nicht im Mittelpunkt dieses Artikels stehen.

Einige Bibliotheken unterstützen TypeScript nicht

Das ist die Magie von TypeScript: Sie brauchen Ihre Bibliotheken nicht, um TypeScript zu unterstützen.

Sie können die Bibliothek ohne Eingabe verwenden und sie wird genauso funktionieren. Da es jedoch schwieriger sein wird, mit einer reinen JavaScript-Bibliothek zu arbeiten (weil sie keine der in diesem Artikel genannten Vorteile bietet), sollten Sie dies wahrscheinlich in Betracht ziehen mit einem anderen.

Ich muss etwas Neues lernen

Ja. Wir als Entwickler müssenjeden Tag etwas Neues lernen. Es ist Teil unserer Arbeit. Wir sind hier, um technische Lösungen für Probleme zu entwickeln, als Referenz zu dienen und herauszufinden, wie wir die Probleme, mit denen wir konfrontiert sind, lösen können.

Etwas Neues zu lernen, das so viele Vorteile hat, ist eine Anstrengung, die die Zeit lohnenswert macht.

Abschluss

Nachdem man weiß, wie sehr statische Schreibwerkzeuge die Entwicklung unterstützen, ohne nennenswerte Nachteile dagegen zu haben, kann man nicht leugnen, wie vorteilhaft sie für alle sind: den Entwickler, die Benutzer und die Finanzen des Unternehmens.

Ich hoffe, dass dieser Artikel Ihnen hilft, es zu verstehen und Ihre Paare davon zu überzeugen, ihre Entwicklungserfahrungen zu verbessern.

Das obige ist der detaillierte Inhalt vonTypeScript (und JSDoc) vs. JavaScript. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!