Software-update: Node.js 18.13.0 (LTS) / 19.4.0

Node.js is open source en platformonafhankelijk, en is gericht op het ontwikkelen van server-sidewebapplicaties. Die applicaties worden geschreven in JavaScript en uitgevoerd binnen de Node.js-runtime op de server. Het biedt een event-gedreven omgeving aan waarbij non-blocking i/o een belangrijk uitgangspunt is geweest. Voor meer informatie over Node.js verwijzen we naar deze pagina. Het ontwikkelteam heeft versies 18.13.0, een versie met extra lange ondersteuning, en 19.4.0 vrijgegeven. De belangrijkste veranderingen die in beide versies zijn aangebracht zijn hieronder voor je samengevat.

Node v18.13.0 (LTS) notable changes

Add support for externally shared js builtins

By default Node.js is built so that all dependencies are bundled into the Node.js binary itself. Some Node.js distributions prefer to manage dependencies externally. There are existing build options that allow dependencies with native code to be externalized. This commit adds additional options so that dependencies with JavaScript code (including WASM) can also be externalized. This addition does not affect binaries shipped by the Node.js project but will allow other distributions to externalize additional dependencies when needed. Contributed by Michael Dawson in #44376

Introduce File

The File class is part of the FileAPI. It can be used anywhere a Blob can, for example in URL.createObjectURL and FormData. It contains two properties that Blobs do not have: lastModified, the last time the file was modified in ms, and name, the name of the file. Contributed by Khafra in #45139

Support function mocking on Node.js test runner

The node:test module supports mocking during testing via a top-level mock object.

test('spies on an object method', (t) => {
  const number = {
    value: 5,
    add(a) {
      return this.value + a;
    },
  };
  t.mock.method(number, 'add');

  assert.strictEqual(number.add(3), 8);
  assert.strictEqual(number.add.mock.calls.length, 1);
});

Contributed by Colin Ihrig in #45326

Node v19.4.0 (Current) notable Changes

• buffer:
  • (SEMVER-MINOR) add buffer.isUtf8 for utf8 validation (Yagiz Nizipli) #45947
• http:
  • (SEMVER-MINOR) improved timeout defaults handling (Paolo Insogna) #45778
• net:
  • add autoSelectFamily global getter and setter (Paolo Insogna) #45777
• os:
  • (SEMVER-MINOR) add availableParallelism() (Colin Ihrig) #45895
• util:
  • add fast path for text-decoder fatal flag (Yagiz Nizipli) #45803

Versienummer	18.13.0 (LTS) / 19.4.0
Releasestatus	Final
Besturingssystemen	Windows 7, Linux, BSD, macOS, Windows Server 2008, Windows Server 2012, Windows 8, Windows 10, Windows Server 2016, Windows Server 2019, Windows 11
Website	Node.js
Download	https://nodejs.org/en/download/
Licentietype	GPL

Reacties (29)

[Gamebuster]

Ondertussen probeer ik anderen te overtuigen dat NodeJS 10 echt niet meer kan

[Jim80]

Ik vind sowieso dat JS niet kan voor serieuze toepassingen. Het is dé taal van fouten onder de mat vegen en er pas 10 stappen later achterkomen dat er ooit eens iets moet misgegaan zijn.

[Gamebuster]

Uiteindelijk is het gewoon een stuk gereedschap dat je met de juiste maatregelen iets mee kan maken.

Maar echt voorbeeldig van kwaliteit is het zeker niet.

[FlaffTweakr]

Het probleem is dat dat stuk gereedschap de tand des tijds niet doorstaat.

Het is een geïnterpreteerde taal die alsnog een compiler nodig heeft voor tegelijkertijd backward (ECMAScript versie) en forward compatibility (polyfills). Bovendien veranderen de toolchains zo veel dat je op meerdere lagen tegelijkertijd onderhoud moet uitvoeren:

- je eigen code migreren naar nieuwe best practices
- je code compatibel houden met nieuwe releases van je directe dependencies
- de directe dependencies met elkaar compatibel houden
- de indirecte dependencies compatibel houden - echt puzzelwerk
- de toolchain versies compatibel houden
- de toolchain configs updaten naar een geüpdatete methodiek
- oude workarounds wegwerken

Een heel deel van die punten zou overbodig moeten zijn. Ze willen te veel backwards compatible blijven i.p.v. te erkennen dat er gaandeweg een nieuwe taal uitgevonden is. Naar mijn mening zouden browsers moeten overstappen naar een niet-backwards compatible versie van TypeScript en maar om de 3 tot 5 jaar syntax changes toelaten.

[Gamebuster]

Ik heb het idee dat heel veel van je argumenten elkaar direct tegenspreken.

Zo constateer je dat de toolchains veel veranderen en dat je daardoor vaak onderhoud moet uitvoeren, en vervolgens stel je voor om backwards compatibility de deur uit te gooien waardoor we met z'n allen WEER onderhoud moeten uitvoeren.

