1.1 Werkzeuge einrichten

Nach dieser Einheit kannst du:

• Node.js in der LTS-Fassung installieren, JavaScript-Dateien mit node ausführen und kleine Fragen in der REPL klären.
• erklären, was Browser und Node.js gemeinsam haben und was es nur an einem der beiden Orte gibt.
• VS Code mit Biome einrichten und deine Projekte so ablegen, dass jede Übung als Unterordner im Jahres-Repository liegt.

Ein Paketdienst hat zwei Möglichkeiten, mit falsch beschrifteten Paketen umzugehen: Er prüft jedes Etikett am Förderband, bevor der Lkw losfährt, oder er stellt einfach zu und hofft, dass sich die Empfängerin schon meldet, wenn etwas nicht stimmt. JavaScript arbeitet nach der zweiten Methode, TypeScript nach der ersten. Um genau diesen Unterschied geht es in Kapitel 1.

Abb. 1.1: Vorher prüfen oder nachher hoffen: TypeScript arbeitet wie Variante 1, JavaScript wie Variante 2 (eigene Darstellung).

Die Sprachen dieses Schuljahres sind JavaScript und sein typisierter Aufsatz TypeScript. Der Grund ist das Jahresthema: Client-Server-Anwendungen im Web. JavaScript ist die einzige Sprache, die im Browser läuft, und mit Node.js läuft sie ebenso auf dem Server. Client und Server lassen sich damit in einer Sprache entwickeln, und genau das nutzt das Framework Next.js, mit dem wir ab der Jahresmitte arbeiten.

Kapitel 1 legt die Basis für das ganze Jahr und ist in sechs Einheiten geteilt: Diese erste richtet die Werkzeuge ein, die Einheiten 1.2 bis 1.4 gehen die Grundkonstrukte von JavaScript, this und die modernen Sprachmittel durch, und mit den Einheiten 1.5 und 1.6 kommt TypeScript. Wer Variablen, Verzweigungen, Schleifen, Funktionen und Datenstrukturen bereits aus einer anderen Sprache beherrscht, liest den JavaScript-Teil als kompakte Wiederholung in neuer Syntax. Mit TypeScript kommt danach etwas wirklich Neues: statische Typen als Werkzeug gegen eine ganze Fehlerklasse.

Begriffe vorab

• JavaScript-Engine: das Programm, das JavaScript-Quelltext liest, übersetzt und ausführt, zum Beispiel V8 in Chrome.
• Laufzeitumgebung (runtime): Engine plus zusätzliche Schnittstellen wie Dateisystem und Netzwerk; Node.js ist eine solche Laufzeitumgebung.
• Paketmanager (package manager): das Werkzeug, das fremden Code in Form von Paketen holt und verwaltet, bei uns npm.
• REPL: eine Eingabezeile, die jede eingetippte Zeile sofort auswertet und das Ergebnis zeigt.
• Linter und Formatierer (formatter): Werkzeuge, die fragwürdigen Code melden beziehungsweise Code einheitlich einrücken.
• Statische Typprüfung: Typfehler werden vor dem Programmlauf gefunden, nicht erst währenddessen. Das ist die Aufgabe von TypeScript.

Werkzeuge einrichten

Node.js: JavaScript außerhalb des Browsers

JavaScript wurde 1995 für eine Aufgabe erfunden: Webseiten im Browser beweglich machen. Ausgeführt wird die Sprache dort von einer JavaScript-Engine. Jeder Browser bringt eine mit: V8 in Chrome und Edge, SpiderMonkey in Firefox, JavaScriptCore in Safari.

2009 kam jemand auf die naheliegende Idee, V8 aus dem Browser herauszulösen und als eigenständiges Programm zu starten. Das Ergebnis ist Node.js: dieselbe Engine, nur ohne Browser drumherum. Damit läuft JavaScript überall dort, wo sonst Java, Python oder C# arbeiten - auf Servern, in Kommandozeilenwerkzeugen, in Build-Prozessen.

Der Unterschied liegt also nicht in der Sprache, sondern in dem, was um sie herum zur Verfügung steht:

	Im Browser	In Node.js
Engine	V8, SpiderMonkey, JavaScriptCore (je nach Browser)	V8
Die Sprache selbst	identisch	identisch
Zusätzlich verfügbar	DOM (document), window, localStorage, alert	Dateisystem (fs), Pfade (path), Prozess (process), Server (http)
Nicht verfügbar	Zugriff auf das Dateisystem des Benutzers	DOM - es gibt keine Seite, die man verändern könnte
Gestartet durch	<script>-Tag in einer HTML-Seite	node datei.js im Terminal

