Software-update: Node.js 18.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 versie 18.0 vrijgegeven en de release notes daarvan zijn hieronder voor je neergezet.

Node.js 18 available now

We’re excited to announce that Node.js 18 was released today! Highlights include the update of the V8 JavaScript engine to 10.1, global fetch enabled by default, and a core test runner module.

Initially, Node.js 18 will replace Node.js 17 as our ‘Current’ release line. As per the release schedule, Node.js 18 will be the 'Current' release for the next 6 months and then promoted to Long-term Support (LTS) in October 2022. Once promoted to long-term support the release will be designated the codename 'Hydrogen'. Node.js 18 will be supported until April 2025.

You can read more about our release policy at https://github.com/nodejs/release.

To download Node.js 18.0.0, visit: https://nodejs.org/en/download/current/. You can find the release post at https://nodejs.org/en/blog/release/v18.0.0, which contains the full list of commits included in this release.

Versienummer	18.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 (23)

[Empheria]

Vooruit, ik ga voor de bait!

Er is een reden dat JavaScript op de server zo ongekend populair is geworden het laatste decennium, drie keer raden hoe dat zit...

Het blijkt zo te zijn dat als je front- en back-end developers in een team hebt zitten, dat ze makkelijker communiceren als ze met dezelfde taal bezig zijn. Voor grote bedrijven betekent dat een enorme productiviteitswinst die dan weliswaar ten koste gaat van snelheid, bugs of limitaties aan het eindproduct, maar daar zijn de aandeelhouders niet zo in geïnteresseerd.

We kunnen het erover eens zijn dat JavaScript veel gore dingen doet met inferred typing conversies waar de ondervaren gebruiker niets vanaf weet, maar dat maakt het nog niet per definitie een crappy taal.

JavaScript is een taal met een gebruiksaanwijzing en doet een heleboel dingen waarvan de haren van een C-developer recht overeind gaan staan, maar als je die gebruiksaanwijzing eenmaal door hebt kun je er heel vlot de dingen mee doen waarvoor de taal inmiddels gangbaar is.

Kan het beter? Absoluut! Wordt vooruitgang geblokkeerd door ondersteuningseisen voor legacy browsers en het hele internet? Zeker weten!

Gelukkig zijn er genoeg alternatieven aan de serverkant voor degenen die er echt een bloedhekel aan hebben, of die per se iets nodig hebben wat echt tot op het uiterste geoptimaliseerd is. Maar voor veel toepassingen is JavaScript gewoon goed genoeg.

Er zijn genoeg legitieme redenen om het hele JavaScript-ecosysteem te bashen. Om maar eens wat te noemen:
- Null safety (undefined is not a function)
- Dependency bloat van NPM packages (al is dat meer pebkac dan JS)
- Afvangen van browserondersteuning voor verschillende versies ECMAScript
- Classes zijn geen echte classes maar fancy objects

[J_van_Ekris]

We kunnen het erover eens zijn dat JavaScript veel gore dingen doet met inferred typing conversies waar de ondervaren gebruiker niets vanaf weet, maar dat maakt het nog niet per definitie een crappy taal.

Hier iemand die al meer dan 30 jaar C/C++ ervaring heeft en nu toevallig op een Node.js open source project wat doet: elke taal heeft zijn hebbelijkheden, en veel komt aan op aangeleerd gedrag van de programmeurs. Als je teveel op de automatische piloot applicaties schrijft dan is elke verandering een probleem. Er worden in het ontwerp van de taal of de implementatie links en rechts andere keuzes gemaakt, en dat maakt een taal anders, niet beter of slechter.

JavaScript is een taal met een gebruiksaanwijzing en doet een heleboel dingen waarvan de haren van een C-developer recht overeind gaan staan, maar als je die gebruiksaanwijzing eenmaal door hebt kun je er heel vlot de dingen mee doen waarvoor de taal inmiddels gangbaar is.

Andersom geldt dat ook: in C/C++ zitten nog steeds constructies waar de rest van de wereld van gruwelt. De gemiddelde code-checker kent ze ook, maar dat is meer lapwerk dan fundamenteel aanpakken van je probleem.

Er zijn genoeg legitieme redenen om het hele JavaScript-ecosysteem te bashen. Om maar eens wat te noemen:
- Null safety (undefined is not a function)
- Dependency bloat van NPM packages (al is dat meer pebkac dan JS)
- Afvangen van browserondersteuning voor verschillende versies ECMAScript
- Classes zijn geen echte classes maar fancy objects

Met name die laatste is verwarrend, but you can't have it all...

[Ablaze]

Het is inderdaad een stuk minder omslachtig om dezelfde taal te gebruiken voor zowel de front als backend.
Maar alle moderne browsers ondersteunen wasm dus het hoeft niet noodzakelijkerwijs js te zijn. Je kunt zelfs intermediate languages gebruiken als C#. De topicstarter voelt zich hier wellicht fijner bij.

