alt.hn

5/20/2026 at 6:48:30 PM

Node.js 26.0.0 (Now with Temporal)

 https://nodejs.org/en/blog/release/v26.0.0

by aarestad

5/20/2026 at 9:38:20 PM

> Upsert (https://github.com/tc39/proposal-upsert): [Weak]Map.prototype.getOrInsert(), [Weak]Map.prototype.getOrInsertComputed()

Their usage of upsert appears different than I was used to:

Me: Upsert = Update or Insert

Them: Upsert = Get or Insert

by jdthedisciple

5/20/2026 at 9:51:36 PM

The proposal used to do more thing and we didn't change the URL after we ultimately arrived at this set of APIs.

by bakkoting

5/21/2026 at 2:49:05 AM

> Their usage of upsert appears different than I was used to: > Them: Upsert = Get or Insert

I agree that their choice of labeling the proposal as "upsert" is less than ideal. However, this functionality is reminiscent of a very useful Perl capability known as autovivification[0] as described in the motivation section:

  A common problem when using a Map or WeakMap is how to 
  handle doing an update when you're not sure if the key 
  already exists in the map.
0 - https://en.wikipedia.org/wiki/Autovivification

by AdieuToLogic

5/20/2026 at 11:01:34 PM

Reminds me of the weird C++ map operator[] behavior.

If you use that operator and the value doesn't exist, it'll default create one and return a reference to that.

And as I'm writing this I realize why... references cannot be `null`.

by OptionOfT

5/21/2026 at 12:26:52 AM

what is the value of an "update or insert" call on `Map`? is that not just set?

`getOrInsert` here seems to be the Python "set_default" method on dicts, which is very useful at avoiding tedium in some basic data munging

by rtpg

5/21/2026 at 2:52:54 AM

> what is the value of an "update or insert" call on `Map`?

It gives a caller the option of alternate logic based on the existence, or lack thereof, of a value.

> is that not just set?

No. The semantics of a "set" operation would overwrite an existing entry (if one exists).

by AdieuToLogic

5/20/2026 at 7:35:30 PM

26.2.0 is already out, why link to the previous release?

https://nodejs.org/en/blog/release/v26.2.0

What I would expect with the inclusion of temporal, is having a section on nodejs docs about Rust addons, alongside the C and C++ sections.

by pjmlp

5/20/2026 at 8:03:35 PM

That's on me - I saw v26 was released, but didn't realize they'd already done a point release in the ensuing 2-3 weeks!

by aarestad

5/20/2026 at 8:38:10 PM

https://nodejs.org/en/blog/release/v26.1.0 is particularly cool as it added initial FFI support.

by petercooper

5/21/2026 at 8:40:21 AM

This API is inherently unsafe. Invalid pointers, incorrect signatures, or accessing memory after it has been freed can crash the process or corrupt memory.

Absolutely great idea to expose such "features" to the web dev world!

All the JS devs that are already struggling with mildly complicated language features will love the giant new field of bugs they only dreamed of.

The arrival of the first very hyped tool that will make activating FFI support a requirement will be a great moment in JS history. Happily an army of mildly educated web devs will activate a feature which potential risks they do not even understand.

Luckily nowadays supply chain attacks are a thing of the past in the JS world, oh, wait...

by sexylinux

5/21/2026 at 5:54:03 PM

Criticism noted! But it is experimental, unconstrained FFI is inherently unsafe, and not all JavaScript developers are "mildly educated web devs".

I doubt we'll see this go into mainstream dependencies likely to be used by such developers – it hasn't in Ruby which has had easily accessible FFI mechanisms for years.

Though, there is already a fun experiment using it: https://blog.platformatic.dev/destino-doom-terminal-nodejs-f...

by petercooper

5/20/2026 at 8:33:51 PM

Tangent: if you use Node.js at build time you should check out VitePlus https://viteplus.dev

(No affiliation, just a fan of VoidZero's consistently excellent tools.)

by chrisweekly

5/20/2026 at 8:46:12 PM

Oh hey, they're the people behind Oxlint and Oxfmt: https://oxc.rs/

I moved some projects over to those from ESLint + Prettier and while the compatibility isn't 100% (I didn't need that), and the time to process a codebase went from like way over a minute with the old tools to a few seconds with theirs.

by KronisLV

5/21/2026 at 3:35:12 PM

Kind of difficult to install, especially in the enterprise business environment. At least they kept it free for everyone.

by butz

5/20/2026 at 8:44:38 PM

Looks interesting, what's their revenue model? Or how do we know it won't be abandoned in the near future?

by rumblefrog

5/20/2026 at 9:53:09 PM

The same as any other dev tool startup, once money gets tight they will monetize and users will rightfully revolt.

Evan You won't break the cycle, tale as old as time.

by shimman

5/20/2026 at 10:56:11 PM

After getting burned so many times on libraries, frameworks, services and platforms, even entire languages - one learns to be wary of critical dependencies. Every new project offers convenience in exchange for you giving up control of part of the software stack, and the power dynamic is often exploited sooner or later as revenue source. You can't trust anything that becomes irreplaceable, or that you can't write it (or at least understand it) yourself.

by lioeters

5/21/2026 at 2:53:31 AM

I mostly agree. But without argument, I can point out that a modern webapp requires tooling for capabilities like testing, linting, formatting, and bundling. Vite (and its ecosystem) has proven its mettle, and when it comes to being able to understand your dependencies, I'll take fewer, and simpler, and way faster, and more coherent, and more independent of misaligned corporate influence, every time. It's not even a trade-off, it's just better. I have deep expertise in wrangling eslint plugins and prettier configs and webpack, and am so grateful that's all in the rear-view mirror. An astonishing percentage of the world's most popular websites are built on a fragile and nearly-incomprehensible stack which no sane developer would choose. VoidZero (and TanStack, FWIW) are a breath of fresh air in making it possible to reason about your frontend tooling and architecture, and stepping away from unnecessary complexity and/or vendor lock-in. Of course it will eventually change. But as someone who's been building and improving web-based experiences for a living since the late 90's (for tiny startups and F500 enterprises and everything between), this is as good as it's ever been, and I recommend it without reservation.

by chrisweekly

5/20/2026 at 10:10:59 PM

VoidZero's business model is in Void, their deployment platform. Open source projects will always stay open source. This was announced at the very beginning.

by manniL

5/20/2026 at 10:56:25 PM

Yes, nothing different from any other VC dev tool startup. When the community fractures people simply move on to something else. See rome -> biome for a very recent example.

by shimman

5/20/2026 at 7:12:15 PM

I'm really looking forward to the temporal api being universally available. Moment and Luxon are fairly good but sensible date/time handling is something that really ought to be baked into the platform ootb.

by noodlesUK

5/20/2026 at 7:33:37 PM

I always thought the old Date is kind of elegant... increment anything with an overflow and it all wraps around correctly, like `d.setDate(d.getDate() + 100)` to advance a date 100 days. "March 208th" is interpreted like you'd expect, as are the hours and minutes and such.

Of course, complete lack of non-local non-GMT time zones is a huge downside.

by jpsimons

5/20/2026 at 7:43:37 PM

i'm pretty sure all that stuff works w/ Temporal... Temporal is extremely well-designed, in my experience. the js date object, on the other hand, has insane pitfalls, and i say this as someone who thinks not understanding JS ASI is a "skill issue", among other happily-un-"ergonomic" worldviews...

by keeganpoppen

5/21/2026 at 1:53:38 PM

`d.add({ days: 100 })` also wraps like you'd expect. `d.with({ day: 208 })` becomes the last day of the month instead but "March 208th" is kinda nonsense anyway so whatever. You could emulate it with `d.add({ days: 208 - d.day })`

by kaelwd

5/20/2026 at 10:44:17 PM

That's how you get date bugs.

by kaoD

5/20/2026 at 7:25:50 PM

Until then, a solid backfill has been available for quite some time

by culi

5/20/2026 at 8:38:49 PM

Also the release that drops typescript transforms: https://github.com/nodejs/typescript/issues/51

(I’m not disagreeing to remove it. It just took me a while to find out what happened to it)

by jauco

5/20/2026 at 9:02:07 PM

Initially it didn't make sense to me... but it looks like type striping is really the way to go for future TS.

There's the "types as comments" proposal[1] which could even land on browsers one day.

I started using the erasableSyntaxOnly setting in my tsconfig to get ready for this.

[1] https://tc39.es/proposal-type-annotations/

by pier25

5/21/2026 at 8:42:11 AM

At this point we should really prompt all the AI power in the world we have to create a TS replacement. It seems grotesque.

by sexylinux

5/20/2026 at 8:00:41 PM

I thought this was the release where the built in sqlite got its experimental tag removed, but I don't see it in the release notes. THAT'S got me excited more than Temporal. A stable API, huge utility and one less dependency.

by torgoguys

5/20/2026 at 8:56:58 PM

Off-topic but, Safari seems to be the only browser that doesn't support Temporal yet. It looks like the only blocker for adopting it on web.

https://caniuse.com/?search=Temporal

by sedatk

5/20/2026 at 10:23:29 PM

No but Google wants to control the Web (they do).

by owebmaster

5/20/2026 at 11:05:28 PM

Node v26 doesn't ship with corepack anymore. Annoying, it was a decent way to get pnpm in-band.

by OptionOfT

5/20/2026 at 8:54:44 PM

It's so sad that node refuses to add websocket server support.

Adding websocket would simplify stuff tremendously, as well as make deployments much, much more secure.

by emilfihlman

5/20/2026 at 9:37:53 PM

Why more secure?

I see that Deno has WebSockets, but I've never used them: https://docs.deno.com/api/web/~/WebSocket

by skybrian

5/21/2026 at 2:54:57 PM

Because it entirely removes dependency for external libraries and package repositories, like npm, for basic internet interoperability.

I (also) basically use only one package: ws.

by emilfihlman

5/20/2026 at 10:24:16 PM

"ws" is regularly the only package in my package.json

by owebmaster

5/21/2026 at 2:56:25 PM

Same. Without that I could remove all npm dependence, which would greatly improve security.

by emilfihlman

5/20/2026 at 10:32:11 PM

(Now with Malware) I joke! It already had malware.

by jollymonATX

5/20/2026 at 7:39:47 PM

Node JS team should look into bun and make progress. They are somewhat stable, but bun have lot of features and is more performant than Node.

by cute_boi

5/20/2026 at 7:45:08 PM

/s ? Bun is not yet (ever?) compatible with Node. I'm sure if Node JS could trim the fat with breaking changes they'd be fast too

by HatchedLake721

5/20/2026 at 10:05:43 PM

Honest question, what isn't compatible? Where I work we've simply replaced node with bun across a lot of overcomplicated + crappy projects, and on my work+personal computers I alias bun/bunx to node/npx with seemingly no issues at all

by xkcd-sucks

5/20/2026 at 7:59:06 PM

I expect bun to run almost everything that node runs these days. They have an extensive test suit to ensure that.

Even the complicated NextJS runs with Bun: https://nextjs.org/conf/session/nextjs-bun

Do you have a source for your claim?

by bel8

5/20/2026 at 8:20:00 PM

Maybe if you start from scratch with a new project, but when migrating an old project it's definitely not a drop-in replacement. I try once or twice per year, but it's not worth the effort when the upside isn't that big.

by vichle

5/20/2026 at 9:10:19 PM

In my testing Bun wasn't much faster most of the time, usually on par for all non-IO related stuff, and there were some cases with scheduling where Bun was noticable slower.

by notnullorvoid

5/20/2026 at 9:42:29 PM

I see no reason to leave node in what concerns JavaScript runtimes.

by pjmlp

5/20/2026 at 8:23:16 PM

They should the unexpected and vibe code node to zig. Or Odin for the kicks.

by postepowanieadm

5/20/2026 at 7:57:14 PM

they should rewrite their whole stack by AI from one language to another language, it seems fun.

by karel-3d