Daraus folgt die praktische Regel für dieses Jahr: Derselbe Code läuft nicht automatisch an beiden Orten. document.getElementById(...) bricht in Node ab, weil es kein Dokument gibt. fs.readFile(...) gibt es im Browser nicht, und das ist Absicht: Eine Webseite darf nicht in deinen Dateien lesen.

Merksatz

Browser und Node.js teilen sich die Sprache, nicht die Umgebung: Variablen, Funktionen, Arrays, Objekte, fetch und Promises gibt es an beiden Orten, document nur im Browser und fs nur in Node.js.

Genauer erklärt: Was Node.js zur Laufzeitumgebung macht und nicht bloß zur Engine, sind drei Dinge zusammen - die Engine (V8), die zusätzlichen APIs (Dateisystem, Netzwerk) und der Event Loop, der die Abläufe koordiniert, während auf langsame Vorgänge gewartet wird. Der Event Loop ist das Thema von Kapitel 3. Er erklärt, warum ein einziger Node-Prozess tausende gleichzeitige Anfragen bedienen kann, ohne für jede einen eigenen Thread zu starten.

Abb. 1.2: Browser und Node.js teilen sich Engine und Sprache, nicht die Schnittstellen (eigene Darstellung).

Node ist übrigens nicht die einzige Laufzeit dieser Art (es gibt auch Deno und Bun), aber die mit Abstand verbreitetste - und die, auf der Next.js aufsetzt.

Wo begegnet dir das? Jedes Mal, wenn du ab Kapitel 7 npm run dev startest, läuft ein Node.js-Prozess, der deine Seite an den Browser ausliefert: Server und Client in einer Sprache, aber an zwei Orten. Auch VS Code selbst ist mit Web-Technik gebaut (Electron) und führt seine Erweiterungen in Node.js aus.

npm und pnpm: woher die Pakete kommen

Niemand schreibt alles selbst. Wer einen Datumsrechner, einen Validierer oder ein ganzes Framework braucht, holt sich ein Paket: fremden Code, der als wiederverwendbarer Baustein veröffentlicht wurde. Die Sammelstelle dafür heißt npm-Registry (npmjs.com), das größte Paket-Verzeichnis der Programmierwelt.

npm ist zweierlei in einem: diese Registry und das gleichnamige Kommandozeilenwerkzeug, das Pakete daraus holt, ihre Versionen verwaltet und die Abhängigkeiten mit installiert, die ein Paket seinerseits braucht. Der Name wird üblicherweise als Node Package Manager gelesen. Wichtig fürs Erste: npm wird mit Node.js mitinstalliert, es ist keine zusätzliche Installation nötig.

npm install zod       # fetches the package and everything it depends on

pnpm ist ein alternatives Werkzeug für denselben Zweck - gleiche Registry, gleiche package.json, andere Arbeitsweise. Der Name steht für performant npm, und der Unterschied ist die Ablage. npm legt in jedem Projekt eine vollständige Kopie aller Pakete in dessen node_modules/ ab: Bei fünf Projekten, die alle React verwenden, liegt React fünfmal auf der Platte.

pnpm speichert jede Paketversion stattdessen einmal in einem zentralen Speicher und verlinkt sie in die Projekte. Das spart spürbar Platz und Installationszeit. Zusätzlich ist pnpm strenger und macht nur die Pakete zugänglich, die wirklich in der package.json stehen; ein Tippfehler in den Abhängigkeiten fällt dadurch früher auf.

Womit arbeiten wir?

Im Unterricht verwenden wir durchgehend npm: Es kommt mit Node.js mit, braucht keine Zusatzinstallation und ist der Standard, auf den sich jede Anleitung im Netz bezieht. In älteren Unterlagen und in manchen Projektvorlagen wirst du trotzdem pnpm install statt npm install lesen - das ist kein Fehler, sondern dasselbe mit dem anderen Werkzeug.

Eine Regel gilt allerdings streng: In einem Projekt gibt es nur einen Paketmanager. Welcher verwendet wird, erkennst du an der Sperrdatei (package-lock.json bei npm, pnpm-lock.yaml bei pnpm); zwei davon nebeneinander sind ein handfester Fehler. Was in package.json und in diesen Sperrdateien steht, ist das Thema von Kapitel 2.

Installation

