Node.js LTS in 2026: waarom runtime-stabiliteit wint

De belangrijkste Node.js-aankondiging van 2026 heeft geen enkele benchmarkgrafiek erbij. In maart bevestigde het project dat vanaf Node.js 27 elke major versie Long Term Support krijgt - een wijziging in de planning, geen feature. En in een jaar waarin Bun en Deno steeds snellere runtimes blijven uitbrengen, is die saaie planningswijziging misschien wel de sterkste concurrerende zet die welke JavaScript-runtime dan ook heeft gedaan.

Elke Node-major wordt LTS: de planningswijziging van maart 2026

Node.js neemt afscheid van het tien jaar oude model waarin oneven releases een kort leven beschoren waren. Vanaf Node.js 27 gaat elke major versie na de Current-fase over naar LTS, met ongeveer 30 maanden ondersteuning, volgens de officiële aankondiging over de evolutie van het releaseschema. De genoemde reden is helder: oneven releases werden nauwelijks geadopteerd omdat organisaties simpelweg op LTS wachtten. Het experiment met twee sporen werkte prima als oefenterrein - Temporal, V8-upgrades, Undici-updates en API-verwijderingen werden allemaal eerst op de Current-lijn getest voordat productiegebruikers ermee te maken kregen - maar de "wegwerp"-majors met oneven nummers creëerden een versie die niemand daadwerkelijk uitrolde.

De huidige stand van zaken per juli 2026, volgens de officiële Node.js-releasepagina:

Waarom dit belangrijk is: Node heeft zojuist tegen elk platformteam ter wereld gezegd "u kunt uw runtime-upgrades voor de komende vijf jaar op een kalender inplannen", en geen enkele concurrerende runtime kan dat geloofwaardig beweren.

De cijfers zeggen: saai wint - 90% vs 21% vs 11%

De runtime-oorlog heeft een scorebord, en het is eenzijdig. De State of JavaScript 2025-enquête zet Node.js op ruwweg 90% van de runtime-respondenten (10.062 van de 11.141), met Bun op ~21% en Deno op ~11%. De Stack Overflow-enquête van 2025 laat zien dat Node.js de gehele webtechnologie-categorie aanvoert met 49,1%, vóór React met 46,9%.

Wat vaak over het hoofd wordt gezien: die cijfers van Bun en Deno zijn sterk vertekend richting ontwikkeling en tooling, niet productieverkeer. De groei van Bun is reëel waar prestaties en toolingconsolidatie ertoe doen - testrunners, bundling, lokale ontwikkelservers - maar ondernemingen blijven voorzichtig vanwege het snel veranderende API-oppervlak en het kleinere ecosysteem.

De tegendraadse lezing: dit is niet Node dat op puur verdienste wint. Het is Node dat wint op overstapkosten plus voorspelbaarheid. Wanneer uw runtime een ondersteuningscontract van 30 maanden meedraagt, is "iets langzamer dan Bun" een afrondingsfout tegenover "we hoeven onze runbooks niet elk kwartaal te herschrijven".

Waarom dit belangrijk is: De runtimekeuze in 2026 is een beslissing over operationeel risico, en 90% van de markt heeft al gestemd over welk risicoprofiel acceptabel is.

Node 24 bewijst dat discipline geen stagnatie is

Node 24 "Krypton" is de eerste LTS in meerdere cycli waarin wijzigingen op taalniveau alledaagse code hervormen. De blikvanger is await using, expliciet resourcebeheer dat opruimlogica rechtstreeks in de taal verankert:

javascriptCopy
// Before: manual cleanup, easy to leak on early return or throw
async function query(pool, sql) {
  const conn = await pool.acquire;
  try {
    return await conn.query(sql);
  } finally {
    await conn.release;
  }
}

// Node 24: the connection disposes itself when scope exits
async function query(pool, sql) {
  await using conn = await pool.acquire;
  return await conn.query(sql);
}

De await using-declaratie roept automatisch de [Symbol.asyncDispose]-methode van het object aan zodra de scope eindigt - ook bij excepties en vroegtijdige returns. Dat try/finally-patroon dat het vervangt, is precies waar connectielekken in echte codebases vandaan komen: iemand voegt een tweede return-pad toe, vergeet dat het finally-blok dat moet afdekken, en drie weken later loopt de pool onder belasting leeg. Door het opruimen naar de taal te verplaatsen, verdwijnt de hele bugcategorie, niet alleen de individuele bug.

Node 24 levert ook een ingebouwde URLPattern-API mee, die een einde maakt aan de zelfgeschreven regex-routing die jarenlang path-traversal- en ReDoS-bugs in Express- en Fastify-middleware heeft veroorzaakt. Voeg daar V8 13.6, npm 11, Undici 7 en verbeteringen aan het Permission Model aan toe volgens de releasenotities van Node.js 24.0.0, en de "conservatieve" release blijkt behoorlijk wat om het lijf te hebben.

