Node 23 fixes the worst thing about JavaScript

[@nehua6164]

Thank god for competitor runtimes like Bun pushing this feature forward. It seems like the Node team has finally decided to ACTUALLY work on something useful-without the competition, we probably wouldn’t have seen this from them anytime soon.

[@fred.flintstone4099]

Yeah, and Deno too. Bun and Deno are so much faster and easier to use. Deno is also more secure. I think Node.js should just recommend everyone to ditch it and upgrade to Bun or Deno instead.

[@ivanjermakov]

Am I the only one who completely dropped CJS from all my projects back in like 2020? There is literally no reason to hold onto the old way of doing it, since the great ES6 support on all platforms.

[@HawkSerj]

Yes, you are

[@RaVq91]

anybody who cares about tree shaking did the same thing (even earlier)

[@Sv443_]

For new projects, sure, but maintaining and updating old projects is a pain without ESM compat.

[@SirusStarTV]

React for example doesn't seem to have .mjs files or any ESM syntax in them. Even though in the examples they provide they use import statements loading cjs files.

[@zettca]

@@SirusStarTV the React team basically said they're only moving to ESM after everyone else does

[@thomasini]

Personally I think the most common error in all of JavaScript is the worst one: Cannot read property "someMethod" of undefined. Why can't JavaScript (or node) say instead: Cannot read property "someMethod" on "config" because it's undefined? That would be a much nicer error message IMO.

[@Pazuno]

Everyone switch to ESM, then problem solved, this fragmented module system is madness

[@SirusStarTV]

JSR should be used. Only ESM modules allowed.

[@corey4448]

Have you worked with large codebases?

[@maelstrom57]

@@corey4448 Yeah. So what's the problem with ESM and a large code base?

[@corey4448]

@@maelstrom57 problem is that you cannot easily migrate large codebase from commonjs to esm due to various reasons, from complexity to usage of commonjs-only dependencies

[@maelstrom57]

​@@corey4448 So the problem isn't the size of the code base; it's the fact that you depend on CJS-only dependencies. Most packages of this type are deprecated anyway so you're gonna have a problem even if you stick to CJS forever.

[@ColinRichardson]

I love how we know, if everything goes terribly wrong, you could safely get a job directing aircrafts with those little red sticks.. Your arm movements were NEXT LEVEL in this video.. Keep up the great work Matt!

[@BlackAsLight448]

Node is trying to catch up on what other runtimes have already achieved

[@fred.flintstone4099]

Yeah, Bun and Deno are way ahead, easier to use and faster.

[@maziasty]

Props to node.

[@gordonjohnston8321]

The only other system I can recall that used ‘odd number versions are less stable’ numbering was the Linux kernel back in the day. For example 2.2 and 2.4 were stable versions and 2.1 and 2.3 were development versions. However they stopped doing that with 2.6

[@EdwinMartin]

Ubuntu stil does this

[@jtw-r]

Love the wooden bookshelves in the background! Very nice homely touch

[@dasten123]

Great now we just need to wait one or two years until you can use it in production. Or switch to Bun today.

[@fred.flintstone4099]

Or Deno.

[@AutisticThinker]

3:39 - The Linux Kernel does this; a few others that I don’t recall atm too. This is very old school.

[@weirdwordcombo]

on another note: i think a painful thing about the JS module system is that the module paths depend on what the filesystem paths are (at least when using relative paths). whereas for example in C# they are completely independent, so you can move and rename files without the import paths having to change at all. this is such a freaking pain because the tooling is never perfect and you always have to correct a path manually when doing massive refactors.

[@dazraf]

After more than 25 years Javascript dev is still a mess. Thank goodness we have people such as you to guide us through the forest.

[@kyrregjerstad]

how did you do that little magic file-switching trick at 0:24? :O

[@felixgraphx]

Ctrl+ a number switches tabs. E.g. ctrl+1 or ctrl+2 , etc...

[@Novascrub]

the even/odd release/dev pattern started with the kernel during the v2 era, iirc

[@randyt700]

Why are there efforts/resources being spent on maintaining two module systems? Shouldn't the community and tooling just move forward with ESM?

