Was zum Teufel ist Node?

Hier ist das Wichtigste, was man über Node.js (oder einfach Node) wissen muss und wie es direkt mit npm zusammenhängt.

• Node ist JavaScript, aber als serverseitige Sprache.
• Dies ist dank V8, der JavaScript-Engine von Chromium, möglich, die unabhängig vom Browser laufen kann.
• Node und browserbasierter JavaScript können sich stark unterscheiden und unterschiedliche Fähigkeiten haben, obwohl beide im Kern JavaScript sind.
• Sie müssen Node nicht kennen, um npm zu verwenden.

Wie Sie inzwischen vielleicht wissen, steht npm für Node Package Manager (auch wenn die offizielle npm-Website auf jeder Seite im Header amüsante alternative Namen anzeigt, wie „Ninja Pumpkin Mutants“).

Das Wichtigste, was Sie sofort verstehen sollten, ist Folgendes: „Node“ und „Package Manager“ sind die beiden großen, unterschiedlichen Teile, die zusammen npm bilden.

Wir werden behandeln, was ein Paketmanager ist und warum Sie ihn in Betracht ziehen könnten, wenn wir zum nächsten Kapitel dieses npm-Leitfadens kommen. Vorerst konzentrieren wir uns jedoch darauf, zu verstehen, was Node ist, da es ein wichtiger Teil des Verständnisses der modernen Webentwicklung ist.

Kapitel des Leitfadens

1. Für wen ist diese Anleitung?
2. Was zum Teufel bedeutet „npm“?
3. Was zum Teufel ist die Befehlszeile?
4. Was zum Teufel ist Node? (Sie sind hier!)
5. Was zum Teufel ist ein Paketmanager?
6. Wie zum Teufel installiert man npm?
7. Wie zum Teufel installiert man npm-Pakete?
8. Was zum Teufel sind npm-Befehle?
9. Wie zum Teufel installiert man ein bestehendes npm-Projekt?

Node ist JavaScript, aber ohne den ganzen Browser

Sie kennen JavaScript wahrscheinlich hauptsächlich als eine Sprache, die im Browser läuft, ähnlich wie HTML und CSS. Ja, jede dieser Sprachen hat Abstraktionen und Obermengen (wie HAML für HTML, Sass für CSS und TypeScript für JavaScript als Beispiele) sowie Compiler und Transpiler und alle möglichen Dinge, die sie in diese oder jene Form umwandeln. Aber letztendlich generieren diese Tools Vanilla-Code (d. h. reinen Code) in der richtigen Syntax, als ob die Abstraktionen nie verwendet worden wären, um im Browser und nur im Browser ausgeführt zu werden.

Das hat am längsten gedauert, bis ich es verstanden habe, und ehrlich gesagt, ist es vielleicht ein noch größer verpasster Hinweis als die ganze Sache mit npm. JavaScript braucht keinen Browser mehr, um ausgeführt zu werden. Sie werden mich also manchmal Node-JavaScript nennen, wenn ich es von „browserbasiertem“ JavaScript unterscheide.

Server-seitige vs. client-seitige Sprachen

An dieser Stelle halte ich es für angebracht, einen Moment innezuhalten und die Unterscheidung zwischen client-seitigen Sprachen (HTML, CSS, JavaScript) und server-seitigen Sprachen (im Grunde alle anderen) zu untersuchen. Ich gehe nicht davon aus, dass Sie Erfahrung mit server-seitigen Sprachen wie PHP, Ruby oder Python haben, aber wenn das *Konzept* von server-seitigen Sprachen für Sie völlig neu ist, könnte es sich lohnen, zu lesen, was sie sind. (Zusammenfassend: Es sind Programmiersprachen, die rein auf einem Server und nicht im Browser ausgeführt werden und im Allgemeinen viel breitere und leistungsfähigere Fähigkeiten haben.)

Das ist relevant, denn vor einigen Jahren, etwa 2009, gab es einige sehr kluge Leute, die JavaScript *wirklich* mochten. Insbesondere mochten sie, wie *schnell* JavaScript ist (besonders im Vergleich zu den damals dominierenden server-seitigen Sprachen, am bekanntesten PHP und Ruby), und sie wollten JavaScript *überall* haben, nicht nur im Browser.

Ryan Dahl ist die prominenteste Persönlichkeit unter ihnen und ihm wird die Erfindung von Node zugeschrieben (und in jüngerer Zeit Deno, was ein Anagramm von Node ist). Das ist eine nette Information, aber ansonsten für dieses Thema nicht unbedingt relevant.

Wie Node funktioniert

Relevant ist jedoch, dass Node im Wesentlichen JavaScript als server-seitige Sprache ist, die *außerhalb* des Browsers läuft.

Wie ist das möglich? Unter der Haube hat jeder Browser seine eigene JavaScript-Engine. Dies ist der Teil des Browsers, der tatsächlich JavaScript *ausführt*. Ja, das ist anscheinend ein separater Teil des Browsers und nicht Teil desselben Codes, der HTML und CSS verarbeitet – was meiner Meinung nach Sinn macht, wenn man bedenkt, dass wir buchstäbliche APIs zwischen dem Dokument und JavaScript haben. Selbst das Konzept eines DOM ergibt mehr Sinn, wenn man die Abteilung, die JavaScript verwaltet, als provisorisches Büro auf dem Flur von der HTML-Abteilung betrachtet.