Waarom dit belangrijk is: Nieuwe functies van Node komen binnen via conservatieve releasepoorten in plaats van constante verandering, waardoor uw team await using en URLPattern krijgt met een compatibiliteitscontract erbij.

TypeScript type stripping is stabiel en dicht stilletjes het gat met Deno

Node kan nu rechtstreeks TypeScript-bestanden uitvoeren. Type stripping - het uitvoeren van .ts-bestanden door type-annotaties te wissen zonder transpilatie - werd stabiel in v25.2.0 en v24.12.0, waarbij de experimentele waarschuwingen al vanaf v22.18.0 en v24.3.0 verdwenen, volgens de officiële TypeScript-documentatie.

bashCopy
# No flags, no loaders, no ts-node. Just:
node app.ts

Dit was het oorspronkelijke verkoopargument van Deno en een van de sterkste ergonomische troeven van Bun. Node heeft het op zijn eigen manier overgenomen: langzaam, achter experimentele flags, verspreid over drie major versies, totdat de semantiek vaststond. In combinatie met verbeterde CommonJS/ESM-interoperabiliteit verliest het oude argument "Node is lastig op te zetten" zijn laatste tanden.

Het is belangrijk om op te merken wat type stripping bewust niet doet: types controleren. Types worden gewist, niet geverifieerd, dus u heeft nog steeds tsc --noEmit nodig in CI. Als u het volledige toolchainplaatje evalueert, telt ook de compilersnelheid mee - zie hoe de 11,9x snellere compilatie van TypeScript 7.0 de buildstrategie verandert voor de andere helft van die vergelijking.

Waarom dit belangrijk is: Elk ergonomisch voordeel dat Bun en Deno hadden, wordt in Node opgenomen zonder één bestaand project te breken - wat de hele LTS-these in het klein is.

Beveiligingsdiscipline is nu onderdeel van het releasecontract

Februari 2026 bracht nieuwe eisen voor beveiligingsrapportage, naast de releases v24.14 LTS en v25.7.0. Daarachter zit een jaar aan structureel werk, gedocumenteerd in het OpenJS Security Annual Report 2025: een OpenJS CVE Numbering Authority, geautomatiseerde workflows voor Node.js-beveiligingsreleases en formele incident-responseplannen.

De context maakt dit urgent in plaats van bureaucratisch. Een npm supply-chain-aanval in september 2025 trof packages met samen ruim 2 miljard wekelijkse downloads, en de Shai-Hulud-campagne compromitteerde meer dan 180 packages, met aanvullende golven die doorliepen tot in 2026. Het npm-ecosysteem is tegelijkertijd Node's grootste troef en zijn grootste aanvalsoppervlak. Het Permission Model van Node - dat toegang tot het bestandssysteem, netwerk en child processes op runtimeniveau beperkt - is het directe technische antwoord, en de voortgezette verharding ervan in Node 24 verandert "het beveiligingsmodel van Deno is beter" van een doorslaggevend argument in een krimpend argument.

Waarom dit belangrijk is: Voorspelbare, geautomatiseerde beveiligingsreleases maken het verschil tussen "patchen op dinsdagochtend" en "spoedoverleg met het hele team", en Node heeft nu de institutionele machinerie voor het eerste.

De echte bedreiging is verouderde Node, niet Bun of Deno

Hier komt de ongemakkelijke statistiek: ruwweg twee derde van de Node.js-gebruikers draait verouderde of niet-ondersteunde versies, volgens de OpenJS Foundation. Die bevinding leidde in maart 2026 tot de lancering van het Node.js LTS Upgrade and Modernization Program, met NodeSource als eerste partner.

De kosten van het negeren van de releasecadans zijn niet abstract. Volgens de officiële Node.js EOL-pagina draagt Node 20 "Iron" na EOL al 27 hoge, 24 middelhoge en 9 lage ongepatchte kwetsbaarheden met zich mee. Node 18 staat op 15 hoge, 19 middelhoge en 4 lage. Die aantallen groeien alleen maar, en ze komen gebundeld met kapotte toolchains en rode vlaggen bij compliance-audits.

Dit zet de taaloorlogen in een compleet ander licht. Het stabiliteitsvoordeel van Node is niet vanzelfsprekend - het is een contract dat alleen uitbetaalt als uw team zijn deel nakomt door op Active of Maintenance LTS te blijven. Een Node 18-uitrol in 2026 heeft niets van de beveiligingshouding, niets van de prestatiewinst, en wel al het auditrisico.

Waarom dit belangrijk is: De grootste concurrent van Node in 2026 is oude Node, en twee derde van het ecosysteem is daar momenteel aan het verliezen.

Concurrenten kopiëren het draaiboek, en daarmee is de discussie beslecht