[@mattpocockuk]

Yep, we're trying

[@kupopo1]

It turns out adoption problems are Really Hard. Imagine you maintain a common library. If you migrate to ESM then you're stranding any users who haven't themselves migrated. Not to mention the fact that a large share of codebases aren't even actively maintained.

[@ajv7038]

Would this support be available for building web apps with some dependencies no longer supporting common js imports in new versions?

[@Gakai08]

Hi Matt, thanks for the great updates on stuff like this. One quick question: Is there a reason to not use --experimental-transform-types instead of --experimental-strip-types? To me it just sounds like the superior version as it implies the strip-types flag too :o

[@mattpocockuk]

I just really hate enums 😂 But yes it's better

[@Gakai08]

​​@@mattpocockuk haha yes, I also don't like enums, but namespaces can occasionally be useful, as you mentioned in the react props pattern video.

[@mattpocockuk]

@@Gakai08 Yes, though you can use 'declare namespace' for those which dodges any runtime behaviour.

[@satanacchio]

--exoerimental-transform-types enable sourcemaps while --experimental-strip-types does not. So there is a performance advantage

[@ashuvssut23]

Whats the situation in Deno for this? can we use esm in cjs in deno?

[@SirusStarTV]

When we want to include node modules in our js bundle with import statements like import { foo } from "./bar.js"; How can bundler like webpack know if we need to bundle "bar.js" or just leave these statement as is because browsers support imporing ESM modules? Only absolute urls are fixed so that no one should interpret it in different way.

[@mattpocockuk]

Webpack won't leave any files as they are, not sure this is a real problem.

[@Yin117]

I adore your content, thanks for keeping me upto date 😀

[@zx-sy1qh]

This has taken too long in the oven to fix for node! Already have baked buns!

[@masterflitzer]

one should move slowly to esm modules, so legacy commonjs should be importable into esm, but importing esm into commonjs is just unneeded and people will continue to use commonjs that way

[@DefekacjaOdbyta]

Sure, if you’re starting from scratch, but if you have a legacy system that you can’t migrate to ESM just like that, then having the ability to import ESM from CJS can make the gradual migration easier.

[@edgeeffect]

The gradual migration has been going on for... ... ... how many years now?!

[@masterflitzer]

@@edgeeffect that's the problem, but i doubt this change will speed it up

[@lemontec]

ESM packages in Expo Router APIs here I come!

[@mzhomie8880]

Deno 2.0 ❤

[@samislam2746]

❤❤

[@Caldaron]

❤❤❤

[@Muhammed-zn7ft]

❤❤❤❤

[@fred.flintstone4099]

Yeah, I think Node.js is pretty awful and this Deno and Bun seems much nicer.

[@robertsandiford6223]

I think everyone knew this was needed, ever since ESM, didnt they?

[@vinception777]

God I love your videos, they are always super insightful, well explained and peaceful, thanks for sharing Matt☺🙏

[@renegadeace1735]

I was just dealing with this today lol

[@MinaLuke]

Is it only me who think allowing esm imports in commonjs files with such simplicity would delay the migration from cjs to esm 😅. With top level await is the only obstacle i see devs and libs maintainers would delay the conversion to esm even more.

[@bordeux]

ufff i do not care about it anymore with Bun :) It just works there.

[@ra2enjoyer708]