[jwarmer]

TypeScript! Lost veel van deze problemen op (helaas niet allemaal).

[pofsok]

JavaScript heeft zo'n zijn eigenaardigheden, maar als dit de eigenaardigheden zijn die het de 'meest crappy taal ter wereld' maakt. Dan is het zo slecht nog niet.

Als dit soort dingen voor jouw valkuilen zijn, is het misschien handig om correct mental model van JavaScript in je hoofd te creëren, wat zijn primitives, referenties, etc. Veel mensen (ik was ook een van deze mensen) maken de fout om naar JavaScript te kijken vanuit een C-achtig perspectief (je hebt geheugen waar waardes in staan, en pointers die naar geheugen adressen wijzen). Maar als je dit model gebruikt maak je heel veel fouten, die je helemaal niet hoeft te maken.
Daarnaast zijn veel van de 'rare' dingen definities die in bepaalde zin even logisch zijn als wiskunde, want wiskunde (en dus ook gewoon rekenen) begint bij het opstellen van heel veel definities. Je bent je daar alleen niet meer bewust van, omdat je al die regeltjes en definities al je hele leven gebruikt.

[Henk1827]

JS is te snel naar de markt gebracht en APIs als .sort() zijn gewoon stuk. Omdat we er niet omheen kunnen is er gelukkig veel werk verzet om specificatie beter te maken. Ik ben het met @Jim80 eens dat dit eigenlijk niet kan in een programmeertaal. Zonde van je metale capaciteit om steeds met de valkuilen rekening te houden.

[Orgel]

Jouw drol mag overigens ook wel wat beter gecompileerd worden qua syntaxis.

[Cyb]

Dat persoon (waar je lof voor zou moeten hebben) is tevens ook de maker van Deno (laatste twee letter van "Node" naar voren gehaald). Deno heeft hij in 2018 aangekondigd in zijn talk "10 Things I Regret About Node.js", en Deno heeft volledig TypeScript support.

[Hogarts]

In wezen maak jij het plaatje alleen maar erger ipv beter.

Dus in plaats van dat hij node.js gaat proberen te verbeteren begint hij maar gewoon opnieuw.
En om de problemen in Deno te fixen gaat hij dan weer een nieuwe taal maken?

Eigenlijk zeg je dus dat deze persoon gewoon geen taal kan maken waarop je kan bouwen. Op elk moment kan deze persoon besluiten om de huidige taal weg te gooien en opnieuw te beginnen.

Yep klinkt echt alsof je er lof voor moet hebben.

[Cyb]

In de open source wereld worden dingen niet "weggegooid". Ze liggen klaar voor anderen die er interesse in hebben, om het verder op te pakken. In Node hebben heel veel mensen interesse, dus dat is geen probleem. Ook is dat al meer dan 10 jaar geleden gebeurd, dus het probleem dat je voor deze situatie probeert aan te kaarten, is niet echt relevant meer.

Ook kan je niet zomaar de filosofie van software veranderen. I.p.v. alles aan te passen naar je eigen dictatoriale wensen en de rest van het team en de community te negeren, kan je er ook voor kiezen om het vanaf scratch opnieuw te doen, met een andere filosofie. Dat vind ik wel lofwaardig.

ps. Node is overigens geen taal, maar een runtime omgeving.

[Hogarts]

In de open source wereld worden dingen niet "weggegooid". Ze liggen klaar voor anderen die er interesse in hebben, om het verder op te pakken.

Tja, en zwerfafval bestaat ook niet, dat zijn spullen die klaarliggen voor anderen die er interesse in hebben.

Ook kan je niet zomaar de filosofie van software veranderen.

Juist wel, dat heet verantwoordelijkheid en ja dat brengt problemen met zich mee. Maar weglopen van problemen is wmb niet heel lofwaardig.
Je initiele filosofie gaat nooit 100% juist zijn over de lange termijn, daarvoor heb je juist voortschrijdend inzicht.

[Empheria]

Zo simpel is het in de realiteit helaas niet.

Node.js wordt inmiddels op enorm grote schaal ingezet voor de meest uiteenlopende toepassingen, zowel lokaal als online. Met dat je een versie uitbrengt waarop je Long-Term support aanbiedt garandeer je daarmee ook dat je de boel onder de motorkap gewoon laat zoals het is. De genoemde "10 Things I Regret About Node.js" zijn voor het grootste gedeelte structurele wijzigingen aan de manier waarop Node zou werken. Zelfs als het haalbaar is om de hele boel op de schop te gooien om Node "te verbeteren" zal vervolgens elk van de miljoenen dagelijkse gebruikers voor de nieuwe versie zijn code moeten omschrijven met alle gevolgen van dien.