Het sterkste bewijs dat LTS-discipline wint, is niet het marktaandeel van Node - het is wat de uitdagers doen. Deno introduceerde LTS-releases in Deno 2.x, specifiek voor teams die een stabiele productiebasis nodig hebben. Wanneer uw onderscheidend vermogen "wij bewegen snel en repareren de fouten van Node" was en uw roadmap nu "long-term support-vensters" bevat, dan heeft de markt gesproken over wat productiekopers daadwerkelijk kopen.

Bun blijft winnen in de categorieën waar pure snelheid en toolingconsolidatie domineren: lokale ontwikkeling, testuitvoering, CI-pipelines. Dat is een oprecht sterke positie. Maar ondernemingen die Bun evalueren voor productieverkeer noemen steevast dezelfde bezwaren - een kleiner ecosysteem, een snel veranderend oppervlak, geen equivalent van een ondersteuningstoezegging van 30 maanden.

De eerlijke framing voor 2026: Bun en Deno duwen de categorie JavaScript-runtimes vooruit, en Node neemt de beste ideeën over op LTS-tempo. Python groeit via AI-workloads, Rust en Go trekken systeemontwikkelaars aan, maar productie-JavaScript blijft zich consolideren op de runtime met compatibiliteitscontracten, ondersteuning door cloudproviders, npm-integratie en vertrouwdheid op de arbeidsmarkt.

Waarom dit belangrijk is: Wanneer elke uitdager LTS-programma's begint uit te rollen, is "stabiliteit als killerfeature" niet langer de mening van Node, maar de consensus van de sector.

Het volgen waard

• Node 26 dat in oktober 2026 LTS wordt - let op of het nieuwe elke-major-LTS-model de enterprise-adoptie van zowel even als oneven releases versnelt
• De release van Node.js 27 onder het nieuwe schema - de eerste major die de belofte "elke versie krijgt 30 maanden" test
• Adoptiecijfers van het LTS Upgrade and Modernization Program - of het cijfer van twee derde verouderd daadwerkelijk beweegt in het volgende OpenJS-rapport
• De reactie van Bun op de LTS-consensus - een Bun LTS-aankondiging zou de these volledig bevestigen
• Adoptie van het Permission Model in productie - de volgende golf npm supply-chain-incidenten zal testen of runtime-sandboxing echt terrein wint

Wat u nu kunt doen

Begin hier (uw eerste stap) Draai vandaag node --version op elke productieservice. Alles onder 22 is uw prioriteit; alles op 20 of 18 is een actief beveiligingsrisico volgens de EOL-kwetsbaarheidstellingen.

Snelle winst (direct effect)

• Voeg deze week een CI-testmatrix toe die Node 22, 24 en 26 dekt in uw belangrijkste repositories, zodat de uiteindelijke overstap naar Node 24 een configuratiewijziging is in plaats van een project
• Dwing lockfiles af in CI (npm ci, nooit npm install) en schakel waar mogelijk --ignore-scripts in voor installaties, gezien de lopende supply-chain-campagnes

Verdieping (voor wie meer wil)

• Test het Permission Model van Node 24 (--permission met expliciete --allow-fs-read- en --allow-net-toekenningen) op één niet-kritieke service en documenteer wat er stukgaat
• Refactor één connection-pool- of file-handle-module naar await using met [Symbol.asyncDispose], en meet vervolgens of lekgerelateerde incidenten het kwartaal daarna afnemen

Nuttige bronnen

• Node.js Release Schedule - Officiële LTS-status en ondersteuningstijdlijnen voor elke versie
• Evolving the Node.js Release Schedule - De aankondiging van maart 2026 die elke major naar LTS brengt
• Node.js 24.0.0 Release Notes - Alle details over V8 13.6, npm 11, Undici 7 en de wijzigingen aan het Permission Model
• Node.js TypeScript Support - Officiële documentatie over native type stripping
• OpenJS Security Annual Report 2025 - De lancering van de CNA en de automatisering van beveiligingsreleases

Wat dit voor u betekent

De runtimekeuze van 2026 draait niet om syntax of benchmarks. Het draait om welk platform u risico laat inplannen in plaats van absorberen, en het antwoord van Node - jaarlijkse LTS voor elke major, ondersteuningsvensters van 30 maanden, geautomatiseerde beveiligingsreleases en functies die vooraf gehard binnenkomen - is momenteel het enige complete antwoord in JavaScript.

De actie is even helder: het voordeel bestaat alleen voor teams die de cadans volgen. Behandel runtime-upgrades als gepland platformwerk per kwartaal, houd productie op Active of Maintenance LTS, en test tegen Current, zodat de LTS-overgang van Node 26 in oktober een non-event is. In een jaar dat wordt getekend door supply-chain-aanvallen en runtimefragmentatie, is het minimaliseren van verrassingen waarschijnlijk de waardevolste feature die welke runtime dan ook levert.