1. Node.js installieren. Lade es von nodejs.org herunter (unter Linux über den Paketmanager). Die Seite bietet zwei Fassungen an: LTS und Current. Nimm LTS - das ist die Fassung mit Long Term Support, die über Jahre Fehlerkorrekturen bekommt und auf die sich Werkzeuge und Bibliotheken verlassen. Current ist die neueste Version, aber eine Baustelle. npm kommt mit.

2. Installation prüfen.

   node --version        # v24.x or newer LTS Version
   npm --version

3. Erstes Skript ausführen. Leg eine Datei hello.js an und starte sie im Terminal:

   const name = "Ada";
   console.log(`Hello, ${name}!`);

   node hello.js

   Beispielprojekt: 01_typescript_examples/ex01_hello_node

4. VS Code: JavaScript- und TypeScript-Unterstützung ist eingebaut, es braucht keine Erweiterung, um loszulegen. Welche Erweiterungen sich trotzdem lohnen, steht gleich im nächsten Abschnitt.

console.log() schreibt ins Terminal (im Browser: in die Konsole der DevTools). Eine Tastatureingabe im Konsolenstil spielt in diesem Jahr kaum eine Rolle; Eingaben kommen aus Web-Formularen und HTTP-Anfragen.

Die REPL: ausprobieren ohne Datei

Node bringt außerdem eine REPL mit. Das Kürzel steht für Read-Eval-Print-Loop und beschreibt genau, was das Werkzeug tut: Es liest eine eingetippte Zeile (read), wertet sie aus (eval), gibt das Ergebnis aus (print) und beginnt von vorne (loop). Gestartet wird sie mit node ohne Dateinamen; beendet wird sie mit .exit oder Strg+D.

> 2 + 3 * 4
14
> const name = "Ada"
undefined
> name.toUpperCase()
'ADA'
> console.log("hi")
hi
undefined
> [1, 2, 3].map((n) => n * 2)
[ 2, 4, 6 ]

Zwei Zeilen daraus verwirren beim ersten Mal zuverlässig, und beide erklären sich aus dem P in REPL: Die REPL gibt immer den Wert des Ausdrucks aus, den du eingetippt hast. Eine Deklaration wie const name = "Ada" hat keinen Wert - deshalb undefined. Und console.log("hi") macht zweierlei: Es schreibt hi auf die Konsole (das ist seine Aufgabe) und liefert danach undefined zurück (das ist sein Rückgabewert). Die REPL zeigt beides.

Wozu das Ganze? Um eine Frage zu klären, ohne ein Projekt anzulegen: Was macht parseInt("08")? Was liefert [3, 12, 1].sort() wirklich? Solche Dinge beantwortest du in fünf Sekunden statt in fünf Minuten Recherche, und du weißt es danach aus erster Hand.

Für mehr als ein paar Zeilen ist die REPL allerdings nichts: Nach dem Schließen ist alles weg. Sobald du etwas aufbewahren willst, kommt es in eine Datei. Dieselbe Idee findest du übrigens in der Browser-Konsole der DevTools; auch dort ist jede Eingabe ein Durchlauf durch dieselbe Schleife.

Visual Studio Code einrichten

JavaScript und TypeScript versteht VS Code von Haus aus; Erweiterungen sind trotzdem sinnvoll, weil sie Fehler früher zeigen und Formatierungsdiskussionen beenden. Die Liste für dieses Jahr:

Erweiterung	Wofür
Biome (biomejs.biome)	Linter und Formatierer in einem: meldet fragwürdigen Code beim Tippen und formatiert beim Speichern
Error Lens (usernamehw.errorlens)	schreibt Fehlermeldungen direkt neben die Zeile statt in die Problemliste
Pretty TypeScript Errors (yoavbls.pretty-ts-errors)	macht lange Compiler-Meldungen lesbar - im ersten Halbjahr Gold wert
Auto Rename Tag (formulahendry.auto-rename-tag)	benennt das schließende Tag mit um; ab dem React-Kapitel ständig nützlich
Path Intellisense (christian-kohler.path-intellisense)	vervollständigt Dateipfade in import-Zeilen
markdownlint (davidanson.vscode-markdownlint)	prüft die Markdown-Dateien deiner Abgaben
REST Client (humao.rest-client)	HTTP-Anfragen direkt aus einer .http-Datei; ab Kapitel 5 im Einsatz
Git Graph (mhutchie.git-graph)	zeigt die Historie als Graph, inklusive Branches

Schneller als die Suche im Marktplatz ist die Kommandozeile:

