Die meisten Einsteiger tippen any, wenn ein Typ nicht sofort passt. Dabei schaltet genau das die Prüfung ab, die TypeScript leistet.

TypeScript erweitert JavaScript um statische Typen; der Compiler prüft die Typen und erzeugt daraus normales JavaScript. Wer ankommende Daten als any deklariert, verschenkt diesen Schutz vollständig.

🌐 Externe Daten aus dem Netz sind zur Laufzeit nicht typisiert. JSON ist das verbreitete Datenformat von Web-APIs: Objekte mit Schlüssel-Wert-Paaren, Listen, Zeichenketten, Zahlen sowie true, false und null. Das Backend eines anderen Anbieters kann jederzeit ein Feld weglassen, null statt einer Zahl liefern oder ein Objekt statt einer Liste schicken. Der Typ im eigenen Code weiß davon nichts.

🧩 any schaltet den Typprüfungspfad ab, unknown erzwingt ihn. Der Typ any akzeptiert jede Operation, auch solche, die zur Laufzeit scheitern. Der Typ unknown ist die typsichere Variante: Der Wert darf darin landen, aber jede Operation erfordert vorher eine Typprüfung (Narrowing, das schrittweise Einengen des Typs), sonst kompiliert der Code nicht.

🔒 Erst prüfen, dann typisieren – Schritt für Schritt. JSON.parse liefert in TypeScript any, das Ergebnis einer fetch-Abfrage muss ebenfalls selbst geprüft werden. Bewährt hat sich: Das Ergebnis sofort unknown zuzuweisen. Dann mit typeof primitive Werte prüfen, mit Array.isArray Listen erkennen und einzelne Felder gegen erwartete Typen vergleichen. Erst danach den Wert einem echten Typ wie User zuweisen.

any heißt nicht „irgendein Typ“, sondern „keine Prüfung mehr“. unknown heißt nicht „unbekannt und ungeeignet“, sondern „unbekannt und kontrolliert“.

📌 unknown statt any · Typprüfung mit Narrowing · JSON.parse liefert any

📚 Webentwicklung von Grund auf · Tag 6 von 30
#typescript #webdev #javascript

Viele Einsteiger schreiben einen Unit-Test – und der Test baut heimlich eine Datenbankverbindung auf. Der Test wird langsam, bricht ohne Netz und misst plötzlich viel mehr als die eine Funktion.

Viele denken, ein Test müsse „echt“ sein, also mit echter Datenbank und echten APIs, sonst sei er wertlos. Das klingt plausibel, weil Software am Ende ja wirklich laufen muss.

Tatsächlich prüft ein Unit-Test nur eine Einheit isoliert – meist eine einzelne Funktion oder Methode einer Klasse. Abhängigkeiten wie Datenbanken oder APIs werden dafür durch Test-Doubles ersetzt, also Nachahmungen, die festgelegte Werte liefern. Solche Tests laufen in Millisekunden und ganz ohne Netz. Das Zusammenspiel mit echten Nachbarn prüfen stattdessen Integrationstests, etwa gegen eine echte PostgreSQL-Instanz.

Der Irrtum entsteht, weil „Test“ sich erst einmal gleich anhört, egal welche Schicht er prüft. Die Testpyramide rät deshalb ausdrücklich: viele schnelle Unit-Tests, weniger Integrationstests und wenige End-to-End-Tests, also Tests über die gesamte Anwendung hinweg.

Ein Beispiel: Eine Funktion berechnet den Bruttopreis aus Nettopreis und Steuersatz. Ihr Unit-Test ruft sie mit konkreten Werten auf und vergleicht das Ergebnis mit dem erwarteten Wert, ganz ohne Datenbank. In Node.js reicht dafür seit Version 20 der eingebaute Test-Runner node:test.

„Woran man es erkennt:“ Läuft der Test offline in Millisekunden, prüft er eine Einheit. Berührt er Datenbank oder Netzwerk, ist er ein Integrationstest – und gegen eine gemockte Datenbank findet er keine SQL-Fehler, denn dafür gehört mindestens ein Test gegen die echte Datenbank-Engine dazu.

Unit heißt nicht „kleiner Test von irgendetwas“, sondern isolierte Prüfung einer Einheit mit Test-Doubles für alle Abhängigkeiten.

📌 Einheit isoliert · Test-Doubles · Testpyramide

📚 Webentwicklung von Grund auf · Tag 6 von 30
#testing #NodeJS #typescript #webdev

TypeScript kennt den Typ einer Variable oft besser, als die Deklaration vermuten lässt. Nach einer einzigen Prüfung im Code verschwinden Fehler, die vorher rot unterstrichen waren.

