Einstieg in JavaScript & ECMAScript

JavaScript — Einstieg

0:00 Kaum eine Programmiersprache ist so allgegenwärtig und wird so oft missverstanden wie JavaScript. Sie läuft in jedem Browser dieser Welt, sie treibt Server an, sie steckt in Werkzeugen, die niemand mehr bewusst wahrnimmt. Und trotzdem beginnen viele damit, ein Framework zu lernen, statt die Sprache. In diesem Modul drehen wir das um.

0:19 Wir klären zuerst, was JavaScript eigentlich ist und wo es ausgeführt wird, richten eine Umgebung ein, in der Sie wirklich arbeiten können — und am Ende läuft Ihr erster eigener Code. Nicht abgetippt aus einem Tutorial, sondern verstanden.

Ankommen in JavaScript

0:34 Sechs Stationen liegen vor uns, und sie folgen einer bewussten Reihenfolge. Erst die Einordnung: Was ist die Sprache, was die Umgebung, und was bedeutet dieses ECMAScript, das einem ständig begegnet. Dann die Werkzeuge und die Frage, wo man nachschlägt, wenn man etwas nicht weiß — das ist Handwerk, kein Eingeständnis. Danach wird es praktisch: installieren, prüfen, den ersten Code ausführen. Und zum Schluss ein kurzer Blick in den Debugger.

1:01 Theorie gibt es genau so viel, wie für den Start nötig ist. Das Modul endet mit laufendem Code.

Was JavaScript ist und wo es läuft

1:08 Fangen wir mit der Einordnung an. Denn wer weiß, was zur Sprache gehört und was nur zur jeweiligen Umgebung, spart sich später viele Stunden Fehlersuche. Und er versteht, warum ein Beispiel aus dem Netz auf dem eigenen Rechner plötzlich nicht funktioniert. Zwei Eigenschaften prägen JavaScript, und beide klingen technischer, als sie sind.

1:28 Dynamisch heißt: Sie müssen nicht vorab ankündigen, ob in einer Variablen eine Zahl oder ein Text steckt. Das entscheidet sich erst, während das Programm läuft. Interpretiert heißt: Es gibt keinen separaten Übersetzungsschritt, den Sie anstoßen müssen — Sie schreiben, Sie starten, es läuft. Stellen Sie sich den Unterschied wie zwischen einem Dolmetscher und einem übersetzten Buch vor. Das macht den Einstieg angenehm schnell.

1:52 Es verschiebt aber auch einen Teil der Fehler von der Übersetzungszeit in die Laufzeit — ein Punkt, auf den wir zurückkommen. Der eigentliche Gewinn liegt darin, dass Sie diese Sprache nur einmal lernen müssen. Dieselbe Syntax trägt die Oberfläche im Browser, den Server dahinter, das Kommandozeilenwerkzeug und die Build-Automatisierung.

2:12 Wer den Sprachkern beherrscht, wechselt das Framework, ohne bei null anzufangen — und Frameworks wechseln bekanntlich häufiger als Sprachen. Dazu kommt ein Punkt, der noch vor wenigen Jahren keine Rolle spielte: Ein erheblicher Teil des Codes, mit dem Sie künftig arbeiten, wird von einer KI vorgeschlagen. Bewerten können Sie diesen Code nur mit einem Fundament. Ohne das bleibt jedes Tutorial Auswendiglernen.

2:36 Was diese Zusammenstellung eigentlich zeigt, ist ein einziges Prinzip: Die Sprache bleibt gleich, die Umgebung liefert die Fähigkeiten. Ein Browser kann Fenster zeichnen und auf Klicks reagieren, aber nicht auf Ihre Festplatte schreiben — aus gutem Grund. Node.js kann Dateien lesen und Netzwerkdienste anbieten, hat dafür aber keine Oberfläche.

2:57 Schleifen, Funktionen und Objekte funktionieren überall identisch; alles darüber hinaus ist ein Angebot der Umgebung. Behalten Sie diese Trennlinie im Kopf. Dieser Kurs behandelt die Sprache selbst — nicht die Browser-Schnittstellen und kein einzelnes Framework. Jetzt sind Sie dran, und zwar mit Ihrem eigenen Vorhaben. Überlegen Sie: Wo soll Ihr Code laufen — im Browser, auf einem Server, als Werkzeug auf der Kommandozeile?