code --install-extension biomejs.biome
code --install-extension usernamehw.errorlens
code --install-extension yoavbls.pretty-ts-errors
code --install-extension formulahendry.auto-rename-tag
code --install-extension christian-kohler.path-intellisense
code --install-extension davidanson.vscode-markdownlint
code --install-extension humao.rest-client
code --install-extension mhutchie.git-graph

Prisma (prisma.prisma) kommt erst im Persistenz-Kapitel dazu; installiere sie erst dann.

Biome: prüfen und formatieren mit einem Werkzeug

Zwei Aufgaben fallen in jedem Projekt an: fragwürdigen Code finden (Linter) und den Code einheitlich einrücken (Formatierer). Lange war das die Arbeit von zwei Werkzeugen, ESLint und Prettier, mit zwei Konfigurationsdateien, die sich gegenseitig in die Quere kommen konnten. Im Unterricht verwenden wir stattdessen Biome: ein Werkzeug für beides, eine Konfigurationsdatei biome.json, und so schnell, dass die Prüfung beim Tippen nicht bremst.

Die VS-Code-Erweiterung zeigt die Meldungen direkt im Editor an. Damit Biome auch beim Speichern formatiert, gehört in die Einstellungen (settings.json):

{
  "editor.defaultFormatter": "biomejs.biome",
  "editor.formatOnSave": true
}

Im Projekt selbst wird Biome wie jedes Entwicklungswerkzeug als devDependency installiert (was das genau heißt, zeigt Kapitel 2):

npm install --save-dev --save-exact @biomejs/biome   # exact version: formatting rules change between versions
npx @biomejs/biome init                              # creates biome.json with the recommended rules
npx @biomejs/biome check .                           # lint and format check in one pass
npx @biomejs/biome check --write .                   # apply the safe fixes

Genauer erklärt: check --write behebt nur, was sich gefahrlos automatisch ändern lässt, etwa Einrückung, fehlende Strichpunkte oder let, wo const reicht. Ein == meldet Biome zwar (Regel noDoubleEquals, mehr dazu in Einheit 1.2 bei den Vergleichen), ersetzt es aber nicht selbst durch ===, weil sich dabei das Verhalten des Programms ändern kann. Diese Entscheidung bleibt bei dir.

Weiterlesen

Biome: Getting Started - Installation, biome.json und die wichtigsten Befehle; von dort ist auch die Liste aller Regeln verlinkt.

Wo deine Projekte liegen

Der Ablageort klingt nach Nebensache und kostet erfahrungsgemäß die meisten verlorenen Stunden. Drei Regeln:

1. Kein Leerzeichen im Pfad. Viele Werkzeuge der JavaScript-Welt stolpern darüber. Leg einen kurzen Arbeitsordner an, etwa C:\HTL\SEW4te\, und arbeite ausschließlich darin.

   good:  C:\HTL\SEW4te\SJ26_27_4AHITM_SEW_musterm_exercises
   bad:   C:\Users\max muster\OneDrive\Dokumente\Projekte\SEW

   Enthält dein Benutzername ein Leerzeichen, ist der Ordner außerhalb des Benutzerverzeichnisses Pflicht. Auch OneDrive-synchronisierte Ordner sind ungeeignet: Der Synchronisationsdienst und ein node_modules-Ordner mit zehntausenden Dateien vertragen sich schlecht.

2. Lange Pfade erlauben. Node-Projekte verschachteln tief. Einmalig im Terminal:

   git config --global core.longpaths true

3. Ein Repository für das ganze Jahr. Deine Lehrkraft legt für dich in GitLab genau ein privates Projekt an, benannt nach dem Schema SJ26_27_4AHITM_SEW_<Benutzername>_exercises (Beispiel: SJ26_27_4AHITM_SEW_musterm_exercises). Klone es nach C:\HTL\SEW4te\; jedes Übungsprojekt entsteht danach als Unterordner darin.

Der letzte Punkt hat einen technischen Grund: Legst du ein Projekt außerhalb an und verschiebst es später hinein, hat es womöglich schon ein eigenes Git-Repository: create-next-app legt außerhalb eines Repositorys automatisch eines an, und ein git init von Hand hat dieselbe Folge - du hättest ein Repository im Repository, und beim Push fehlt der halbe Code. Richtig ist deshalb:

cd C:\HTL\SEW4te\SJ26_27_4AHITM_SEW_musterm_exercises
npm create vite@latest uebung-07-1a -- --template react-ts

Und nicht: erst einen Ordner auf dem Desktop anlegen und ihn später hineinschieben. Ist es doch passiert, lösch den .git-Ordner innerhalb des Unterprojekts, bevor du committest.

