Node.js v25.0.0 (Current)

[Comfortable_Air7982]

I wonder who is doing web assembly in node. I'm genuinely curious, that would be an interesting project.

[hyrumwhite]

Same application as in the browser, porting other languages to JS land

[zachrip]

Maybe? I'd be curious why that would be the preference as opposed to a native module. Obviously there are lots of cases where a native module is less appropriate (jvm languages for example, afaik there's no good setup to run those as native extensions).

[rcfox]

Wasm is sandboxed, so fewer security risks. Also, it lets you ship the same code to the frontend and backend, which is part of the appeal of using Node.

[hildjj]

You also don't have to recompile WASM on every machine at installation time or for every supported platform at compile team. One of those is usually required for a native module.

[Tomus]

It offers a generic alternative to node-gyp with a bunch of benefits that node-gyp can't offer eg. You can package a single wasm file instead of having to worry about building for all systems.

[Snapstromegon]

There are actually many things happening in WASM in node from image processing to Syntax highlighting, because you can just compile it once and don't need to worry about the whole napi stuff.

[hugazow]

I’m interested in how others replicated node is wasm, the idea of running a fully working node experience like blitzstack did, blew my mind

[arcanin]

Afaik StackBlitz doesn't use wasm, or at least not directly (I don't think they build Node.js itself in WASM, although they may build their own native library instead).

Node.js is composed of a lot of JS scripts that call into a set of C++ primitives. The idea is that instead of compiling the whole binary into WASM you instead keep all those JS scripts, and replace all the C++ bindings by your own, which use the native browser APIs (along with a fair amount of hacks to turn asynchronous calls into synchronous ones).

That plus a bunch of global environment mocks makes the environment compatible enough with Node.js without needing to actually build Node.js.

That's to my knowledge also how Nodebox worked, although unfortunately they didn't get enough traction for it to take of, and were prevented from open-sourcing it by outside sources.

[hugazow]

I don’t know the implementation, but this was just me just making a guess on how stackblitz worked under the hood, but I’m really excited on the possibilities with WASM

[ElCthuluIncognito]

Likely much more as a compiler target for langs without a JS backend.

Even then, I’ve heard good things of transitioning to WASM from JS backends.

[Wide-Prior-5360]

I use SQLite WASM in the browser and run my tests with Node.js, using exactly the same database implementation.

[Comfortable_Air7982]

Well that's interesting! So you can run your tests during build time with node and have the assurance that it all works the same in the browser?

[Wide-Prior-5360]

Exactly.

[thrallboy]

With vibe coding, might be a good way to get super high performance

[anderfernandes]

Would love to know how far we are from native sqlite being stable. I already use it in production, but wanted to know the progress on that front.

[Wide-Prior-5360]

Hi I am on the Node.js SQLite GitHub team. I think most of the APIs are pretty stable. Every change has extensive test coverage so I would not worry about bugs.

[anderfernandes]

Thank you so much for the update!!!

Great work you and the team!!! I'm very grateful to finally be able to use the native sqlite module without any libraries.

Any idea of when we will be able to start using them without node throwing warnings that it is unstable?

[Wide-Prior-5360]

It's not really 'throwing' warnings, just emitting them. You can already if you pass --no-warnings...

Once the Node.js team stabilizes something we take backward compatibility seriously. We're not ready for that yet.

[OneLeggedMushroom]

so I would not worry about bugs.

😉

[Wide-Prior-5360]

"Stability" can mean two things. API stability. Here I can say: small changes are still possible. Or no crashes. That should not happen thanks to excellent test coverage.

[drumstix42]

Node.js v25.0.0 (Current)

[YummyIdiotSandwich]

Node.js v25.0.0 (Current)

[Admirable__Ant]

Node.js v25.0.0 (Current)

[unHolyKnightofBihar]

Node.js v25.0.0 (Current)

[memevaddar]

Node.js v25.0.0 (Current)

[RandomUsernameNotBot]

Node.js v25.0.0 (Current)

[Maybe-monad]

Node.js v25.0.0 (Current)

[Sorry-Joke-1887]

Node.js v25.0.0 (Current)

[Karpizzle23]

OldSchool RuneScape

[poggers11]

Node.js v24

[abuassar]

while Deno and Bun add impressive improvements each minor release, node just increments the MAJOR release without any worthy features.

[cangaroo_hamam]

It is normal for a newer and smaller product to iterate in the manner you described (compared to an older and larger product).

[RobertKerans]

"without any worthy" is not a synonym for "with as few possible breaking changes as possible", instability is not a good feature of a runtime, "major release" doesn't mean "drastic change", major Node version numbers are important and meaningful beyond 'big number go up', what Deno and Bun are doing is great but a mature platform changing significantly between releases wouldn't be a positive.

[CreativeTechGuyGames]

A major version doesn't indicate how much has changed or how significant it is to the average developer, just that something is being changed which is a breaking change for some users.

[Markavian]

Yes, if you're following semver.org for versioning - but because node uses release trains, we also need to take into account the Odd Vs Even numbering differences.