Die JavaScript-Engine in Chromium-basierten Browsern heißt V8, vermutlich nach einer bestimmten Art von Automotor (nicht das „Gemüsesaftgetränk“, das hauptsächlich aus Tomatensaft besteht). V8 ist bei weitem die beliebteste JavaScript-Engine. Dank der Standardisierungsbemühungen von ECMAScript in den letzten etwa 15 Jahren gibt es im Hinblick auf Browser keine wirklichen großen Unterschiede mehr zwischen JavaScript-Engines. Die in Chrome verwendete Engine ähnelt stark der Engine, die in Firefox läuft, die Safari ähnelt und so weiter. Die Popularität von V8 heutzutage hat weniger mit seinen Besonderheiten zu tun und mehr mit der Eigenständigkeit von Chrome.

(Seitennotiz: Die JavaScript-Engine von Firefox heißt SpiderMonkey. Das ist nicht besonders relevant, aber es ist weiterer Beweis dafür, dass Firefox am coolsten ist.)

Warum ist das wichtig? Nun, es stellt sich heraus, dass man die JavaScript-Engine aus einem Browser *herausnehmen* und mit einigen Modifikationen eigenständig betreiben kann – so ähnlich, als wenn man sich entscheidet, das Radio aus einem Auto auszubauen, ein wenig daran zu basteln und es stattdessen zu einem Soundsystem für zu Hause zu machen. V8 (und vermutlich das Autoradio) kann in jeder Umgebung als eigenständige Einheit einwandfrei funktionieren.

Mit anderen Worten: V8 ermöglicht es, JavaScript *überall* auszuführen. Deshalb gibt es „Node“-JavaScript und „browserbasiertes“ JavaScript.

Node ist fast (aber nicht ganz) JavaScript

Zusammenfassend lässt sich sagen: JavaScript ist jetzt eine server-seitige Sprache! Sie heißt Node und *könnte* bedeuten, dass Sie gar nichts über andere server-seitige Sprachen lernen *müssen*. Wir sind Frontend-Entwickler und wir haben jetzt Superkräfte.

Nachdem all dies gesagt ist, gilt jedoch: Node und das JavaScript, das Sie normalerweise im Browser ausführen, sind sich sowohl ähnlich als auch sehr unterschiedlich.

Auf die Gefahr hin, mich hier zu sehr zu verzetteln: Obwohl beide im Kern JavaScript sind und die Sprache und Syntax gleich sind, sind viele Grundpfeiler von JavaScript im Browser (wie `window` oder `document` und sogar das oft selbstverständliche `alert`) in einer rein server-seitigen Node-Umgebung nicht vorhanden. Es gibt natürlich kein Fenster, wenn die Sprache einfach eigenständig und nicht im Browser läuft. Neue Node-JavaScript-Entwickler sind oft überrascht zu erfahren, dass selbst `fetch` eigentlich eine Browser-API und nicht „reines“ JavaScript ist.

Keine Angst jedoch. `console.log` ist immer noch Ihr bester Freund, und es gibt viele *neue*, umgebungsspezifische Funktionen von Node-JavaScript, die sich von der Browser-Implementierung von JavaScript unterscheiden, wie das `process`-Objekt, das alle Details zu derzeit laufenden Prozessen enthält.

Node und sein Ökosystem haben sich im Laufe der Jahre oft zwangsweise in eine ganz andere Richtung entwickelt als browserbasiertes JavaScript. (Als offensichtliches Beispiel: Die Syntax für Importe zwischen den beiden war jahrelang unterschiedlich und beginnt sich erst jetzt wieder zu vereinheitlichen. Das werden wir im letzten Kapitel noch etwas genauer besprechen.)

Node hatte lange das Privileg, bei der Einführung neuer Funktionen viel schneller zu sein als Browser, und hatte auch eigene Probleme zu bewältigen. Es begann, server-seitige Anwendungen so zu betreiben, wie es Ruby und PHP seit Jahren taten, selbst während Browser noch versuchten, sich auf Standards zu einigen. Dies hat dazu geführt, dass Node-JavaScript und browserbasiertes JavaScript eher wie Cousins als wie Klone geworden sind.

Hier ist eine passende Analogie, um die Unterschiede zwischen den beiden JavaScript-Cousins zu erklären: Stellen Sie sich zwei ähnliche Musikinstrumente vor, z. B. einen Kontrabass und einen modernen E-Bass. Beide Instrumente sind gleich gestimmt und spielen dieselben Noten; wenn man eines beherrscht, beherrscht man in vielerlei Hinsicht auch das andere. Aber obwohl es Ihnen viel leichter fallen wird, das eine zu lernen, nachdem Sie das andere gelernt haben, wird das *Spielen* des neuen Instruments ganz anders sein als das, was Sie gewohnt sind.