NodeJS zelf is niet echt het probleem hier. Ik kan makkelijk oude NodeJS code (2010) pakken en draaien in moderne NodeJS versies. Het zijn de dependencies die stuk gaan, NPM die niet goed of onvoldoende reproduceerbare builds kan maken en de algemene houding van ontwikkelaars in het ecosysteem om dingen snel te "verbeteren" (IMO iets anders te proberen dat ook niet werkt).

NodeJS libraries komen en gaan, en er zijn er 1000en die allemaal hetzelfde doen, en geen enkele is echt een standaard. Dit komt denk ik deels omdat NodeJS out of the box met een slechte library komt waardoor iedereen zijn eigen libraries ging maken voor functionaliteit die iedereen nodig heeft (manupulatie van objecten, arrays, strings, dates of zelfs het maken van classes voordat JS een eigen class keyword had)

Blijkbaar haat iedereen javascript, want er blijven maar "transpilers" uitkomen met nieuwe features die naar javascript compilen.

Naar mijn mening zouden browsers moeten overstappen naar een niet-backwards compatible versie van TypeScript en maar om de 3 tot 5 jaar syntax changes toelaten.

Dit breekt het hele web en gaat natuurlijk nooit gebeuren. Overigens, ik dacht dat we het over server-side JS hadden. Als we over client-side JS applicaties gaan beginnen, kan ik hele boeken typen waarom dat verschrikkelijk is.

[akooijman]

Met een kettingzaag kun je prima een salontafel maken, maar er zijn echt betere gereedschappen waar het beter mee gaat

[Gamebuster]

Wat een nutteloze analogie, was dat nou een comment waard?

[f1fr33k]

Alle Angular/Vue/React apps compilen naar JS, dus dan is dat een heel groot deel van het web dat je niet vind kunnen?

[Jim80]

Alles wat compiled naar JS is net in het leven geroepen om de vele tekortkomingen in JS op te vangen.

[Ed Vertijsment]

Kan je uitleggen wat je daarmee bedoelt? Er wordt een hoop code geschreven die vast mooier kan maar dat is imo in bijna elke taal wel het geval.

Js heeft een paar minder mooie delen m maar de meeste meeste frustratie ervoor komt in mijn ervaring eerder vanuit onbegrip dan dat de taal “niet zou kunnen”.

[Gamebuster]

Javascript zelf heeft natuurlijk wel zo zijn issues, waarvan prototype pollution de grootste is IMO.

[gimbal]

Eens, maar met Typescript ervaar ik dat bijna niet meer. Het is een oplosbaar probleem.

[holoduke51]

En toch draaien er complete backends op van grote serieuze producten. Paypal, Netflix, Trello en nog een hoop meer. Niet alle onderdelen van die bedrijven draaien op nodeJs overigens.
Over het algemeen heeft Nodejs een goede performance. Is developer productiviteit hoog en zijn applicaties minder complex door simpelere tooling. Ja het heeft zeker vervelende zaken zoals NPM en libs die out of date zijn.
Maar ga eens voor de grap een C, Python of Java applicatie van een groot bedrijf bekijken. Kans is groot dat je eerst 6 maanden het build process moet leren begrijpen. Dat er ongelovelijk veel lagen in de applicatie zitten waardoor mensen moeite hebben met begrijpen van de logica.
Persoonlijk vind ik Rust een mooie backend taal.

[retakenroots]

Dan mis je testen .

Elke taal heeft zijn quirks en als developer moet je die quirks kennen/ownen.

Persoonlijk heb ik een AWS datalake geschreven in JavaScript en die heeft nooit een probleem gehad. Maar dan wel in vanilla js en node zonder npm packages.

[FlaffTweakr]

Hoe denk je dat ik me een paar maand geleden voelde bij het releasen van een Electron app update op basis van Node.js 8..

[Gamebuster]

Wacht maar tot je een oud project wil uitchecken en er niets meer werkt om onverklaarbare rede. Ook mijn favoriet! Vooral dingen met typescript + babel + react zijn altijd dikke pret.

[divvid]

Daarom probeer ik javascript frameworks zoveel mogelijk te vermijden.

Laatst een Django/python site die al sinds 2009 stil lag gemoderniseerd. Een middagje werk ondanks de codebase van 100k regels en transitie van django 1.1 en python 2.7 naar django 4.1 en python 3.10. De meeste dingen waren syntax gerelateerd, maar hoofdpijn….nee.

[Ed Vertijsment]

Muah ik kan me nog iets van python2 migreren herinneren . Maar true, vanilla Django is vrij goed te migreren. Wordt overigens ook lastiger als je meer libraries gebruikt.

[w3news]

Er is een verschil van om een framework heb bouwen en frameworks/libraries er bij gebruiken.