Ik kan me in dat geval erg goed voorstellen dat je Node.js gewoon laat wat het is en de focus legt bij de ondersteuning van de bestaande gebruikers, en dat je de geleerde lessen meeneemt naar een nieuw project.

Eigenlijk zeg je dus dat deze persoon gewoon geen taal kan maken waarop je kan bouwen. Op elk moment kan deze persoon besluiten om de huidige taal weg te gooien en opnieuw te beginnen.

Je moet het niet zo zeer zien als het "weggooien van Node in ruil voor Deno", maar eerder als "we hebben nu naast Node ook Deno". Voorlopig gaat Node nergens heen wat marktaandeel betreft en de twee zijn ook verschillend genoeg dat ze niet snel in elkaars vaarwater zullen komen.

Ik kan iedereen die het interessant vindt aanraden om eens te kijken naar wat er allemaal achter Deno zit, bijvoorbeeld hier: https://www.youtube.com/watch?v=1gIiZfSbEAE

[Hogarts]

Zo simpel is het in de realiteit helaas niet.

Waarom niet? Elke andere taal doet dit wel gewoon.

Zelfs als het haalbaar is om de hele boel op de schop te gooien om Node "te verbeteren" zal vervolgens elk van de miljoenen dagelijkse gebruikers voor de nieuwe versie zijn code moeten omschrijven met alle gevolgen van dien.

En? Dit is dagelijkse praktijk in de software wereld.
Ga eens van eender welke programmeertaal dan ook eens in de geschiedenis kijken en elke programmeertaal zal gewoon dingen gedepreciate hebben.

Ik kan me in dat geval erg goed voorstellen dat je Node.js gewoon laat wat het is en de focus legt bij de ondersteuning van de bestaande gebruikers, en dat je de geleerde lessen meeneemt naar een nieuw project.

Alleen waar laat je dan de lessen die je leert tijdens en na je nieuwe project? Ga je daarvoor dan weer een nieuwer nieuw project starten? En de lessen die je dan weer leert?

[...]
Je moet het niet zo zeer zien als het "weggooien van Node in ruil voor Deno", maar eerder als "we hebben nu naast Node ook Deno".

Dus ipv een dedicated persoon met 1 gedachtengang heb je nu een soort split-personality zitten die 2 filosofieën in zijn hoofd uit elkaar moet houden en elke fout daarin is een extra bug.
Yep, klinkt beter en beter...

[Vihaio]

Ik denk dat iemand die denkt dat "false" een boolean is, en blijkbaar niet snapt wat floating point numbers zijn, geen mening moet hebben over hoe goed een taal is

[Jim80]

Net zoals voor Javascript "5" ook een number is? Maar dan enkel maar in sommige gevallen.
Eén van de grote problemen met Javascript is het dat zo lang mogelijk alles zal proberen te blijven converteren, de fout onder de mat proberen te vegen net zolang tot het niet anders meer kan, en je al lang niet meer weet waar de fout zich eigenlijk 100 lijnen eerder heeft voorgedaan.

In tegenstelling tot compile time fouten zijn runtime fouten zoveel malen moeilijker te traceren, als je het geluk hebt dat ze al voorkomen tijdens je testen en niet pas als alles al in productie staat.

[windows8fan]

Gelukkig is er Typescript die veel van dit soort problemen in runtime voorkomt.

[Remzi1993]

Daarom zijn er dus allerlei oplossingen voor dit probleem, en de bekenste is Typescript!

[Stukfruit]

Lang leve (geautomatiseerde) code reviews en een steeds grotere focus op architectuur ipv details die je ook voor andere talen kan bedenken

[beerse]

Het is even kluiven en doorbijten maar de meeste kan ik wel in zien. Het meeste gaat nat op zaken als automatische-type-conversie en misschien ook wel automatische syntax verbetering.

Zelf ben ik dan old-school en mag ik mij niet eens meer programmeur noemen maar als je code baseert op automatismen en 'zo kan/mag het ook' situaties dan is het altijd vragen om problemen.

Over de term 'crappy taal' kan ik alleen maar zeggen dat voor de meeste programmeurs/hakkers/script-kiddies de laatste taal die ze behapt hebben vaak de meest crappy taal is, tot je de filosofie en het gevoel er bij krijgt. Daarna gaan er deuren open en blijkt het allemaal wonderbaarlijk.

Voor echt 'vreemde' talen moet je eens in reverse-polish notatie gaan werken of met talen als small-talk, eifel en lisp.

[Sp3ci3s8472]

Denk dat ik deze hier moet achterlaten :
Interview with Senior JS Developer in 2022
Interview with Junior JS Developer in 2022

Ze hebben die ook voor andere talen gemaakt!

[FlaffTweakr]

Die eerste video heeft me minstens een uur aan productief werk gekost toen een collega dit postte. Ik lag plat.