3:23 Und dann der wichtigere Teil: Nennen Sie zwei Bausteine, die Sie zwar in JavaScript benutzen, die aber nicht zur Sprache gehören, sondern zur Umgebung. Der Dateizugriff in Node ist so ein Fall, der lokale Speicher im Browser ein anderer. Wenn Sie diese Grenze einmal selbst gezogen haben, sitzt sie. Es geht nicht um eine richtige Antwort, sondern um die Unterscheidung dahinter.

3:46 Der häufigste Fehler passiert schon vor der ersten Zeile: JavaScript mit einem Framework gleichzusetzen und die Grundlagen zu überspringen. Das rächt sich, sobald etwas nicht funktioniert wie im Tutorial. Der zweite Klassiker folgt direkt aus unserer Trennlinie — man übernimmt Beispielcode aus dem Browser-Umfeld und wundert sich, warum Node ihn nicht kennt.

4:06 Zwei Entwarnungen noch: HTML- und CSS-Kenntnisse brauchen Sie für den Sprachkern nicht. Und wenn Ihnen ein KI-Assistent Code vorschlägt, den Sie nicht lesen können, dann ist nicht der Code das Problem, sondern die Übernahme.

ECMAScript, Engines und Kompatibilität

4:19 Kommen wir zu drei Begriffen, die ständig durcheinandergehen. Was hinter ihnen steckt, entscheidet über eine sehr praktische Frage: Läuft der Code, den ich gerade schreibe, auf dem System, auf dem er später laufen soll? Die Antwort ist überraschend selten eine Jahreszahl. ECMAScript ist das Regelwerk. Dort steht geschrieben, wie die Syntax aussieht, welche eingebauten Objekte es gibt, wie Operatoren sich verhalten.

4:44 Ein Normtext also, ähnlich wie eine DIN-Norm für ein Bauteil. JavaScript ist der Name, unter dem wir dieselbe Sprache im Alltag benutzen — einschließlich der Umgebung, in der sie ausgeführt wird. Die Norm allein tut nichts. Erst eine Engine setzt sie um, und die Umgebung packt weitere Fähigkeiten darum herum. Diese Kette — Norm, Engine, Umgebung — erklärt fast alles, was beim Thema Kompatibilität sonst verwirrend wirkt.

5:11 Hier liegt die vielleicht wichtigste Einsicht des Kapitels: Engines übernehmen neue Features einzeln, nicht als Paket. Es gibt keinen Stichtag, an dem eine Umgebung schlagartig alles aus einer Jahresausgabe beherrscht. Deshalb kann ein Beispiel unter Node 24 laufen und unter Node 18 einen Syntaxfehler werfen. Die nützliche Frage lautet also nie „Ist das ES 2025?", sondern immer: „Unterstützt meine Zielumgebung das?" Angenehm ist dabei die Rückwärtskompatibilität — alter Code bleibt lauffähig.

5:41 Das ist ein Segen für bestehende Projekte und der Grund, warum Sie in fremdem Code Muster aus zwanzig Jahren nebeneinander finden. Diese vier Begriffe lassen sich mit einem Bild sortieren. Die Spezifikation ist der Bauplan, die Engine ist der Motor, der ihn umsetzt, und die Laufzeitumgebung ist das fertige Fahrzeug samt allem, was noch drumherum gehört.

6:04 V8 sitzt in Chrome und in Node.js, JavaScriptCore in Safari, SpiderMonkey in Firefox — derselbe Bauplan, verschiedene Motoren. Deshalb kann ein Feature hier schon da sein und dort noch fehlen. Für diesen Kurs setzen wir eine feste Grundlinie: Node.js 24 als Langzeitversion, mit den Sprachmitteln der Ausgabe 2025. Damit funktionieren alle Beispiele reproduzierbar.

6:28 Diese Übung trainiert eine Fähigkeit, die Sie Ihr Berufsleben lang brauchen: selbst nachsehen, statt zu hoffen. Suchen Sie sich ein Feature aus der Ausgabe 2025 heraus und finden Sie heraus, ab welcher Node-Version es verfügbar ist. Entscheidend ist nicht die Zahl, sondern der Beleg — Sie sollen zeigen können, woher Sie es wissen. Und dann noch ein zweiter Blick: Zieht Ihr Zielbrowser mit?