Ik probeer mijn code framework agnostic te bouwen, en mijn code zo puur mogelijk.
Dus geen typescript, geen Babel, geen enorme en complexe frameworks als Nest, libraries als TypeORM, ...
Alleen frameworks en libraries die geen harde stempel leggen op je code, dus bijna geen code die afhankelijk is van een framework.

En bij elke PR dependencies bijwerken, en altijd de laatste node LTS versie gebruiken.

Dat is mijn recept voor hoofdpijn loze node code.

[divvid]

Het voordeel van frameworks is natuurlijk wel dat security flaws door ee community opgemerkt en gefixed worden. Daar heb je zelf geen tojd voor. Tegelijkertijd is dat dus ook een nadeel omdat je afhankelijk bent. Het is lastig om een goede balans te vinden

[Htbaa]

Het is altijd afwachten of je toolchain draait na een npm install en de foutmeldingen die je dan krijgt zijn vaak enorm nietszeggend. Backwards compatibility is ook nog wel 's een dingetje, zeker als er een nieuwe Node.js versie is.

Ik ga inmiddels steeds meer richting het afzweren van libraries die allemaal tooling nodig zijn. Het is veel te breekbaar en kwetsbaar. Inmiddels mijn heil gevonden bij htmx en _hyperscript of Alpine.js. Gewoon eenvoudig een script-tag in je HTML en je kan er mee aan de slag. Geen bundlers nodig etc. en het werkt zoveel prettiger.

[Gamebuster]

Ben ik mee eens. Ik houd het nu bij esbuild (snel en compleet out-of-the-box, dus geen 100 plugins nodig) en typescript (TS vind ik wel enige meerwaarde hebben). Voor dependencies gebruik ik nu Yarn 2 PNP, waarbij je dependencies letterlijk als zip-files in je repo staan. Verder lock ik de NodeJS versie en heb ik natuurlijk een dekkende set aan tests zodat ik redelijk kan bewijzen dat nieuwe versies van plugins/nodejs werken.

Ik hoop dat het gezeur zo klaar is, maar ik zal ongetwijfeld tegen nieuwe obstakels aanlopen

[Htbaa]

Ah ja esbuild was ik ook tegengekomen. Wou dat gebruiken voor een applicatie van me waar nog CoffeeScript 1 gebruikt wordt. Dat ging ‘m helaas niet worden, dus die blijft bij webpack totdat ik de boel ombouw naar htmx. Is esbuild ondertussen al uit z’n alpha/beta status? Was wel lekker snel als ik me niet vergis.

[Gamebuster]

esbuild is zover ik weet uit alpha/beta status en is inderdaad super snel, maar dat komt deels omdat een hoop dingen simpelweg niet ondersteund worden. Daar heb je geen last van, tot een bepaalde plugin of library iets doet of gebruikt wat afhankelijk is van babel of exotische typescript features en dan kan je niets (zijn er verassend veel!)

Voor coffeescript is er wel een plugin: https://github.com/johnie/esbuild-coffeescript al denk ik dat je dan wel over moet op CS2. Volgens mij is de migratie van CS1 naar 2 niet zo heel ingewikkeld.

[Reactie gewijzigd door Gamebuster op 23 juli 2024 02:46]

[holoduke51]

Waarom niet dan?

[Merethil]

Omdat 10 al pakweg 1,5 jaar geen securityupdates meer krijgt. Ondertussen is die versie ook al meer dan vier jaar oud, da's tijd zat om naar een nieuwe versie te gaan.

[MaestroMaus]

Ik werk niet met projecten die NodeJS gebruiken. Wat is de reden dat men niet overstapt? Zijn nieuwere versies niet backwards compatible?

[Gamebuster]

Ik vermoed omdat men geen automatische tests heeft en ze dus geen makkelijke manier hebben om nieuwe versies te testen.

De grootste rede waarom dingen stuk gaan na migreren is omdat bepaalde libraries niet meer werken met nieuwe nodejs versies en je dus moet upgraden, wat gepaard gaat met een kettingreactie aan libraries die je moet updaten. (want A is afhankelijk van B, en B weer van C, etc) Dit heeft vaak weer als gevolg dat oude code gewoon niet meer werkt omdat de libraries die je gebruikt nu anders werken, vaak omdat bepaalde validaties strenger zijn geworden of omdat bepaalde functies opeens net iets anders werken.

Met Typescript krijg je als bonus erbij dat de type-definities vaak meer getailleerd bij nieuwere versies van libraries, waardoor opeens hele grote delen van je applicatie opeens vol TS type errors zitten ondanks dat je code gewoon werkt. Ik heb wel wat beters te doen, dus meestal los ik dat op door maar gewoon overal `: any` te plakken en zo de type-checks te omzeilen

Het wordt 4x zo erg zodra React + Babel erbij komen. Op een of andere manier is dat altijd dikke ellende.

[Reactie gewijzigd door Gamebuster op 23 juli 2024 02:46]