There is a lot of wrong information in this video, I'd attribute it to not being informed enough, but for sure the guy who deep dives into experimental typescript features wouldn't use NodeJS/Javascript and Typescript interchangeably when describing features, so I'd go over them one-by-one: - 0:08 - This is not an "error", but the result of community treating ESM as some sort of interchangeable syntactic sugar over CJS. Turns out when you have to interop a strict module system (ESM) with a lax one (CJS), you'd have to have pretty strict rules since you don't have a bundler luxury of infinite build time to make assumptions about modules so they would "just work" with any infinite input configurations. - 0:31 - There is no such thing as "CJS" in "Javascript". CJS module system exists purely in NodeJS and people (and a lot of tooling) assume it's javascript because of its close association with frontend development pipeline. Even ESM semantics differs between ESM in NodeJS and ESM in browsers. `.mts`/`.cts` also has nothing to do with nodejs or ESM, it's purely a typescript construct, which doesn't even provide guidelines on how you should tell them apart in `.jsx`/`.tsx` files. I assume it's `.mtsx`/`.ctsx` but good luck doing that without typescript/bundlers (especially "no config" ones) chocking on them. - 1:02 - It's quite an overstatement, this flag merely allows to write a subset of Typescript without a "build step". Naturally that means it will bring problems down the line when this code will have to interact with code which was written and distributed as typescript with a build step. - 1:40 - It's not so much about `await import()` (aka dynamic import) but ESM modules resolving asynchronously, unlike synchronous-resolving CJS modules. The example can be rewritten as promise chain without changing the behaviour. - 3:43 - It's not too funky, NodeJS gets away with it because it tells about this versioning scheme on its download page and structures said page accordingly. It not being a random lib which you can easily install off `npm` helps with avoiding the confusion also. In regards to top level `await`, I'd advice not using it even if your output environment supports this construct. It can easily kill any benefits of async resolution of ESM (by effectively forcing a sync resolution order on module graph) if not used carefully. It's only safe to use in "leaf" modules, aka modules which do not export any symbols, so things like the files you feed into `node` command line.

[@mattpocockuk]

- Yes, it's an error. ERR_REQUIRE_ESM, to be precise. - Yes, it's .mtsx and .ctsx. - Yes, how dare I simplify it down into a sentence. Also, I'm not saying you should distribute packages in TypeScript, that feels like a hallucination on your part. - I feel confident that my audience knows that async/await and .then are the same thing. - It's funky. Agree on TLA.

[@Pete133]

How incredible for this commenter to be so confidently wrong 🙃

[@ra2enjoyer708]

​@@mattpocockuk ​ - Loading a non-existent module is also technically an "error" but it's not the one nodejs can fix by rolling a new version. - Need a source on that. The only source about these extensions being real is your site, they aren't mentioned in typescript docs and were only brought as a talking point during a design meeting in typescript repo with no apparent resolution. - "writing typescript without typescript" implies that you can freely consume and distribute such code on npm.

[@mattpocockuk]

​@@ra2enjoyer708 - I don't know what point you're making here. - The source is I just tried it and it works. - No it doesn't.

[@duytdl]

Finally! Also to anyone lamenting CJS, it's not about moving on, it's about maintaining backward compatibility. I'm guessing y'all are noobs and only started coding a year ago. When you'll have a gazillion old little utils and modules, you'll understand the significance of not wasting 6 months every 6 months just keep upgrading all your code.

[@Derrickasaur]

Additionally, backwards compatibility is in tune with the JavaScript ethos It's always been the #1 rule of the web and it's what makes JavaScript a great language - the CJS/ES6 divide is unnecessary if the two modules can officially co-exist (they do unofficially anyway, since there is generally a workaround for using one or the other or some combination thereof)

[@ordazgustavo]

Ubuntu also uses odd numbers for non LTS releases

[@mattpocockuk]

Good to know!

[@rawallon]

Node 23 has the sauce

[@Iammrunkown]

Use Deno

[@fred.flintstone4099]

Yeah, or Bun. Both Deno and Bun seems much better than Node.js.

[@Iammrunkown]

@@fred.flintstone4099 Bun sucks as it does not even support Node properly. Next.js does not work without installing Node. Whereas Deno is secure by default, has built-in browser APIs, is faster than Node, has a formatter and a linter, has its own JavaScript registry, has zero build-time, supports Node completely, and so on.

[@danielsharp2402]

At least for me most of the friction with ESM is that commonjs "just works", you can import without the stupid looking .js extensions in typescript, index exports got fucked because someone thought it's a good idea. CJS just works as expected with the interop flags people are used to in tsc. The moment I try to use new module resolution etc errors keep popping up. This is why CJS is still used because ESM is a big old mess.

[@ra2enjoyer708]