Abb. 1.3: Ein Repository fürs ganze Jahr, jede Übung als Unterordner (eigene Darstellung).

Kurz nachgedacht

Starte die REPL mit node und tipp [3, 12, 1].sort() ein. Überleg vorher: Welches Ergebnis erwartest du, und welches kommt wirklich?

Auflösung

Die REPL zeigt [ 1, 12, 3 ]. sort() vergleicht ohne weitere Angabe als Text, und als Text kommt "12" vor "3", weil "1" vor "3" steht. Zahlen sortierst du mit einer Vergleichsfunktion: [3, 12, 1].sort((a, b) => a - b) liefert [ 1, 3, 12 ]. Genau für solche Überraschungen ist die REPL da.

Stolperfallen

1. Projekt neben dem Jahres-Repository angelegt: Wer ein Übungsprojekt am Desktop mit create-next-app anlegt und später hineinschiebt, hat ein Repository im Repository, und beim Push fehlt der halbe Code. Projekte entstehen direkt im Jahres-Repository; ist es doch passiert, den .git-Ordner im Unterprojekt löschen.
2. Leerzeichen oder OneDrive im Pfad: Viele Werkzeuge der JavaScript-Welt stolpern über Leerzeichen, und der Synchronisationsdienst verträgt sich schlecht mit node_modules. Arbeite in einem kurzen Ordner wie C:\HTL\SEW4te\.
3. Zwei Paketmanager in einem Projekt: package-lock.json und pnpm-lock.yaml nebeneinander sind ein handfester Fehler. Im Unterricht verwenden wir npm.
4. Current statt LTS: Die neueste Node.js-Fassung ist eine Baustelle; Werkzeuge und Bibliotheken verlassen sich auf die LTS-Fassung.
5. undefined in der REPL für einen Fehler halten: Eine Deklaration hat keinen Wert, und console.log liefert nach der Ausgabe undefined zurück. Beides ist richtig so.

Zusatzmaterialien

• nodejs.org - Download der LTS-Fassung und die offizielle Dokumentation von Node.js.
• Biome: Getting Started - Installation, biome.json und die wichtigsten Befehle; von dort ist auch die Liste aller Regeln verlinkt.
• npmjs.com - die npm-Registry; hier suchst du Pakete und siehst Versionen, Downloads und Abhängigkeiten.
• MDN: Array.prototype.sort() - erklärt die Überraschung aus „Kurz nachgedacht“ und zeigt Vergleichsfunktionen.

Zum Anhören

Du kannst dir diese Einheit kostenlos mit der Vorlesefunktion deines Browsers oder Betriebssystems vorlesen lassen (etwa „Laut vorlesen” in Edge), ohne Konto und ohne Upload; die Codebeispiele liest du dabei am Bildschirm mit. Freiwillig kannst du mit Google NotebookLM (Google-Konto nötig) aus diesem öffentlichen Text eine gesprochene Zusammenfassung erzeugen, auch auf Deutsch.

Lernergebnisse

Du kannst jetzt:

• Node.js in der LTS-Fassung installieren, JavaScript-Dateien mit node ausführen und kleine Fragen in der REPL klären.
• erklären, was Browser und Node.js gemeinsam haben und was es nur an einem der beiden Orte gibt.
• VS Code mit Biome einrichten und deine Projekte so ablegen, dass jede Übung als Unterordner im Jahres-Repository liegt.

Passende Übungen

• Aufgabe 01 - TypeScript-Spickzettel, Stufe Wesentlich_überwiegend (Projekt und Werkzeugkette einrichten)

Quellen

• Node.js als Laufzeitumgebung, Installation und LTS-Fassung → nodejs.org
• VS Code führt Erweiterungen in einem Node.js-Prozess aus → VS Code-Dokumentation: Extension Host; VS Code ist mit Electron gebaut → microsoft/vscode auf GitHub, electronjs.org
• npm-Registry → npmjs.com
• sort() vergleicht ohne Vergleichsfunktion als Text → MDN: Array.prototype.sort()
• Biome: Installation, biome.json, check --write, Regel noDoubleEquals → Biome: Getting Started
• create-next-app legt außerhalb eines Repositorys ein eigenes Git-Repository an, create-vite nicht → eigener Test mit create-next-app 16.4.0 und create-vite 9.2.1 (Oktober 2026)
• Abb. 1.1 (Paketdienst), Abb. 1.2 (Browser und Node.js), Abb. 1.3 (Projektablage) → eigene Darstellung

Autoren

• Oliver Maurhart (MAO)
• Michael Gabriel (GAM)

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules