Node.js

Praxis-Nachtrag: Nutze Node.js in einem Mini-Szenario. Eine kleine App soll einen Nutzer anmelden, eine Liste laden oder eine Bestellung speichern. Frage: An welcher Stelle taucht Node.js auf, was würde ohne diesen Baustein fehlen, und welchen Fehler würdest du als Anfänger wahrscheinlich sehen? Diese Denkweise macht den Begriff sofort greifbarer als eine reine Definition.

Wenn du Node.js installierst, hast du auch npm (Node Package Manager) dabei. Das ist der größte "App Store" für Programmierer der Welt. Du brauchst eine Bibliothek, um PDF-Dateien zu erstellen? npm install pdfkit. Fertig. Millionen fertige Bausteine stehen kostenlos bereit.

Node ist extrem beliebt für Webserver (mit Express.js) und Echtzeit-Apps (Chats, Spiele), weil es sehr schnell auf viele gleichzeitige Anfragen reagiert.

1. V8 Engine

Node.js basiert auf V8, der JavaScript-Engine von Google Chrome. V8 kompiliert JS direkt in Maschinencode (sehr schnell). Node hat C++ Bindings hinzugefügt, damit JS Dinge tun kann, die es im Browser nicht durfte: Dateien auf der Festplatte lesen, Netzwerk-Sockets öffnen.

2. Event Driven (Nicht-Blockierend)

Der Clou an Node: Es wartet nicht. Klassischer Server (PHP): "Lese Datei..." (Server schläft 2 Sekunden) "...Datei da. Sende Antwort." Node.js: "Lese Datei. Ich mach solange was anderes!" (Verarbeitet 1000 andere User). "Ah, Datei ist da! Sende Antwort." Deshalb kann ein kleiner Node-Server 10.000 User gleichzeitig bedienen, wo andere Server zusammenbrechen.

1. Libuv und der Thread Pool

Node.js rühmt sich, "Single-Threaded" zu sein. Das ist eine Halbwahrheit. Dein geschriebener JavaScript-Code (V8) und der Event-Loop laufen auf einem gigantischen Main Thread. Dort passiert Mathe und Kontrollfluss. Das Problem: Wenn du eine Datei liest (fs.readFile) bremst das eigentlich den Thread. Warum blockiert Node nicht? Wegen libuv (der in C geschriebenen C/C++ Bibliothek). Libuv unterhält unsichtbar einen Pool von (standardmäßig 4, konfigurierbaren) echten C-Worker-Threads. Die Festplattenoperation oder teure Crypto-Hashes werden in diesen Thread-Pool ausgelagert. Libuv erledigt die Schwerstarbeit im asynchronen Hintergrund und schmeißt das Ergebnis als Callback per Queue zurück in den V8 Main-Thread.

2. Event Loop Phases

Die Event-Loop ist nicht ein simpler Kreis, sie ist orchestriert in Phasen (Phases).

1. Timers: Führt setTimeout() aus, falls abgelaufen.
2. Pending Callbacks: Erledigt verzögerte System-Call Errors (TCP refused).
3. Poll: Der wichtigste Block! Hier wartet Node aktiv eintreffende Web-Requests und I/O Operationen ab. Node verbringt hier oft 90% seiner Lebenszeit.
4. Check: Führt setImmediate() Callbacks extrem fix aus.
5. Close: socket.on('close'). Das Unwissen vieler Node-Coder: Eine endlose while(true)-Schleife blockiert z.B. Phase 3 komplett. Weder Timers noch I/O werden je wieder gefeuert ("Event Loop blocked"), und der Webserver stirbt, obwohl die CPU auf 100% rattert.

3. CommonJS vs. ES Modules

Das Node-Ökosystem ist akut in einem Bürgerkrieg gespalten. Anfangs existierte nur das proprietäre CommonJS. Syntax: const fs = require('fs'). ES lädt synchron zur Laufzeit. Die Browser-Welt erfand später ESModules (ESM): import fs from 'fs'. ESM zwingt Engine und Parser zu einer vorherigen statischen statischen Analyse des gesamten Modul-Baums zur Compilezeit, weswegen man Module "Tree-Shaken" (toten Code eliminieren) kann, bevor der Code überhaupt losrennt. Heute zwingt Node Entwickler, in der package.json über das Feld "type": "module" gnadenlos zu deklarieren, ob das gesamte Projekt CJS oder ESM spricht. Das mischen beider Welten endet oft in grauenhaften ERR_REQUIRE_ESM Crashes, was Library-Autoren zum Bau von Dual-Build Packages zwingt.