Einsteiger begegnen dem bei Union-Typen, also Typangaben wie string | number, die mehrere Typen erlauben. Wer sie nicht kennt, wundert sich, warum der Zugriff auf length verboten ist. Der Compiler weiß ja nicht, welcher der beiden Typen gerade drinsteckt.

Das Einengen dieses Typs heißt Narrowing: Der Compiler verengt die Typangabe durch Prüfungen, die der Code ohnehin ausführt. Er analysiert den Kontrollfluss; nach einer bestandenen Prüfung gilt im Block nur der eingegrenzte Typ, im else-Zweig der Rest.

Typisch ist der typeof-Operator, der zur Laufzeit eine Zeichenkette wie "string" liefert. Beispiel: eine Funktion laenge mit Parameter value vom Typ string | number. Sie prüft zuerst mit if, ob typeof value den Wert "string" ergibt; nur dann liefert sie value.length, sonst value.toString().length. Ohne die Prüfung wäre der Zugriff auf length ein Fehler, weil number diese Eigenschaft nicht hat. instanceof prüft, ob ein Objekt von einer Klasse abstammt, und gibt deren Methoden frei. Literalvergleiche wie if (value === "admin") grenzen auf genau diesen Wert ein, besonders bei diskriminierten Unions mit einem Feld wie kind.

Narrowing wird gern mit Validierung verwechselt, also der echten Prüfung ankommender Daten. JSON.parse gibt den Typ any zurück; eine Behauptung wie as User unterdrückt nur die Compilerwarnung. Typen existieren nur zur Übersetzungszeit, im erzeugten JavaScript ist nichts davon übrig.

Narrowing ist keine Prüfung, sondern ein Schluss aus Prüfungen. Es ersetzt die Validierung externer Daten nicht, es setzt sie voraus.

📌 typeof · instanceof · Kontrollfluss

📚 Webentwicklung von Grund auf · Tag 5 von 30
#typescript #javascript #webdev

TypeScript verspricht Sicherheit, doch nach dem Übersetzen ist davon nichts mehr da. Wer das nicht weiß, vertraut Daten, die nie geprüft wurden.

TypeScript übersetzt den Code nach JavaScript, und dabei verschwinden alle Typangaben. Der Vorgang heißt Kompilieren, also das Übersetzen des Quelltexts in ausführbaren Code, und er läuft bei jedem Build.

Zuerst schreibt man Typen wie const user: User in den Code. Eine Typangabe ist eine Zusicherung an den Compiler, also das Übersetzungsprogramm: Sie sagt „vertrau mir“, statt einen Wert zu prüfen. Der Compiler sieht nur die Deklaration, nie die echten Daten.

Dann kommt Daten von außen: von einer Web-API über das Netzwerk, aus einer Datei oder von Nutzern. JSON ist dabei das verbreitete Format, mit Schlüssel-Wert-Paaren, Listen, Zeichenketten, Zahlen sowie true, false und null. Zur Laufzeit, also während das Programm läuft, weiß der Code nichts mehr von Typen.

Danach verwandelt JSON.parse die ankommende Zeichenkette in ein Objekt. In TypeScript gibt die Methode den Typ any zurück, und any schaltet die Typprüfung für diesen Wert ab. Schreibt man as User dazu, unterdrückt das nur eine Compilerwarnung: Die Daten bleiben ungeschützt.

Zuletzt prüft man selbst, bevor man einen Typ vertraut: Ist der Wert ein Objekt, existieren die erwarteten Felder, passen ihre Typen? Ein Typtest wie typeof x === "string" sichert das Ergebnis ab. Besser noch: eine kleine Prüffunktion, die unknown entgegennimmt und erst nach bestandener Prüfung einen konkreten Typ zurückgibt.

Eine Typangabe heißt nicht „geprüft“, sondern „behauptet“. Was zur Laufzeit ankommt, muss zur Laufzeit geprüft werden.

📌 Typen zur Übersetzungszeit · JSON.parse gibt any · unknown plus Prüffunktion

📚 Webentwicklung von Grund auf · Tag 5 von 30
#typescript #javascript #webdev

JavaScript läuft im Browser – und TypeScript landet dort ebenfalls, aber nur als übersetztes Ergebnis. Der Unterschied liegt darin, was vor dem Start geprüft wird.

Die Verwechslung ist naheliegend: TypeScript sieht fast aus wie JavaScript und erzeugt am Ende auch genau das. Doch TypeScript ist eine Sprache mit statischen Typen, das heißt, der Compiler prüft schon vor dem Start, welche Art von Wert in jeder Variable steckt. JavaScript dagegen entscheidet Typen erst zur Laufzeit, also während das Programm läuft.