This sounds like a typescript (and bundler) problem more than anything. Also you've got it all backwards - It's CJS being a giant mess which was quietly sweeped under the rug. I strongly doubt you've written a lot "CJS" code to have any strong opinion on it. Chances are it's merely a buzzword somewhere in your build config file and all your input code is just a microsoft approved ESM-like syntax which doesn't rely on a single "feature" of CJS.

[@nomadshiba]

using esm in commonjs shouldnt be supported. it should be one way. this update will only make lifetime of commonjs longer

[@bigmistqke]

Wrong. It is one of the reasons so many libraries are still published in commonjs. Anything that helps migration is a good thing.

[@edgeeffect]

Deno 2.0 fixes the worst things about Node. ;)

[@mo3k]

"fixes the worst thing about JavaScript" is a very clickbait title considering this has nothing to do with JavaScript, it's a node thing AND it's no where near "the worst". Thx for the video though.

[@mattpocockuk]

The ESM/CJS divide is genuinely one of the most divisive things about JS. Node is EVERYWHERE in the JS ecosystem, and improvements to it ripple out to a huge part of the JS world.

[@dada78641]

It's insane to me they didn't launch modules with this feature. As is the module transition was Node's version of Python 2 to 3, and now years later they're like "lol jk we're making it painless anyway!" By far most libraries don't use top level await because it's a bad practice anyway (unless you really need it for some reason).

[@dada78641]

But then the import/export syntax itself was inconsistent and confusing in its first iteration so I guess the whole thing was just needlessly ill conceived from the start.

[@MrMudbill]

I refuse to believe there are any sane people left using CommonJS

[@twilightdev]

So odd version of node has odd behavior

[@cryptixdaemon7236]

Fake it till you make it, that's JS

[@chrisstroud1915]

I read the thumbnail as ”Worst Burger" and was so confused

[@samislam2746]

Finally!!!!

[@danser_theplayer01]

Just ctrl + F, match by regex, replace all require() with import() and stop using common js.

[@rafadydkiemmacha7543]

It's brave to call this a game changer. Pretty sure 99% of Node users don't give a damn about this anymore.

[@mattpocockuk]

Definitely a game changer for folks who ship libraries.

[@mattpocockuk]

And TBH, anyone using Jest.

[@erics2133]

@@mattpocockuk That was one of the side benefits of my dropping Jest for vitest.

[@PieterWigboldus]

A bug? For me it sounds like a feature that wasnt build. The new chance wil make it a lot easier for ESM packages that dont have to generate a CJS version anymore.

[@SolmanNurov]

finally

[@akam9919]

I fail to see why they can't just block the event loop for any top level awaits. Is there *really* that meaningful a difference? Perhaps a future flag for handling top-level awaits when importing esm in cjs. Perhaps even an future where one can customize how one "requires" a module, regardless of it being esm. Though, maybe the real fix is updating commonjs spec to just allow top-level awaits. This is a very arbitrary decision to begin with that would have very consequences (assuming it treats a top-level await in an module the same way that esm does).

[@Patterner]

"cjs is old, use mjs" node developers [citiation needed]

[@kilo.ironblossom]

Ohh!! This bloated ecosystem again 😂

[@shapelessed]

Still better than that of C++

[@abcq1]

With this title I expect to hear that Node.js 23 erased Typescript from history and executed its inventors. Lets see.

[@edgeeffect]

Back in the long ago, I was in the process of migrating from C++ to Ada... and I was all "oh, I love how this strong typing prevents me from making so many errors and leads to more explicit/readable/maintainable code" then in jumped Perl, Python and Ruby with their "let's throw away types enttirely"... well, When Python, TypeScript and PHP started putting the types back in, I threw a massive metaphorical "welcome back home typesystems" party.

[@abcq1]

@@edgeeffectTypes are cool in places when they are appropriate, like C++ or Rust. When the comiler needs to know ahead of time how much memory to allocate and how to handle it. But not in JavaSscript. Typed JavaScript is like C++ without types. Nonsense.

[@recursiv]

@@abcq1 Types are for people too.

[@edgeeffect]

@@abcq1 that's half of the purpose of types, yes... but only half.