De auteur beschrijft de overstap van de Deno-runtime terug naar Node.js. In het artikel wordt benadrukt dat Node.js inmiddels sterk gemoderniseerd is, met betere ondersteuning voor ECMAScript en vernieuwde API's.
Belangrijke punten uit het artikel zijn:
- Pakketbeheer: De auteur gebruikt FNM voor versiebeheer en PNPM als veiliger alternatief voor NPM, inclusief specifieke configuraties om malware-updates te vertragen.
- TypeScript: Er wordt ingegaan op de native TypeScript-ondersteuning in Node.js en de filosofische beperkingen omtrent het strippen van types in
node_modules.
- Migratie: De auteur heeft een static site generator gemigreerd van Deno naar Node.js (met Hono), wat resulteerde in builds die 15% sneller zijn.
- Kritiek op Deno: De auteur concludeert dat Deno is gestopt met innoveren en noemt specifieke technische bugs (ZSH-integratie, JSR-fouten en HTTP-problemen) als reden voor de definitieve uninstall.
Vriendschap met Deno beëindigd, Node is nu mijn beste vriend
Ik heb Node deze maand intensief gebruikt voor een SvelteKit-clientproject. Wanneer is Node zo goed geworden<0xE2><0x80><0xBD> Deno was zo lang mijn standaard runtime dat ik was vergeten hoe ik met Node moest werken. Nu ik terug ben, merk ik dat alle ECMAScript-versieringen¹ worden ondersteund en dat de oude, irritante API's zijn vervangen of gemoderniseerd. Het belangrijkste is dat ik require() nooit meer hoef te zien.
¹ Het lijkt erop dat het handelsmerkconflict met Oracle niet tot een positieve uitkomst zal leiden :(
Pakketbeheer
De officiële Node-documentatie raadt aan om een internetscript direct naar bash te pipen (we leren het nooit) om NVM te installeren voor het beheer van Node & NPM. Mijn (oude) ervaring met NVM en NPM was niet optimaal. Ik hoorde dat Fast Node Manager (FNM) beter was voor het wisselen van Node-versies. Hoewel ik zelf altijd de nieuwste versies gebruik, heb ik clientprojecten die stabiliteit vereisen.
Ik heb ook gekozen voor PNPM om te voorkomen dat ik direct gehackt word. (De "M" in NPM staat voor "malware"). Sommige scripts die ik gebruik hebben hardgecodeerde binary-namen², dus ik heb twee aliassen toegevoegd:
alias npm=pnpm
alias npx=pnpx
Misschien is dat een misdaad, maar tot nu toe heeft het vlekkeloos gewerkt.
² Aanvulling: Ik verwar dit mogelijk met de keer dat ik verschillende binaries symlinkte. De aliassen helpen wel bij het kopiëren van stappen uit installatiehandleidingen die ervan uitgaan dat NPM is geïnstalleerd.
PNPM blokkeert bovendien post-install scripts. Doet NPM die nog steeds zomaar?
Ik heb extra instellingen toegevoegd aan pnpm-workspace.yaml om malware-updates te vertragen:
minimumReleaseAge: 1440
trustPolicy: no-downgrade
In eerste instantie probeerde ik de minimale release-leeftijd op "één maand" te zetten, omdat Microsoft minstens zo lang nodig heeft om gemelde malware te verwijderen. Dit veroorzaakte echter afhankelijkheidsproblemen waarbij PNPM moeite had om geschikte versies te vinden. Ik ben uiteindelijke gestopt op "één dag"; lang genoeg om iemand anders het volgende Shai-Hulud te laten beta-testen.
TypeScript
Node kan nu TypeScript uitvoeren zonder een driftbui te krijgen als de sterren niet gunstig staan. Dat gezegd hebbende: men publiceert niet zomaar TypeScript-pakketten naar NPM.
error: [ERRUNSUPPORTEDNODEMODULESTYPESTRIPPING]: Stripping types is currently unsupported for files under nodemodules
Waarom? Strip gewoon de types, ik weet dat je het kunt! Laat me een pact met de duivel sluiten!
"Om pakketauteurs te ontmoedigen pakketten te publiceren die in TypeScript zijn geschreven, weigert Node.js TypeScript-bestanden in mappen onder een node_modules-pad te verwerken."
— Node.js v26.10.0 documentatie
Deze beperking is filosofisch in plaats van technisch. Ik begrijp het wel. TypeScript is een Microsoft-product. Die sluis openzetten zou het hele ecosysteem vervuilen. Niemand wil meer Microsoft. Ik zou graag lichte "native types" in ECMAScript zien. Er zijn voorstellen voor type-annotaties, maar ik vermoed dat ik met pensioen ben voordat die vruchten afwerpen.
Het ontbreken van TypeScript-pakketten betekent dat ik de nieuwste "churnware slop" moet vinden om mijn spullen te bundelen. tsdown deed de truc, met slechts twee extra dotfiles. Daar ben ik niet enthousiast over (elke dotfile vertegenwoordigt een fout). Ik supposeer dat ik quitte na het verwijderen van deno.json etc.
Over Microsoft-lock-in gesproken: omdat ze GitHub hebben verpest, host ik mijn eigen Forgejo-instantie. Door beperkingen van NPM zijn mijn pakketten hun "provenance" verloren. Ik moest de PNPM-trustpolicy configureren om mijn eigen werk toe te staan. Leuk is dat!
Mijn website migreren
Mijn laatste test voor Node was het converteren van mijn static site generator van Deno. Een paar Node-versies geleden zou dit een grote refactor hebben vereist. Vandaag, met Node v26.10.0, merkte ik dat er verrassend weinig werk aan te pas kwam.
De enige vereiste wijzigingen waren:
- Het vervangen van Deno’s file system API door
node:fs — wat enorm is verbeterd ten opzichte van wat ik me herinner (letterlijk ~10 jaar geleden).
- Het vervangen van
Deno.serve door de Node-adapter van Hono (een wrapper rond node:http).
Na deze minimale migratie was ik geschokt om te zien dat de builds 15% sneller waren. Mijn codebase geeft nog steeds de voorkeur aan idiomatisch Deno. Ik wed dat ik prestaties misloop door geen andere ingebouwde Node API's te gebruiken; dat is iets om later te onderzoeken. De enige verdere wijziging die ik maakte, was het vervangen van Deno’s @std/path door node:path, wat een eenvoudige import-swap is.
Kortom: Node heeft een enorme glow-up gehad!
Je wist dit waarschijnlijk al een tijdje. Ik bleef Deno gebruiken uit gewoonte en vertrouwdheid. En ik was onlangs niet bepaald enthousiast over het schrijven van server-side JavaScript.
De neergang van Deno
Ik zet dit deel onderaan omdat het een dood paard is dat ik aan het geselen ben. Uiteindelijk faalde Deno toen ze toelieten dat het "Silicon Valley Circus" definieerde wat "succes" is. Deno ging van een innovatieve, moderne JavaScript-runtime naar een saaie start-up met onovertuigende producten. De helft van de werknemers werd ontslagen en wie er overbleven, twieten over AI-fantasieën en "vibe-coding" voor een soort Temu-versie van Cloudflare.
Er is vandaag de dag geen reden meer om de Deno-runtime te gebruiken. Deno Land Inc. is jaren geleden gestopt met innoveren. Node heeft langzaam maar zeker ingehaald en Deno op sommige punten zelfs ingehaald.
Wat me uiteindelijk wegduwde was:
- Al wekenlang een kapotte ZSH-integratie;
- Agressieve "429 (Too Many Requests)" fouten bij JSR;
- Bug(s) waardoor Deno stikte op gelijktijdige HTTP-verzoeken.
In feite zaken die het bijna onbruikbaar maakten, bovenop mijn andere kritiek. De JSR-ondersteuning was erg snel in het verwijderen van mijn account op verzoek. Ik hou er niet van om dode profielen op het internet achter te laten. Geen van mijn pakketten is meer zichtbaar, hoewel oude versies installeerbaar blijven.
Het was in het begin leuk, maar nu is het tijd om afscheid te nemen.
brew uninstall deno
Vriendschap met Deno beëindigd, Node is nu mijn beste vriend
Ik heb Node deze maand intensief gebruikt voor een SvelteKit-clientproject. Wanneer is Node zo goed geworden<0xE2><0x80><0xBD> Deno was zo lang mijn standaard runtime dat ik was vergeten hoe ik met Node moest werken. Nu ik terug ben, merk ik dat alle ECMAScript-versieringen¹ worden ondersteund en dat de oude, irritante API's zijn vervangen of gemoderniseerd. Het belangrijkste is dat ik require() nooit meer hoef te zien.
¹ Het lijkt erop dat het handelsmerkconflict met Oracle niet tot een positieve uitkomst zal leiden :(
Pakketbeheer
De officiële Node-documentatie raadt aan om een internetscript direct naar bash te pipen (we leren het nooit) om NVM te installeren voor het beheer van Node & NPM. Mijn (oude) ervaring met NVM en NPM was niet optimaal. Ik hoorde dat Fast Node Manager (FNM) beter was voor het wisselen van Node-versies. Hoewel ik zelf altijd de nieuwste versies gebruik, heb ik clientprojecten die stabiliteit vereisen.
Ik heb ook gekozen voor PNPM om te voorkomen dat ik direct gehackt word. (De "M" in NPM staat voor "malware"). Sommige scripts die ik gebruik hebben hardgecodeerde binary-namen², dus ik heb twee aliassen toegevoegd:
alias npm=pnpm
alias npx=pnpx
Misschien is dat een misdaad, maar tot nu toe heeft het vlekkeloos gewerkt.
² Aanvulling: Ik verwar dit mogelijk met de keer dat ik verschillende binaries symlinkte. De aliassen helpen wel bij het kopiëren van stappen uit installatiehandleidingen die ervan uitgaan dat NPM is geïnstalleerd.
PNPM blokkeert bovendien post-install scripts. Doet NPM die nog steeds zomaar?
Ik heb extra instellingen toegevoegd aan pnpm-workspace.yaml om malware-updates te vertragen:
minimumReleaseAge: 1440
trustPolicy: no-downgrade
In eerste instantie probeerde ik de minimale release-leeftijd op "één maand" te zetten, omdat Microsoft minstens zo lang nodig heeft om gemelde malware te verwijderen. Dit veroorzaakte echter afhankelijkheidsproblemen waarbij PNPM moeite had om geschikte versies te vinden. Ik ben uiteindelijke gestopt op "één dag"; lang genoeg om iemand anders het volgende Shai-Hulud te laten beta-testen.
TypeScript
Node kan nu TypeScript uitvoeren zonder een driftbui te krijgen als de sterren niet gunstig staan. Dat gezegd hebbende: men publiceert niet zomaar TypeScript-pakketten naar NPM.
error: [ERRUNSUPPORTEDNODEMODULESTYPESTRIPPING]: Stripping types is currently unsupported for files under nodemodules
Waarom? Strip gewoon de types, ik weet dat je het kunt! Laat me een pact met de duivel sluiten!
"Om pakketauteurs te ontmoedigen pakketten te publiceren die in TypeScript zijn geschreven, weigert Node.js TypeScript-bestanden in mappen onder een node_modules-pad te verwerken."
— Node.js v26.10.0 documentatie
Deze beperking is filosofisch in plaats van technisch. Ik begrijp het wel. TypeScript is een Microsoft-product. Die sluis openzetten zou het hele ecosysteem vervuilen. Niemand wil meer Microsoft. Ik zou graag lichte "native types" in ECMAScript zien. Er zijn voorstellen voor type-annotaties, maar ik vermoed dat ik met pensioen ben voordat die vruchten afwerpen.
Het ontbreken van TypeScript-pakketten betekent dat ik de nieuwste "churnware slop" moet vinden om mijn spullen te bundelen. tsdown deed de truc, met slechts twee extra dotfiles. Daar ben ik niet enthousiast over (elke dotfile vertegenwoordigt een fout). Ik supposeer dat ik quitte na het verwijderen van deno.json etc.
Over Microsoft-lock-in gesproken: omdat ze GitHub hebben verpest, host ik mijn eigen Forgejo-instantie. Door beperkingen van NPM zijn mijn pakketten hun "provenance" verloren. Ik moest de PNPM-trustpolicy configureren om mijn eigen werk toe te staan. Leuk is dat!
Mijn website migreren
Mijn laatste test voor Node was het converteren van mijn static site generator van Deno. Een paar Node-versies geleden zou dit een grote refactor hebben vereist. Vandaag, met Node v26.10.0, merkte ik dat er verrassend weinig werk aan te pas kwam.
De enige vereiste wijzigingen waren:
- Het vervangen van Deno’s file system API door
node:fs — wat enorm is verbeterd ten opzichte van wat ik me herinner (letterlijk ~10 jaar geleden).
- Het vervangen van
Deno.serve door de Node-adapter van Hono (een wrapper rond node:http).
Na deze minimale migratie was ik geschokt om te zien dat de builds 15% sneller waren. Mijn codebase geeft nog steeds de voorkeur aan idiomatisch Deno. Ik wed dat ik prestaties misloop door geen andere ingebouwde Node API's te gebruiken; dat is iets om later te onderzoeken. De enige verdere wijziging die ik maakte, was het vervangen van Deno’s @std/path door node:path, wat een eenvoudige import-swap is.
Kortom: Node heeft een enorme glow-up gehad!
Je wist dit waarschijnlijk al een tijdje. Ik bleef Deno gebruiken uit gewoonte en vertrouwdheid. En ik was onlangs niet bepaald enthousiast over het schrijven van server-side JavaScript.
De neergang van Deno
Ik zet dit deel onderaan omdat het een dood paard is dat ik aan het geselen ben. Uiteindelijk faalde Deno toen ze toelieten dat het "Silicon Valley Circus" definieerde wat "succes" is. Deno ging van een innovatieve, moderne JavaScript-runtime naar een saaie start-up met onovertuigende producten. De helft van de werknemers werd ontslagen en wie er overbleven, twieten over AI-fantasieën en "vibe-coding" voor een soort Temu-versie van Cloudflare.
Er is vandaag de dag geen reden meer om de Deno-runtime te gebruiken. Deno Land Inc. is jaren geleden gestopt met innoveren. Node heeft langzaam maar zeker ingehaald en Deno op sommige punten zelfs ingehaald.
Wat me uiteindelijk wegduwde was:
- Al wekenlang een kapotte ZSH-integratie;
- Agressieve "429 (Too Many Requests)" fouten bij JSR;
- Bug(s) waardoor Deno stikte op gelijktijdige HTTP-verzoeken.
In feite zaken die het bijna onbruikbaar maakten, bovenop mijn andere kritiek. De JSR-ondersteuning was erg snel in het verwijderen van mijn account op verzoek. Ik hou er niet van om dode profielen op het internet achter te laten. Geen van mijn pakketten is meer zichtbaar, hoewel oude versies installeerbaar blijven.
Het was in het begin leuk, maar nu is het tijd om afscheid te nemen.
brew uninstall deno
Groetjes,