6:51 Es kommt regelmäßig vor, dass die beiden Antworten auseinanderfallen. Genau dieser Moment ist der Grund für die Übung. Der verführerischste Trugschluss lautet: Es steht im Standard, also läuft es überall. Zwischen Normtext und ausgelieferter Engine liegen oft Jahre. Ähnlich heikel sind Vorschläge, die noch im Entwurfsstadium stecken — im Netz kursieren sie längst als fertige Features, in Ihrer Umgebung existieren sie nicht.

7:17 Prüfen Sie deshalb bei jedem übernommenen Beispiel, für welche Umgebung es gedacht war. Und noch eine Bitte um Milde: Ältere Muster sind nicht falsch, nur weil sie älter sind. Sie sind heute nicht mehr die erste Wahl — begegnen werden sie Ihnen trotzdem, in fast jedem gewachsenen Projekt.

Werkzeuge und Nachschlagewerke

7:34 Bevor wir installieren, lohnt ein kurzer Blick darauf, womit wir überhaupt arbeiten. Es sind erstaunlich wenige Teile — und ebenso wenige Quellen, in denen Sie nachschlagen. Genau diese Schlankheit ist Absicht: Jedes zusätzliche Werkzeug will verstanden, konfiguriert und gepflegt werden, und nichts davon bringt Sie dem ersten laufenden Programm näher.

7:54 Wir nehmen deshalb das Minimum, mit dem sich ernsthaft arbeiten lässt. Vier Teile, mehr braucht der Anfang nicht. Node.js führt Ihren Code aus. Die Paketverwaltung npm holt fremde Bausteine dazu und kommt gleich mit. Das Terminal ist die Stelle, an der Sie Befehle absetzen — für viele der ungewohnteste Teil, aber der mit dem größten Ertrag.

8:16 Und Visual Studio Code ist der Editor, in dem Sie schreiben und später auch debuggen werden. Was hier bewusst fehlt, sind Versionsmanager, Bündelwerkzeuge und Konfigurationsketten. Die kommen, wenn ein echter Bedarf sie erzwingt. Vorher sind sie nur Ballast, der vom Lernen ablenkt. Programmieren lernt man nicht durch Zusehen.

8:37 Solange Code nur im Video läuft, bleibt alles Theorie — die Fähigkeit entsteht in dem Moment, in dem Sie selbst einen Fehler erzeugen und ihn wieder loswerden. Deshalb legen wir Wert auf eine lokale Umgebung, auch wenn es online bequemere Spielwiesen gibt. Zum zweiten Punkt: Nachschlagen ist kein Zeichen von Unwissen, sondern Teil des Handwerks. Auch erfahrene Entwicklerinnen und Entwickler öffnen mehrmals täglich die Dokumentation.

9:02 Was Profis auszeichnet, ist nicht das Auswendigwissen, sondern die Sicherheit, in welcher Quelle die Antwort steht. Hinter dieser Aufteilung steckt eine einfache Logik: Jede Quelle beantwortet eine andere Art von Frage. Geht es um die Sprache selbst — wie verhält sich eine Methode, welche Argumente nimmt sie —, dann sind die MDN Web Docs die erste Adresse.

9:23 Geht es um etwas, das nur auf dem Server existiert, etwa Dateizugriff, dann steht die Antwort in der Node-Dokumentation und nirgends sonst. Fragen der Verfügbarkeit klärt caniuse. Und die formale Spezifikation ist die letzte Instanz für Streitfälle, nicht der Einstieg. Sie müssen nichts davon auswendig lernen — nur den Weg dorthin.

9:43 Drei Fragen, drei Quellen — ordnen Sie zu und holen Sie sich die Antwort tatsächlich ab. Wie verhält sich eine bestimmte Methode? Wie lese ich eine Datei? Wird ein neueres Feature vom Zielbrowser unterstützt? Der Lerneffekt liegt weniger in den Antworten als in der Zuordnung: Wer den Reflex entwickelt, sofort die richtige Quelle anzusteuern, spart über die Jahre erstaunlich viel Zeit.