Ähnlich ist es unwahrscheinlich, dass die Jobs zweier Entwickler, die jeweils eine Art von JavaScript schreiben, gleich aussehen.

Node ist JavaScript mit den Fähigkeiten anderer zuvor erwähnter server-seitiger Sprachen – Dinge wie Lesen und Schreiben in das Dateisystem, Zugriff auf systemweite APIs, E-Mail, die Fähigkeit, auf Anfragen zu hören und zu reagieren, geplante Aufgaben … die Liste geht weiter.

Ich werde hier nicht mehr darauf eingehen, aber wissen Sie einfach, dass beide am Ende des Tages JavaScript sind, aber in unterschiedlichen Umgebungen ausgeführt werden und jeweils Dinge tun können, die die andere nicht kann. Selbst wenn Sie zuvor browserbasiertes JavaScript geschrieben haben, wird Node Ihnen über die grundlegende Syntax hinaus wahrscheinlich immer noch etwas fremd erscheinen und wird oft auf sehr unterschiedliche Weise verwendet werden.

Node lokal ausführen

Wie bei server-seitigen Sprachen üblich, müssen Sie Node installieren, bevor Sie es verwenden können.

Node wird häufig zusammen mit npm installiert, da der Paketmanager-Teil Node benötigt und der Node-Teil mit einem Paketmanager nützlicher ist. (Man könnte sagen, sie sind ein *Paket*-Deal. Nein, für diesen Witz entschuldige ich mich nicht. Ich bin schließlich ein Vater.)

Ich möchte an dieser Stelle betonen, dass **Sie nichts über Node wissen müssen, um npm zu verwenden**. Auch wenn ich im Folgenden einige Node-Beispiele behandeln werde, betrachten Sie diesen gesamten Abschnitt bitte als etwas Nützliches zu wissen, aber für diesen Zweck nicht wesentlich. Ich halte es immer noch für nützlich, ein etwas besseres Verständnis dafür zu bekommen, wie Node funktioniert, nur um ein vollständigeres Bild zu zeichnen.

Wir werden in einem kommenden Kapitel dieses Leitfadens behandeln, wie Node und npm installiert werden. Wenn Sie es also noch nicht installiert haben, können Sie diesen Teil einfach überfliegen oder hierher zurückkehren, wenn Sie es bereit haben. In jedem Fall ist dies für die weitere Verfolgung dieses npm-Leitfadens nicht entscheidend.

Wenn Sie es ausprobieren möchten, können Sie eine neue Datei `test.js` erstellen und darin generisches JavaScript einfügen. Etwas Kontemplatives wie der folgende Code, der Inhalte in die Konsole schreibt, sollte ausreichen.

console.log('Look, ma, Node hands!')

const oneThroughFive = [1, 2, 3, 4, 5]

oneThroughFive.forEach(number => {
  console.log(number)
})

Nehmen wir an, Sie speichern diesen Code, öffnen dann die Befehlszeile in einem Terminalfenster, navigieren dorthin, wo sich die Datei befindet (mit `cd` oder „change directory“) und führen `node test.js` aus, um die folgende Ausgabe zu erhalten.

Look, ma, Node hands!
1
2
3
4
5

Sie können auch `node` alleine eingeben (ohne Dateiname), um ein interaktives Terminal zu öffnen, in dem Sie beliebiges Node-JavaScript ausführen können. Wenn Sie jemals die Konsole in den DevTools Ihres Browsers geöffnet haben, um Code auszuprobieren, ist dies genau das, nur auf der Befehlszeile mit Node anstelle des Browsers.

Probieren Sie es aus, wenn Sie möchten, vorausgesetzt, Sie haben Node installiert. Aber auch hier dient dies nur zur Veranschaulichung und ist nicht erforderlich, um npm zu verwenden.

Was kommt als Nächstes

Alles, was wir in diesem Kapitel behandelt haben, ist nett und hilft hoffentlich zu zeigen (wenn auch einfach), wie Node funktioniert. Denken Sie daran, dass Node, obwohl wir kein spezifisches Beispiel dafür behandelt haben, alles tun kann, was eine server-seitige Sprache tun kann. Es ist hoffentlich nicht zu schwer vorstellbar, wie die Ausführung von JavaScript, um praktisch alles zu tun, was man sich vorstellen kann, auf Systemebene oder sogar auf einem Remote-Server sehr ansprechend und vorteilhaft ist.

Das Konzept von Node entstand als Möglichkeit, JavaScript außerhalb des Browsers auszuführen. Daher haben wir Node-basierte Pakete von Skripten, die uns bei der Frontend-Entwicklung helfen. Wie installieren wir also diese Pakete und stellen sicher, dass sie nicht nur aktualisiert, sondern auch deinstalliert werden können? Das steckt in den letzten beiden Buchstaben der npm-Abkürzung: *Paketmanager*.

Mit anderen Worten, npm ist ein Werkzeug, das Pakete verwaltet, die in Node-JavaScript geschrieben sind. Was genau ist ein Paketmanager und wie qualifiziert sich npm als einer? Das erfahren Sie als Nächstes in unserem npm-Leitfaden.