2009 hatte ein Entwickler (Ryan Dahl) eine einfache Idee mit grossen Folgen: Was, wenn man JavaScript ausserhalb des Browsers laufen liesse? Das ist Node.js. Heute treibt es einen grossen Teil der modernen Webanwendungen an.

Die urspruengliche Idee

Bis dahin lebte JavaScript nur im Browser (um Seiten interaktiv zu machen). Node.js nimmt die V8-Engine von Chrome — jene, die dieses JavaScript sehr schnell ausfuehrt — und holt sie aus dem Browser heraus, um sie serverseitig zu nutzen.

Die Folge: Man kann eine ganze Website, vom Server bis zur Oberflaeche, in einer einzigen Sprache schreiben. Fuer Web-Teams ist das ein enormer Gewinn.

Das nicht-blockierende Modell (der eigentliche Vorteil)

Die meisten klassischen Server verarbeiten Anfragen eine nach der anderen: Wartet eine auf die Datenbank, muessen die anderen warten.

Node.js funktioniert anders, mit einer nicht-blockierenden Ereignisschleife (event loop): Waehrend eine Anfrage auf eine Antwort wartet (Datenbank, Datei, Netzwerk), geht Node zur naechsten ueber. Das Ergebnis: Es verwaltet Tausende gleichzeitiger Verbindungen mit wenig Ressourcen.

Deshalb glaenzt Node bei:

• APIs (die viele kleine Anfragen beantworten),
• Echtzeit (Chat, Benachrichtigungen, Spiele, Live-Dashboards).

Das Oekosystem: npm

Node wird mit npm geliefert, dem Paketmanager: dem groessten Bibliothekskatalog der Welt. Brauchst du einen Kalender, ein Authentifizierungssystem, einen Zahlungs-Client? Es gibt fast immer ein Paket dafuer. Genau das macht die Entwicklung schnell.

Oft kommt obendrauf:

• ein Server-Framework: Express, Fastify oder NestJS;
• ein Oberflaechen-Framework: React, Vue, Svelte — manchmal in “Full-Stack”-Werkzeugen wie Next.js oder Nuxt vereint.

Node vs PHP: zwei Philosophien

	PHP (LAMP)	Node.js
Ausfuehrung	Bei jeder Anfrage (startet und endet)	Persistenter Prozess (immer aktiv)
Staerke	Content-Management, WordPress-Oekosystem	API, Echtzeit, Full-JavaScript
Sprache	PHP serverseitig, JS clientseitig	JavaScript ueberall

Keines ist absolut gesehen “besser”: Sie decken unterschiedliche Beduerfnisse ab. Siehe auch unseren Vergleich statisch / dynamisch / Anwendung.

Wann man Node (nicht) waehlen sollte

• Waehle Node fuer eine interaktive Anwendung, eine API, ein Echtzeit-Produkt oder wenn dein Team bereits auf JavaScript setzt.
• Vermeide Node fuer eine einfache Visitenkartenseite: Eine statische Seite ist einfacher, schneller und guenstiger.

Entscheidend ist nicht die Mode, sondern die Passung zwischen Werkzeug und Bedarf.