10:06 Machen Sie es einmal bewusst und langsam. Danach läuft es von allein. Node-eigene Schnittstellen auf MDN zu suchen, ist der klassische Fehlgriff — sie stehen dort schlicht nicht, weil sie nicht zur Sprache gehören. Umgekehrt ist es reizvoll, die Spezifikation als erste Anlaufstelle zu nehmen; sie ist verbindlich, aber sie ist auch als Normtext geschrieben und beantwortet Alltagsfragen selten schnell.

10:30 Vorsicht auch bei Blogbeiträgen: Sie sind oft hervorragende Erklärungen, aber kein Beleg — Stand und Umgebung fehlen meistens. Und der letzte Punkt ist eher ein Rat: Bauen Sie keine Werkzeugkette auf, bevor Sie ein Projekt haben, das sie braucht.

Node.js und VS Code einrichten

10:44 Jetzt wird es praktisch. Nehmen Sie sich für dieses Kapitel wirklich Zeit und fragen Sie lieber einmal zu viel — wer hier hängen bleibt, kommt im ganzen Kurs nicht mit. Alles danach setzt darauf auf. Was heißt eigentlich „fertig eingerichtet"? Zwei Nachweise genügen: Node und npm antworten im Terminal mit einer Versionsnummer, und ein Projektordner ist im Editor geöffnet.

11:06 Diese Definition ist bewusst so nüchtern gehalten, weil die Einrichtung sonst ein Fass ohne Boden ist — man kann Tage mit Erweiterungen, Themes und Konfigurationen verbringen, ohne eine Zeile Code geschrieben zu haben. Die Versionsnummer ist der Beleg, dass die Installation nicht nur stattgefunden hat, sondern auch auffindbar ist.

11:26 Genau daran scheitert es nämlich häufiger als an der Installation selbst. Der rote Faden dieser fünf Schritte ist: erst installieren, dann beweisen, dann arbeiten. Wir holen Node in der Langzeitversion 24 — Langzeitversion heißt, sie wird über Jahre gepflegt und ist die vernünftige Wahl für alles, was länger leben soll als ein Nachmittag.

11:46 Dann den Editor. Der dritte Schritt ist der eigentlich wichtige: die Versionsabfrage im Terminal. Sie ist Ihr Beleg, dass das System die Programme auch findet. Erst danach legen wir einen Projektordner an und öffnen ihn. Meldet sich der Editor-Befehl nicht, ist trotzdem alles in Ordnung — den Ordner können Sie auch von Hand öffnen.

12:07 Was Sie hier sehen, sind zwei Gruppen von Befehlen mit ganz verschiedenen Aufgaben. Die ersten drei fragen nur nach: Bist du da, und in welcher Fassung? Die Antwort ist Ihr Nachweis. Die zweite Gruppe legt den Arbeitsplatz an — ein Ordner, ein Wechsel hinein, ein Öffnen im Editor. Achten Sie auf den Punkt am Ende der letzten Zeile: Er steht für „der Ordner, in dem ich gerade bin". Dieses Zeichen begegnet Ihnen auf der Kommandozeile immer wieder.

12:33 Und merken Sie sich den Namen kiezgarten — dieser Projektordner begleitet uns durch das gesamte Seminar. Diese Aufgabe ist kurz, aber sie ist die Eintrittskarte für alles Weitere. Sie soll nicht nur installieren, sondern belegen: Node meldet mindestens Version 24, npm antwortet mit einer Version, und der Ordner kiezgarten ist im Editor geöffnet.

12:54 Die Betonung liegt auf der Versionsnummer. Wenn dort eine ältere Zahl steht, funktionieren spätere Beispiele des Kurses nicht — und die Fehlermeldung, die Sie dann bekommen, wird Ihnen nicht verraten, dass die Node-Version die Ursache ist. Deshalb lieber jetzt zwei Minuten investieren als später eine Stunde suchen. Der teuerste Stolperstein ist die alte Node-Version, die man behält, weil sie ja läuft — und die einen dann Wochen später mit einem unverständlichen Syntaxfehler ausbremst.

13:23 Harmloser, aber verwirrend: Wenn der Editor-Befehl im Terminal nicht reagiert, ist das kein Installationsfehler, sondern nur eine fehlende Verknüpfung. Zwei Ratschläge noch: Versionsmanager sind großartig, sobald man mehrere Projekte mit unterschiedlichen Anforderungen hat — jetzt sind sie eine Fehlerquelle ohne Nutzen.