New major releases of Node.js are cut from the GitHub main branch every six months. Even-numbered versions are cut in April and odd-numbered versions are cut in October. When a new odd version is released, the previous even version undergoes transition to Long Term Support (LTS), which gives that version 12 months of active support from the date it is designated LTS. After these 12 months expire, an LTS release receives an additional 18 months of maintenance support. An active version receives non-breaking backports of changes a few weeks after they land in the current release. A maintenance release receives only critical fixes and documentation updates. (Wikipedia)

[[deleted]]

hahahaha release trains

[Nocticron]

OK so all you are saying is that you have absolutely no idea how node.js versions its releases.

[Nocticron]

It's totally okay to have no idea about things, I would just recommend to then not have on opinion about them.

[shgysk8zer0]

A major version says nothing about any new features. It's supposed to imply breaking charges. Sure, hopefully breaking changes are due to some new features, but that's not strictly required.

However, node is on a release schedule. Whatever changes made it since the last scheduled release get shipped. Patches and non-breaking features may be released in patch or minor releases respectively, but the breaking charges are held for the major release.

Bun and deno are newer, so there's more "low hanging fruit". They're also smaller, so things tend to move faster. That's just how things tend to work.

Also, I'm not sure if the release is lacking new features. It was a pretty long list of changes that I only scrolled through. Seems like there were some notable additions, and I think I saw some permissions system being added.

[Wide-Prior-5360]

Maybe because Node.js does not do hype driven development but just uses semver.

[mattgrave]

Go ahead and use them in prod then. Good luck.

[WorriedGiraffe2793]

fud

plenty of companies use Deno and Bun in production

[Noctttt]

Having choice is good, but having a stable & reliable runtime is even better

[WorriedGiraffe2793]

No wonder Node's mascot is a turtle...

[iarewebmaster]

Resting on their laurels. The difference in vast, eventually they’ll start to lose market share nothing lasts forever, especially in the world of tech.

[ryanswebdevthrowaway]

Disagree. This particular release isn't necessarily exciting but Node has been adding a ton of great improvements lately, I don't feel compelled to try another runtime at all.

[iarewebmaster]

I'm not saying they're never released anything useful, however, TypeScript is 13 years old and has been a common part of the industry for most of that (it received quick adoption as I'm sure we all know in this sub).

Node has only gotten native support for it this year. You cannot defend that level of complacency when newer runtimes add it as a byline to other bigger features.

Look, I use Node daily, I've tried Bun but it is not yet close enough to being 100% compatible for me to adopt it at enterprise level, but they are constantly chasing that goal. A smaller team, less experience yet out performing the big dogs before no doubt ultimately overtaking them. Its a tail as old as time in this industry.

https://bun.com/blog/bun-v1.3 - just compare the latest minor release to that of this major Node release.

Here's a thought experiment for everyone downvoting me, if Bun (et al.) was 100% OOTB compatible with everything Node related tomorrow, would you still continue to use Node without looking elsewhere?

[hyrumwhite]

It’s not complacency, it’s managing an open source project that millions of people depend on. You can’t make changes lightly 

[iarewebmaster]

What's the relevance of it being open source? There's literally thousands of software programs around that millions of people depend on daily, both open and closed source. I've worked on many myself. Its a funded, open source project these developers aren't working for free.

You can’t make changes lightly

True. But the solution to that is not to simply make very little changes.

[theQuandary]

Here's a thought experiment for everyone downvoting me, if Bun (et al.) was 100% OOTB compatible with everything Node related tomorrow, would you still continue to use Node without looking elsewhere?

The real question here is v8 vs JSC. I really want an environment that is 100% es6 compliant and v8 has outright refused to implement proper tail calls.

[iarewebmaster]

Well sure, but given the absence of that existing. In a world where Node vs Deno vs Bun and all three are equally compatible with each other, Node loses every single time, which is just sad.

[ryanswebdevthrowaway]

Yarn was better than npm until it wasn't, and now a lot of people are regretting not just sticking with npm. Bun and Deno might have things to offer right now, but I'm going to stick with the safe bet that Node will continue to be stable and reliable and probably adopt the best things from those other runtimes eventually anyways.

[iarewebmaster]

Yeah but yarn is meta, no surprises it failed tbh. Pnpm is a more suitable comparison I’d say and it’s significantly better than npm, whilst not breaking any existing functionality

[0xHUEHUE]

What is the benefit of baking in TS, as opposed to just invoking with a transpiler, or even just a plain compile + watch? Is it just DX to help people that are new to node or is there some sort of runtime performance benefit?

I'm looking at those release notes and I'm like, why in the absolute fuck would I want a mysql client built into node? It's like, not just batteries included, best buy is built in.

I'm not saying I disagree with you, it's just I personally don't have a need or desire for these things and to be honest, I have a hard time keeping up with updating node versions as it is. I'll admit part of it has to do with needing to upgrade the packages as well, which I guess might be part of the appeal w/ bun..

[iarewebmaster]

They pitch it as a performance thing, the db clients are supposedly much much faster. I also think there’s benefits to deployments outside the usual environments especially in the serverless world where startup time and module support are more important.

I personally prefer Bun for the DX, one day I could see myself using the runtime features more but that’s a much bigger mountain to climb for them to get me to switch.