JavaScript ist die Skriptsprache, die das Verhalten einer Seite im Browser steuert. Der Browser führt den Code unmittelbar aus, ohne dass vorher ein Compiler die Typen prüft. Ein Beispiel: „5“ + 5 ergibt den String „55“, weil die Zeichenkette den Typ der Verknüpfung bestimmt. Der Fehler fällt erst beim Nutzer auf.

TypeScript ist JavaScript, erweitert um Typangaben wie string für Zeichenketten, number für Zahlen und boolean für Wahrheitswerte. Der Compiler prüft alle Typen und erzeugt daraus normales JavaScript. Eine Signatur wie function alter(pruefe: string): number sagt beim Lesen, was hineingehört und was herauskommt; ein Interface namens Nutzer mit den Feldern name und alter meldet fehlende Felder vor dem Start.

TypeScript wirft die Typangaben beim Übersetzen vollständig weg. In der ausgegebenen Datei stehen keine Typen mehr, und der Browser führt gewöhnliches JavaScript aus.

Faustregel: In TypeScript entwickeln, um Fehler früh im Editor zu sehen – aber nie erwarten, dass der Browser dadurch geschützt wird. Typen sind ein Werkzeug der Entwicklungszeit, kein Schutz zur Laufzeit.

TypeScript macht also nicht den Code im Browser sicherer, sondern fängt Typfehler vor dem Start ab, statt dass sie beim Nutzer auftreten. Wer das trennt, nutzt beide Sprachen richtig.

📌 Statische Typen · Compiler · Interface

📚 Webentwicklung von Grund auf · Tag 5 von 30
#typescript #javascript #webdev

Der Code hängt an einer await-Zeile – oder scheint es zu tun. Dabei wartet dort nur eine einzige Funktion, nicht das ganze Programm.

Symptom kennen viele aus ihren ersten Webprojekten: Eine Variable enthält nach einem Serveraufruf nichts Brauchbares. Stattdessen steckt darin ein Objekt namens Promise, obwohl man doch die Daten erwartet hatte.

Hinter dem Symptom steht ein Grundbegriff: das Promise, ein Behälter für ein Ergebnis, das erst später eintrifft. JavaScript wartet nicht gern: Läuft eine Anfrage an einen Server, gibt der Aufruf sofort das Promise zurück – noch ohne Inhalt. Die Event-Loop, also die zentrale Verwaltung, die Aufgaben nacheinander abarbeitet, läuft währenddessen munter weiter. Würde der Code wirklich anhalten und warten, stünde die gesamte Anwendung still. Das Promise ist der Trick, beides zu vermeiden: Aufrufer bekommen sofort etwas in der Hand, die Daten folgen später.

Konkret: In einer mit async markierten Funktion, die immer ein Promise zurückgibt, schreibt man const antwort = await fetch("/artikel/42"); fetch ist der Browser-Befehl für eine HTTP-Anfrage. Erst nach Ankunft der Serverantwort liefert await das Antwortobjekt mit den Daten. Wichtig: await pausiert allein die umgebende Funktion; andere Aufgaben, etwa weitere eingehende HTTP-Anfragen, laufen weiter. async und await sind also keine Paralleltechnik, sondern eine lesbare Schreibweise für Promise-Ketten.

So prüft man es: Nach dem Aufruf den Inhalt der Variablen ausgeben lassen. Steht dort ein Promise statt der Daten, fehlt await. Und die await-Zeile in try und catch packen, damit eine Ablehnung des Promise, also ein fehlgeschlagenes Ergebnis, nicht als unbehandelter Fehler durchgeht.

await heißt nicht „Programm anhalten“, sondern „nur diese Funktion pausieren, bis das Promise ein Ergebnis liefert“.

📌 Promise · await · Event-Loop

📚 Webentwicklung von Grund auf · Tag 4 von 30
#javascript #typescript #webdev

Node 24 mit nativem TypeScript-Support im Produktionstest, Ergebnis nach einer Woche: Deploy-Pipeline von 6:40 auf 3:05 Minuten, ueber 1.200 Zeilen Bundler- und tsconfig-Ballast geloescht, Cold-Start unveraendert. Einzige Stolperfalle: ein Legacy-Decorator, der doch noch einen Transform brauchte. Fuer neue Services gilt bei uns ab sofort: kein Transpiler mehr. Weniger Toolchain ist auch weniger Angriffsflaeche. #webdev #performance

TypeScript oder JavaScript für neue Projekte? #typescript #javascript #umfrage