13:41 Und legen Sie den Projektordner an einer Stelle an, die Sie morgen wiederfinden. Klingt banal, kostet aber regelmäßig Zeit.

Erster JavaScript-Code

13:49 Jetzt kommt der Moment, auf den alles Bisherige hinauslief: eigener Code, der läuft. Dabei lernen Sie gleich zwei Wege kennen, ihn auszuführen — und die spannendere Frage ist nicht, wie beide funktionieren, sondern wann welcher der richtige ist. Die REPL — das Kürzel steht für Lesen, Auswerten, Ausgeben und wieder von vorn — ist eine Art Taschenrechner für Code.

14:11 Sie tippen einen Ausdruck, drücken Enter, sehen sofort das Ergebnis. Eine Datei dagegen ist das Notizbuch: Was darin steht, bleibt, lässt sich verändern und beliebig oft erneut ausführen. Beides ist nützlich, aber für Verschiedenes. Die REPL ist der Zettel neben dem Telefon, die Datei ist der Aktenordner. Wer beide Werkzeuge sauber auseinanderhält, arbeitet spürbar schneller — und wundert sich nicht mehr, wenn nach dem Schließen des Terminals alles weg ist.

14:40 Warum lohnt sich die REPL überhaupt, wenn man doch ohnehin Dateien schreibt? Weil sie kleine Fragen in Sekunden beantwortet. Wie verhält sich diese Methode bei einem leeren Wert? Was kommt bei dieser Rechnung heraus? Dafür extra eine Datei anzulegen, wäre Verschwendung. Innerhalb einer Sitzung merkt sich die REPL sogar Ihre Werte, sodass Sie schrittweise ausprobieren können.

15:03 Alles, was Bestand haben soll, gehört dagegen in eine Datei — nur die lässt sich versionieren, testen und mit anderen teilen. Die Faustregel ist simpel: Ausprobieren in der REPL, Entwickeln in der Datei. Dieses Beispiel zeigt zweimal fast dasselbe — und genau darin liegt der Punkt. Oben passiert alles interaktiv: Sie tippen eine Zeile, sehen die Ausgabe, tippen die nächste.

15:26 Unten steht derselbe Gedanke in einer Datei, die Sie mit einem einzigen Befehl starten. Der Code ist identisch, der Arbeitsmodus ist es nicht. Was Sie an Sprachmitteln hier sehen — eine Variable anlegen, zwei Texte zusammenfügen, etwas ausgeben — schauen wir uns im nächsten Modul in Ruhe an. Für heute zählt nur eines: Der Code läuft, und Sie haben ihn selbst gestartet.

15:50 Gehen Sie beide Wege einmal bewusst: dieselbe Ausgabe zuerst in der REPL erzeugen, dann aus einer Datei heraus mit node und dem Dateinamen. Der Nachweis ist schnell erbracht. Der eigentliche Teil der Aufgabe ist der zweite: Nennen Sie je einen Fall, für den Sie den jeweiligen Weg wählen würden. Wer das begründen kann, hat den Unterschied verstanden und nicht nur nachvollzogen.

16:12 Praktischer Hinweis zum Schluss: Aus der REPL kommen Sie mit einem Punkt-exit heraus oder mit zweimal Strg und C. Zwei dieser Fehler treffen fast jeden am ersten Tag, und beide sehen schlimmer aus, als sie sind. Die vergessene Dateiendung führt dazu, dass Node die Datei nicht findet — die Meldung klingt dramatisch, gemeint ist nur ein fehlendes Punkt-js.

16:34 Fast gleich sieht es aus, wenn Sie im falschen Ordner stehen; ein Blick auf das aktuelle Verzeichnis klärt das sofort. Der dritte Punkt ist eine Erwartungsfrage: Die REPL vergisst alles beim Beenden, und das ist kein Mangel, sondern ihre Natur. Deshalb der letzte Rat — größere Programme entstehen in Dateien, nicht in der REPL.

Erster Blick in den Debugger

