Eigenschaften von Node.js 26, die schrittweise jahrelange Workarounds ersetzen
Funktionen von Node.js 26, die alte Workarounds ersetzen: die Temporal-API für Datumsverarbeitung, native Ausführung von TypeScript, eingebaute Cache-Hilfsfunktionen sowie einige kleinere Ergänzungen.
1. Wir können endlich aufhören, so zu tun, als wäre Date eine echte Datum-API
Hier ist etwas völlig gewöhnlicher JavaScript-Code:
const date = new Date("2026-09-08");
console.log(date);
Probieren Sie nun, eine etwas schwierigere Frage zu beantworten:
Welches ist das lokale Datum eines Treffens in New York?
Oder:
Fügen Sie drei Monate zu diesem Rechnungsdatum hinzu.
Oder:
Was ist eigentlich der Unterschied zwischen einem Kalendertag und einem genauen Zeitpunkt?
Dort fängt Date an, Probleme zu machen.
Deshalb ist Temporal so wichtig.
Node.js 26 aktiviert die Temporal-API standardmäßig und bietet JavaScript endlich klare Konzepte für Instanzen, Kalendertage, Dauerangaben und Zeitzonen.
Anstelle davon, Folgendes zu schreiben:
const date = new Date();
können Sie jetzt Folgendes schreiben:
const today = Temporal.Now.plainDateISO();
const invoiceDate =
Temporal.PlainDate.from("2026-09-08");
const dueDate =
invoiceDate.add({ days: 30 });
Und wenn Sie tatsächlich einen genauen Zeitpunkt statt eines Kalendertags benötigen:
const now = Temporal.Now.instant();
Dieser Unterschied ist wichtiger, als es auf den ersten Blick scheint.
Ein Abrechnungssystem benötigt eigentlich nicht „ein JavaScript-Dateiobjekt“.
Es braucht einen Kalendertag.
Ein verteiltes Ereignisprotokoll benötigt nicht „einen Kalendertag“.
Es braucht einen Zeitpunkt.
Temporal zwingt einen dazu, klar zu machen, welchen Zeitwert man tatsächlich meint.
Für alles, was mit Zahlungen, Abonnements, Buchungen, Märkten oder Benutzern in verschiedenen Zeitzonen zu tun hat, handelt es sich dabei nicht nur um eine ansprechendere Syntax.
Es schließt ganze Kategorien von Fehlern aus, bei denen man letztendlich den falschen Zeitwert verwendet.
2. Ihre .ts-Datei benötigt nicht unbedingt einen Build-Schritt
Jahrelang bedeutete die Ausführung von TypeScript in Node diesen Ablauf:
app.ts
↓
TypeScript
↓
app.js
↓
Node
Dieser Workflow ist nach wie vor völlig gültig.
Aber Node kann jetzt TypeScript-Dateien direkt ausführen, solange sie nur eine lösbare Syntax verwenden.
Nehmen wir diese Datei:
interface User {
id: number;
name: string;
}
function greet(user: User) {
return `Hello ${user.name}`;
}
console.log(
greet({
id: 1,
name: "Priyanshu"
})
);
Man kann sie direkt mit folgendem Befehl ausführen:
node app.ts
Node entfernt einfach die Typangaben und führt den verbleibenden reinen JavaScript-Code aus.
Es gibt einen wichtigen Punkt, den man wiederholen sollte: Node überprüft keine Typen für Sie.
Daher wird man in großen Produktionscodebasen weiterhin tsc oder einen äquivalenten Typüberprüfungs-Schritt in seinem Workflow benötigen.
Aber denken Sie an kleinere Fälle: ein internes Skript, ein schnelles CLI-Tool oder eine Einzeldatei-Utility.
Der alte Ansatz sah so aus:
script.ts
↓
configure compiler
↓
compile
↓
run
Nun kann er so aussehen:
script.ts
↓
node
Es handelt sich um eine kleine Veränderung.
Aber es ist ein weiteres Beispiel dafür, wie Node stillschweigend eine Schicht entfernt, die viele Projekte ursprünglich gar nicht wirklich benötigt haben.
3. Ihr Cache-Code wird allmählich unnötig kompliziert aussehen
Sie haben dieses Muster mit ziemlicher Sicherheit öfter geschrieben, als Sie zählen können:
let user = cache.get(userId);
if (user === undefined) {
user = await fetchUser(userId);
cache.set(userId, user);
}
An diesem Code ist nichts falsch.
Aber die eigentliche Absicht geht unter den Mechanismen des Überprüfens, Abrufens und Speicherns verloren.
Was Sie eigentlich sagen wollen, ist:
Geben Sie mir diesen Wert. Wenn er noch nicht vorhanden ist, erstellen Sie ihn.
Moderne JavaScript-Implementierungen ermöglichen es Ihnen nun, genau das auszudrücken.
V8 14.6, das im Rahmen von Node.js 26 mitgeliefert wird, fügt hinzu:
Map.prototype.getOrInsert()
Map.prototype.getOrInsertComputed()
Mit diesen Funktionen kann ein synchroner Cache-Abruf auf etwas wie folgendes vereinfacht werden:
const value = cache.getOrInsert(
key,
createValue()
);
Und wenn der Wert nur verzögert, auf Anfrage berechnet werden soll:
const value = cache.getOrInsertComputed(
key,
() => createValue()
);
Niemandes dieser Funktionen ist für sich genommen eine bahnbrechende Neuerung.
Doch die Entwicklung einer Sprache macht selten Fortschritte durch bahnbrechende Funktionen.
Sie macht Fortschritte, wenn genügend Entwickler immer wieder dieselben fünf Zeilen schreiben, bis die Sprache schließlich reagiert mit:
">In Ordnung. Sie müssen diese fünf Zeilen nicht mehr schreiben."
Genau diese Art von Erweiterung fügt sich leise in den alltäglichen Code ein.
In einem Jahr wird kaum noch jemand darüber sprechen.
Sie werden sie einfach ohne weiteres Nachdenken verwenden.
4. Node.js kann nun unter JavaScript liegen
Diese nächste Fähigkeit hat weitaus größeres Gewicht.
Node.js 26 bringt eine experimentelle Foreign Function Interface mit:
node:ffi
FFI ermöglicht es JavaScript, Funktionen aufzurufen, die von nativen Bibliotheken direkt bereitgestellt werden.
So sieht die grobe Struktur aus:
JavaScript
↓
node:ffi
↓
Native library
↓
C / C++ / system APIs
Stellen Sie sich eine native Bibliothek vor, die etwas wie Folgendes bietet:
double calculate(double value);
JavaScript kann nun, zumindest in Theorie, diese Bibliothek laden und die Funktion direkt aufrufen.
Das eröffnet Möglichkeiten wie:
- spezialisierte numerische Berechnungen
- Wiederverwendung bestehender native Bibliotheken
- tiefergehende Systemintegration
- Kryptografie auf nativer Ebene
- Bild- und Videobearbeitung
Aber es gibt eine ernste Einschränkung.
Man überschreitet dabei die Grenze zwischen verwaltetem JavaScript und roher nativer Speicherung.
Falscht man die Funktionssignatur an, erhält man keine höfliche JavaScript-Exception als Reaktion.
Dadurch kann der gesamte Prozess zusammenbrechen.
Genau deshalb bleibt diese API experimentell und ist hinter einem Schalter verborgen.
Achten Sie also nicht darauf, dies als…
„Es ist an der Zeit, jedes npm-Paket in C umzuschreiben.“
Lesen Sie es lieber so:
„Node bietet nun einen viel direkteren Weg in das Gebiet der nativen Programmierung.“
Das sind zwei völlig unterschiedliche Aussagen.
5. Ihre Node CLI benötigt vielleicht gar kein installiertes Node
Hier ist eine weitere Annahme, die in Frage gestellt werden sollte:
Falls Sie ein Tool mit Node entwickeln, müssen auch Ihre Nutzer Node installiert haben.
Einfache ausführbare Anwendungen widersprechen dieser Annahme.
Nodes SEA-Tooling ermöglicht es Ihnen, eine Anwendung als eigenständiges Binärdatei zu verpacken.
Anstatt also Folgendes zu liefern:
npm install
node index.js
können Sie etwas Ähnliches wie Folgendes liefern:
./my-cli
Betrachten Sie ein internes Tool, auf das Ihr Team täglich angewiesen ist.
Das könnte eine Deployment-CLI sein:
deploy production
oder ein Datenbank-Hilfsprogramm:
db-migrate
oder ein Projekt-Scaffolding-Tool:
project init
Falls Sie ein einzelnes ausführbares Programm bereitstellen, müssen die Benutzer nicht wissen oder sich darum kümmern, dass dahinter JavaScript läuft.
Das verändert subtil das Selbstbild von Node.
Node entstand ursprünglich als:
JavaScript, das außerhalb des Browsers läuft.
Es beginnt zunehmend wie folgt auszusehen:
Ein Mehrzweck-Anwendungs-Runtime, der zufällig JavaScript ausführt.
Das ist eine weitaus größere Behauptung.
6. Was passiert, wenn Ihre Anwendung nicht mehr alle Berechtigungen benötigt?
Sicherheitsmodelle folgen in der Regel diesem Muster:
Application
↓
Gets permissions
↓
Keeps permissions
↓
Runs
Aber was ist, wenn eine Berechtigung nur kurzzeitig während des Startvorgangs benötigt wird?
Nehmen Sie einen Dienst, der bei seiner Initialisierung eine Konfigurationsdatei sowie einige Zertifikate liest.
Sobald es läuft, benötigt es möglicherweise überhaupt keinen weiteren Zugriff auf das Dateisystem mehr.
Das Berechtigungsmodell von Node zielt darauf ab, Anwendungen zu ermöglichen, ihre eigenen Fähigkeiten während des Laufs über APIs wie permission.drop() aktiv einzuschränken.
Der Ablauf sieht dann so aus:
Start
↓
Read configuration
↓
Initialize
↓
Drop unnecessary permissions
↓
Run
Das spiegelt ein nützliches Sicherheitsprinzip wider:
Fragen Sie nicht nur, was Ihre Anwendung tun darf. Fragen Sie stattdessen, welche Berechtigungen sie künftig tatsächlich noch benötigt.
Die Veränderung an der API-Oberfläche ist gering.
Der Wandel in der Denkweise bezüglich der Anwendungsicherheit ist es jedoch nicht.
7. Node.js ist endlich bereit, Dinge zu löschen
Das Hinzufügen von APIs ist der einfache Weg, um einen Laufzeitumfeld beeindruckend erscheinen zu lassen.
Ihre Entfernung ist der schwierige Teil.
Node.js 26 beseitigt weiterhin alte APIs sowie veraltete Interna, die bereits seit Jahren bestehen.
Das ist wichtiger, als es auf den ersten Blick scheinen mag.
Jede alte API wird früher oder später zu einer unvermeidlichen Abhängigkeit für jemanden.
Wird sie unkontrolliert gelassen, muss der Laufzeitumgebung jahrzehntelang angesammelte „historische Last“ mitgeschleppt werden:
old API
+
new API
+
replacement API
+
deprecated API
+
"don't use this anymore" API
Eine ausgereifte Plattform benötigt die Bereitschaft, diese Ansammlung zu reduzieren.
Node.js zeigt zunehmend genau diese Bereitschaft.
Das sind gute Nachrichten, wenn man nicht jedes veraltete Vorgehen zum Ausführen derselben Aufgabe auswendig lernen möchte.
Der interessante Teil ist keine einzelne Funktion
Temporal ist für sich genommen nicht besonders auffällig.
Ebenso wenig wie getOrInsert().
Auch das Ausführen einer .ts-Datei ohne Build-Schritt ist es nicht.
Ebenso wenig wie das Verpacken einer CLI als ausführbares Programm.
Doch wenn man sie nebeneinander stellt...
Erhöht Node gleichzeitig die Abstraktion aufwärts:
Temporal
Better collections
TypeScript
Modern JavaScript
während es gleichzeitig auch abwärts vordringt:
FFI
Native libraries
Permissions
Executable packaging
Das ist die eigentliche Geschichte hier.
Node.js wird nicht nur immer besser darin, JavaScript auszuführen.
Es entwickelt sich zu einer besseren Laufzeitumgebung für alles, was mit der Anwendung zusammenhängt.
Das verändert die Frage, die man am Anfang eines neuen Projekts stellen sollte.
Anstatt direkt zu:
"Welches npm-Paket brauche ich dafür?"
ist es zunehmend sinnvoll, zuerst zu fragen:
">Kann Node.js das bereits?"
Mannchmal lautet die ehrliche Antwort immer noch nein.
Aber immer öfter ist die Antwort:
">Eigentlich... ja."
Das ist wohl das Auffälligste an Node.js 26.
Die Laufzeitumgebung hat bereits Fortschritte gemacht.
Unsere mentalen Modelle haben einfach noch nicht mitgehalten.