16:53 Zum Abschluss noch ein Werkzeug, das viele erst viel zu spät entdecken. Wir schauen es uns heute nur kurz an — ein eigenes Modul zum Debugging kommt später im Kurs. Aber der erste Kontakt lohnt sich jetzt schon. Ein Haltepunkt ist so etwas wie eine Pausetaste für Ihr Programm — gesetzt an einer Zeile Ihrer Wahl. Erreicht die Ausführung diese Stelle, hält sie an, bevor die Zeile ausgeführt wird.

17:17 Und dann geschieht das Eigentliche: Der Editor zeigt Ihnen, welche Werte in diesem Moment existieren und welche noch nicht. Aus einem Programm, das sonst in Millisekunden durchrauscht, wird ein Standbild, in dem Sie sich umsehen können. Wer einmal erlebt hat, wie viel Ratelei damit wegfällt, mag nicht mehr zurück zu reinen Textausgaben.

17:37 Der Unterschied lässt sich in einem Satz sagen: Ausgaben zeigen Ergebnisse, der Debugger zeigt den Weg dorthin. Wenn am Ende eine falsche Zahl steht, hilft es wenig zu wissen, dass sie falsch ist — interessant ist, an welcher Stelle sie es geworden ist. Das schrittweise Ausführen deckt zudem etwas auf, das man mit Ausgaben kaum findet: falsche Annahmen über die Reihenfolge.

17:59 Man glaubt zu wissen, was wann passiert, und sieht dann etwas anderes. Und das Beste daran: Diese Technik ändert sich nicht. Sie trägt vom ersten Skript bis zur großen Anwendung. Die fünf Schritte folgen einer einfachen Dramaturgie: anhalten, hineinschauen, weitergehen. Der Haltepunkt entsteht mit einem Klick links neben der Zeilennummer.

18:20 Beim Start wählen Sie Node.js als Umgebung — der Editor kann auch Browser debuggen, deshalb die Nachfrage. Dann kommt der Moment, um den es geht: Im Variablen-Bereich sehen Sie den Zustand vor dieser Zeile. Mit „Step Over" führen Sie genau eine Zeile aus und schauen erneut hin; der Unterschied zwischen beiden Blicken ist die eigentliche Erkenntnis.

18:41 Legt der Editor dabei eine Konfigurationsdatei an, ist das normal — sie beschreibt nur, wie gestartet wird. Diese Übung macht etwas sichtbar, das man sonst nur vermutet. Setzen Sie zwei Haltepunkte — einen vor einer Zuweisung, einen vor der Ausgabe — und zeigen Sie dann eine Variable, die am ersten Punkt noch nicht existiert und am zweiten einen Wert hat.

19:02 Es geht nicht darum, einen Fehler zu finden. Es geht darum, den Programmzustand einmal beobachtet statt erraten zu haben. Genau dieser Perspektivwechsel ist der Grund, warum wir den Debugger nicht ans Ende des Kurses stellen, sondern schon an den Anfang. Der häufigste Anfängerfehler ist der Haltepunkt an der falschen Stelle: eine Zeile zu tief gesetzt, und der interessante Moment ist schon vorbei.

19:26 Setzen Sie ihn lieber vor die Zeile, die Sie verstehen wollen. Verwechseln lassen sich auch die beiden Schritt-Befehle — „Step Into" führt Sie in fremde Funktionen hinein, was schnell in Bibliothekscode endet, in dem Sie nichts verloren haben. Und noch eine Erwartungskorrektur: Eine Variable ist erst gesetzt, wenn ihre Zeile fertig gelaufen ist, nicht davor. Wer das einmal gesehen hat, sucht danach anders.

Geschafft — der erste Code läuft

19:49 Halten wir fest, was Sie jetzt mitnehmen. JavaScript ist die Sprache, Node.js die Umgebung, in der wir sie ausführen — und diese Trennung erklärt später viele Überraschungen. Kompatibilität ist immer eine Frage an die konkrete Umgebung, nie an eine Jahreszahl. Die REPL ist zum Ausprobieren da, die Datei für alles, was bleiben soll.

20:09 Und Sie haben eine Umgebung, in der Sie tatsächlich arbeiten können. Im nächsten Modul geht es an das Material selbst: Syntax, Variablen und die primitiven Datentypen — die Bausteine, aus denen alles Weitere entsteht.