Import vs Require: The Biggest JavaScript Divide

[@mattpocockuk]

A note on Bun: Bun lets CJS modules import ESM as long as there's no top-level await in that ESM file. This makes sense, and makes me slightly more optimistic that Bun have thought through the impact of their interop.

[@mghost4416]

i remember the "top level await is a footgun" gist, and was disappointed when the original author retracted their take. i hope TLA will not be missed.

[@RasmusSchultz]

what do you make of tsx? (TypeScript execute) ... it seems to "just work" and makes cjs esm work seamlessly.

[@muhammedsalihaltun8779]

Whenever I run into a CJS vs ESM problem, I take a break. It's extremely annoying. Worst thing about the ecosystem.

[@Dorgrin]

I should’ve done this instead of shooting my foot for a few hours today.

[@nomad_swe]

The editing in this video is top notch, sleek and tasteful animations, simple and elegant. Really well done!!

[@edupsousa]

Nice video, I started emitting esm only a while ago and the migration was not so sweet. I became stuck with small details like having to use .js extension in my TypeScript imports, or allowing to use the .ts extension but stop emmiting code with TSC. It would be great to have a follow up video about the migration process of an existing codebase and the choices the developers need to make when doing it.

[@erikras]

As a JS Olde, I still remember RequireJS, the initial idea of being able to "import" multiple JS files into the same bundle... also shoutout to browserify!

[@slava_trushkin]

Problem with switching to ES modules is, many users are still using CJS. So if I release a package with ES modules support only, I will end up with some React user complaining that his CRA that uses ancient version of WebPack cannot use ESM. Too many users using outdated dev tools make it next to impossible to support ESM. So I publish packages with both ESM and CSJ, which also requires adding exports property to package.json to point to correct file depending on require/import (and types to make things even more complicated)... such a mess. Then there is `assert` mess, which affects importing JSON files, but that's a completely different mess. Sometimes I wish Node would just remove require() in a new major release. That would be a shock to many users, but a necessary one.

[@avid459]

Just release a major version dropping support for cjs

[@oscarljimenez5717]

Everyone: Should we use ESM is better Nestjs framework: Nah, we want to cause more problem to the ecosystem (using Decorators and not using ESM).

[@ApprendreSansNecessite]

Oddly enough, CommonJS is what forced me, as a designer (mostly) at the time, to have a build step in my process, because it was getting harder to find Javascript libraries that didn't use it. I hated it because the web should be accessible to the non-initiate, but it was a milestone to adopting TDD, type systems, pre-processors, continuous integration, etc. because when you have come to a point where you need to build, then adding more tools is not a problem. Now I still hate CommonJS for this incompatibility issue, module resolution problems, etc. It is SUCH a pain, but I'm also thankful in an odd way.

[@dinckelman]

I use ESM for anything I write for myself, but when it comes to libraries, I just emit both CJS and ESM, and the rest is your problem. Doing so removes the headaches from me, however if you still want to use CJS, I guess you can

[@a-yon_n]

I publish libraries in two forms, sometimes even three, including Deno support. But to myself, I personally use CJS more often, because it allows me to implement hot-reloading, which is not possible in ESM.

[@modernkennnern]

Using require in 2023 is like omitting "use strict" just because you like the `with` keyword. require is legacy; import is the "future"("future" actually meaning "present" for many years now). It only exists because of nodeJS backwards compatability reasons.

[@Dev-Siri]

this video is powered by the view-transitions api

[@mattpocockuk]

By Apple Keynote!

[@AlvaroDevLabs]

Best explanation out there of the why, and you answer the most common question, should I force ESM only? It's always depending on your users. Great video.

[@fagnersales532]

I really dislike having to handle what I emit in this type of situation. Which made me love Bun's approach to CJS vs ESM.

[@ra2enjoyer708]

And by doing that it contributed to the problem further in the form of js code with questionable syntax.

[@NateLevin]

@@ra2enjoyer708 Bun's CJS support is for compatibility. Jarred Sumner himself has said that you shouldn't use CJS for new code

[@TymekDev]

Such a clean edit! That was really pleasant to watch 💯

[@Gabriel-iq6ug]

So entertaining video! I love this new format

[@zettca]

We should be talking about how to gracefully deprecate and move away from CJS, not how to interop CJS with ESM... Bun is just adding salt to the injury by having first-class _non-spec compliant_ CJS support. CJS is a custom implementation from NodeJS that appeared bc there was no alternative. But we now have an alternative! The *official* alternative! That was released long ago... And there's much more it that just "import * from 'package'". There's all the import.meta.* stuff, http imports, etc. Sadly if it wasn't for Vite's usage of import.meta; it'd barely be known. Deno implements all these and many other standards OOTB and is barely ever mentioned in these discussions.

[@a-yon_n]

Don’t you ever wonder why Deno is so unpopular? It’s because of its lack of compatibility with the existing ecosystem. Vite and Bun choose to solve the compatibility issue at first, that is why they’re promising and Deno is not.

[@djSeakDigital]

I was literally teaching code splitting today. Great explanation 👌

[@rohitkharche7562]

I think library publishers should specify a note like: This library is not for cjs imports users, that's it. If this movement starts from major library publishers, this could also solve the problem although by forcing them to use esm imports

[@mattpocockuk]

node-fetch did this and got absolutely slaughtered by their .cjs users. This is part of why the debate is hard - lib authors want to move to a simplified publishing setup, but also don't want to screw over their users.

[@Guergeiro]

​@@mattpocockuk not only that. Even if you want to use node-fetch@3 then you need to change your ENTIRE project to use esm. Fine by me, but the reality is that the majority of stuff doesn't even work with esm. Nowadays its more accessible, but I remember the days that even for frontend frameworks (which emit code for the web), they required your dependencies to be cjs.

[@kesor6]

@@mattpocockuk and for good reason, new versions of node implemented Fetch API. And node-fetch has always been a polyfill for older versions of node. This is the absolutely worst kind of library to migrate to "esm-only", since most of its usage is in environments where only old-er Node.js is available (v14, v16, v18) at the time they did this.

[@Dude29]

@@mattpocockuk Tough. Progress has costs. Keep using an older version if you don't want to make the effort to swap require for import

[@niccommander]

@Dune29 unfortunately this is not always so easy. Especially if you work with tooling like nx and nestjs in a monorepo with several older applications and you have no time / money to rewrite everything

[@franky47]

Feels like 2015 again when we had multiple (sometimes incompatible) implementations of Promise.. How did you make those animations? They look slick!

[@4AlexeyR]

I met this pain point too about year ago and put it on hold. Now with more stable situation, Bun, Vite at so on it is time to back.

[@raph151515]

a big offender was or is for instance treejs that took forever to start migrating, now some things in the docs are not representative to the modern version and apparently the tree shaking is not yet fully working (smaller packages) because the architecture doesn't allow it, since it was developed with CSJ in mind and without tree shaking. So you sometimes need to import and refer to some module member to force the bundler to include missing code. The bundle size is better but personally I find it extremely big is you don't use all the features. Designing a library from scratch with imports in mind (proper separation , stateless modules, etc) makes your future life way better and your shipped packages potentially way smaller. Imagine you want multiple output and each of them are different subsets of the codebase, now the tree shaking will make wonders, or the lib user want to import and use specifically just a few functions, they surely don't want to include your complete package.

[@emkisn]

Superb video! Concise, suuper informative and easy to follow, love it ❤

[@saskirakosyan5268]

Its fun listen to you, you are clever and not only engineer.

[@ExponentialWorkload]

i emit cjs and esm - simply outputting 2 separate files is great :)

[@josipX]

Great video as always mate

[@samislam2746]

This is the worst nightmare in JavaScript

[@adebiyial]

Nice one. Now I understand what's in the cake I've been eating. Also, any chance there'd be more videos like this or a series perhaps? "CJS vs ESM: The never-ending JavaScript divide". "A vs B: The never-ending JavaScript divide"...

[@yourDecisi0n]

Yea, I tried getting rid of CJS, but to my knowledge Jest doesn't support ESM apart from an experimental solution, which therefore limits the usage of ESM for me and I'm sure that's not the only time I would run into problems in the future, so I might either emit both a ESM version and a CJS for my modules or just use CJS

[@mattpocockuk]

Yeah that is really tough. I can say that Vitest is extremely good - I haven't used Jest in a while. But of course, you want to be shipping features and not worrying about plumbing.

[@tiendang5149]

The best video that I found 🎉

[@adambickford8720]

Fun fact: node was at least a decade behind the server-side js 'innovation'.

[@JeremyKolassa]

I saw Dual Package Hazard open for Kernel Panic at BlackhatStock 2012

[@mattpocockuk]

I was there! "Cache Miss" as an encore was epic

[@TienNguyen-un7lo]

thanks for the explain cjs and esm :D

[@hlkz7067]

I'll use ESM when : - we won't have to specify the file extension in the import - we'll be able to import what ever file we want from a module - also the import folder with the index file use was a good idea imho CJS feels like more freedom, and thats the reason I love JS in the first place. The sync/async problem is not a problem anymore once you stop relying on file exec order, for this part CJS should convert to the ESM's way.

[@Cahnisama]

More like this please.

[@4AlexeyR]

Thanks for the short explanation. Does it means that I can write a code with ESM way but use old require based cjs modules and compile/bundle it to browser and to nodejs without changing my code? ;)

[@MrMudbill]

For years I've done all I can to avoid using `require`. I don't ship packages with CJS. Bite the bullet.

[@thepetesmith]

We had AMD, which solved all these problems. Dojo had this in 2008 with requirejs.

[@joepetrillo6185]

Awesome video. Correct me if I am wrong. In a perfect world, ESM is used everywhere for everything and CJS never existed. However, since many codebases are using CJS, packages can’t just end support for it? Does it just come down to older software? Id love to see another video about configuration of all this and explaining how CJS works vs import (you mentioned synchronous vs asynchronous, etc) and typescript/bundler configuration. :)

[@ra2enjoyer708]

It's worse, the problem is not just an old CJS code (which gets consumed just fine by ESM with almost no issues), it's a slew of pseudo-ESM code generated by bundlers and typescript in-between ESM spec got announced (2015) and NodeJS released ESM out of beta status (2020). Until 2020 people treated ESM like a fancy syntactic sugar for the javascript source code, not a bunch of reserved keywords with specific semantics. And bundlers fed into this belief by "abstracting" away all the problems of CJS, which caught up once ESM became an actual runtime. So any solution which claims to solve this interop with an install of another CLI tool only pours more gasoline into fire. Because it ensures the "legacy" code is still being produced forever. The only real way to solve this is for the majority of packages to semver major up to ESM-only format and the consumers (and therefore bundlers) to deal with ever increasing amount of outdated dependencies. Which is ironically what semver was intended for, but for some reason a lot of people treat semver major like a semver minor but with an advertisement campaign on top and then get upset when a package rolls out a semver major with breaking changes.

[@Dude29]

@@ra2enjoyer708 based take

[@joepetrillo6185]

@@ra2enjoyer708 I don’t get it 😅

[@BlueBabyPufferFish]

I need to test it out... can esm do this? if (ok) { import or await import(...) }

[@mattpocockuk]

await import yes, not sure about import in that position.

[@ra2enjoyer708]

`import` is a keyword in a ESM context, not a symbol you can pass by reference. And static imports are only allowed at the top level scope of the module and can't be conditional. So no.

[@maelstrom57]

@@ra2enjoyer708 I take it you're not familiar with dynamic imports.

[@avid459]

You should talk about .mjs and all the bizzare choices there

[@boian-inavov]

I’d love to kill CJS, but it’s not always a possibility. Especially when using backend node tools that are at least 5 years behind the curve, if it ain’t broke and all. So yes, that’d be lovely to do, but it’s not always possible due to, you guessed it, legacy 😢

[@stxnw]

tell ur manager to give u 2 months off for a full refactor

[@cristianpallares7565]

5 years old node... That's dangerous 😅

[@a-yon_n]

Why make the change when it’s worked so well?

[@stxnw]

@@a-yon_n for the future

[@mixtv3668]

i loved that man keep goin' on that 😎😎

[@nickderaj]

Such a basic thing but I think a lot of people don't know how this is even working, but luckily TS has options to scream at you if you write require

[@neociber24]

Oh man, I'm developing a TS library. How can I compile it to esm instead of cjs? Or should I output both?

[@mattpocockuk]

You should probably emit both. tsup will help.

[@Dude29]

3:18 Don't sell yourself short my guy, I consider you a 10x aswell!

[@juniorrokudevelopertutoria3734]

So, Node.js mostly used common js, and react uses new and shiny modules system

[@mattpocockuk]

Yes, but now ESM is recommended (and very well-supported) on Node.

[@juniorrokudevelopertutoria3734]

@@mattpocockuk Okay, so if I am learning node.js i need to learn how to use ESM too.

[@mattpocockuk]

@@juniorrokudevelopertutoria3734 Yes, ESM for everyone

[@DobesVandermeer]

I think it's time for a new JS module system to come out...

[@mhadi-dev]

I think it's hard for a framework user to decide which to use, I use NestJS, which unfortunately emits CJS.

[@edgeeffect]

If your framework only emits CJS, then that's a sign that maybe you picked the wrong framework????

[@mhadi-dev]

@@edgeeffect An old framework doesn't mean it's wrong. don't forget that ESM is still new and not used a lot. The vast majority of npm packages are CJS

[@jaredsmith5826]

Spicy hot take: ESM was a mistake. Yes yes, I know it's been a huge boon to tool authors and static analysis (and I'm a fan of both). But before ESM we had synchronous native require on the server and asynchronous module definition (AMD) loaders in the browser and UMD that played nice with both. This whole mess that's been going on for a better part of a decade now is solving a problem we created for ourselves. I'm struggling to believe the (still ongoing!) juice was worth the squeeze here.

[@ra2enjoyer708]

> But before ESM we had synchronous native require on the server and asynchronous module definition (AMD) loaders in the browser and UMD that played nice with both. They never played nice together in the first place, webpack just made you believe you so.

[@ColinRichardson]

Mr. Wizard, I still need your head size..

[@james-cucumber]

Lip sync is off at the start

[@CottidaeSEA]

This is one of the reasons why I dislike the JavaScript ecosystem. I enjoy JavaScript as a language, but there is just needless complexity when it comes to tools and configurations.

[@anupammaurya6624]

Why background music 😢

[@尼古拉丝土豆]

我这几天正在挣扎这个问题

[@garretmh]

In an ideal world require would be converted to a synchronous import statement and “exports” would be removed entirely. In reality, I don’t see a reasonable path to that.

[@113bast]

The audio seems offbeat

[@ayushgogna9732]

well said

[@stewiebrown1520]

oh, yeah, I love writing ESM while using typescript when your files called .ts or tsx, but imports should be .mjs or .mjsx, importing files that are not exists yet! nice and easy

[@felipek.deboni8157]

I already knew it, what I don’t know is why they chose import x from package instead of from package import x. Can you explain this design decision?

[@louroboros]

I just want to not think about this anymore please

[@RedStone576]

commonjs is here to stay

[@raph151515]

so many companies a still shipping old heavily transpiled cjs code to prod, what a waste

[@Joshua-yc9ei]

Thats a really good explanation of the differences between CJS and ESM. Unfortunately I have still yet to hear a simple explanation of “why” ESM is “better” and worth putting the time and effort into moving things over.

[@mattpocockuk]

'CJS doesn't work on the web' feels like enough for me

[@seannewell397]

I'll bite. CJS is incompatible with how works in the browser; you need requirejs to ship require calls. ESM is essentially, a tag that knows how to extract a value from the script it contains. You can ship ESM to the browser, today with type="module". As an aside, I am not interested in if CJS vs ESM would be better for the language at the spec level - that, for me, is a settled question because TC39 already actioned and spec'd ESM and browsers already implemented ESM.

[@mattpocockuk]

​@@seannewell397 Agree. Quick clarifying question: > you need requirejs to ship require calls These are basically async calls, right? Similar to await import(). Except it uses a callback instead of a promise.

[@IvanKleshnin]

No static analysis -> No tree-shaking; Much worse auto-imports in IDE, related issues in TypeScript...

[@Joshua-yc9ei]

@@IvanKleshnin static analysis and tree shaking is a big benefit for sure! Thanks

[@Ostap1974]

I personally have no use of using ESM for Node projects and will only migrate to ESM if I am forced to or it is made doable in 15 min or there is a measurable gain in smth. Tried some time ago and rolled back. Not interested in spending hours to get smth working (again) that was working before with no real benefit.

[@maelstrom57]

What about your IDE resolving imports automatically? Do you enjoy typing out 'const myPackage = require("my-package");' a million times?

[@Ostap1974]

@@maelstrom57 I am using typescript, there is not a single require in the code, IDE is importing all needed automatically.

[@maelstrom57]

@@Ostap1974 Your original post is weird, then. You make it sound like it takes effort to switch to ESM although it's only a property or 2 to change in tsconfig.json. Sounds like you tried once with a wrong config and gave up.

[@Ostap1974]

@@maelstrom57 Main issue was that most of the tooling and external libraries just stopped functioning. As told earlier, I see zero benefits in migrating to ESM for my NodeJS apps. I would be happy to be convinced opposite.

[@helleye311]

It's funny, I watched this video when it was released, and now I started a new job and we're not using type: "module". Seems like I'm the only one that cares about it.

[@gyoby_toys]

Very fast explanation.

[@raph151515]

people should stop install libs that contain CJS and never use it in their own code, that's all, that's call progress, I come from AS3 that had imports and I will never work with require. The dumb thing in node is the default behavior to require es6 code to have mjs extension. We can't have 1 extension for each version of JS

[@HudsonAfonso]

bun

[@pawieplays]

I'm currently having this issue. It's the most annoying thing. I just want to code without all these.

[@snowytones]

I hope at some point we can just have a single distribution and eco system for a target platform under a unified standard. This is like Linus' Debconf talk on different separate distros vs one official distro for a target platform all over again.

[@gosnooky]

ESM is great, but there are still thousands of NPM repos out there that while still relevant, are still commonJS, peppered throughout with vars and module exports. It is irritating that some of the hardcore JS holdouts like the author of chalk simply dropped support for CJS, and will not release future patches for CJS. Thankfully TS has esModuleInterop that helps, but it is indeed very messy. Hopefully Bun becomes prominent enough to influence and perhaps in the future truly standardize this stuff, because as much as I disliked Java, there was standardization that did away with all these concerns.

[@ra2enjoyer708]

ESM is the standard though, why should package maintainers (most likely doing it for free) bother supporting a non-standard module system? Especially when the reward is debugging dual-package hazard issues for eternity.

[@gosnooky]

@@ra2enjoyer708 In a word, backwards compatibility. Node kind of opened up this can of worms to begin with, but what about all those CJS libraries out there that are 10 years old, simple enough that nothing ever needs to be upgraded and sit there on NPM with millions of weekly installs? While I agree modules are the right way, we can't rewrite history or flat out remove any old libraries or compel the original authors to migrate to ESM. Especially if these libraries are deps of others. Where does the cascade stop?

[@ra2enjoyer708]

@@gosnooky Ironically the problem is not 10+ years old libraries, because they would be written in a proper CJS, and ESM works with them almost just fine. The problem is the libraries which got fed into a bundler after 2015 and outputting mixed code which is considered erroneous by Nodejs module resolver.

[@krtirtho]

Hey why didn't u mentioned my personal favorite UMD & AMD?!! Now I'm offended /s

[@pxkqd]

It's always said that the good thing about js is the ecosystem, but honestly most packages you don't need. Just find alternatives that already use esm and drop cjs altogether.

[@oszi7058]

yes and no => Yesn't

[@AlpharderCodes]

No ESMs till TypeScript requires specifying .js extensions in order to emit code

[@marble_wraith]

This is contentious?... ESM. End of the line, case closed.

[@Dude29]

The guys behind node don't seem to share that POV

[@garretmh]

There are things that are possible with require but not import that have performance impacts. So having a “synchronous import expression” can be really valuable on the server. It’s just a shame the one we have isn’t compatible with ES modules.

[@maelstrom57]

@@Dude29 Ryan Dahl himself recommends using ES modules. You're such a boomer.

[@Dude29]

@@maelstrom57 no no you misunderstood me. I'm all for ESM aswell. I was just saying that some of the folks behind node don't share that idea and are somewhat resistant to its adoption which isnt helping anyone and just generally slowing things down even more Don't shoot the messenger 😅

[@bilalazhar4495]

front end devs got nothing better to do they would make new framework to feel better (COPIUM) or just tell other devs how the framework they are using is just shit

[@ДенисСоколинский-о5я]

Migrating a project from cjs to esm brought me the worst dev experience of all my life. Yes, esm is cool and all, but the amount of things to fix is totally unbearable. Not to mention that custom esm loaders are still considered experimental, and this leads to many things marked as experimental such as yarn PnP, and it is not ok.

[@ussskynet8590]

The origin of the problem is that we have front-end and back-end people forced in a sense to use the same language. We are separate worlds with different requirements and paradigms. We on the back-end should be able to require what ever we want in Node.js. Those people with 1001 different framework that all do the same s**t on front-end should import to their browser desire. In ideal world we should not communicate, but if we have to, only through REST and maybe events... Maybe...

[@ra2enjoyer708]

Nodejs also has 1001 different webserver frameworks. And they all do the same shit way more exact than different frontend frameworks. Also ES Modules are, you guess it, a part of ECMAScript spec and nodejs, being a javascript runtime which already implemented a bunch ECMAScript interfaces, would have to implement ESM, a core feature of ECMAScript by the way, sooner or later.

[@erikslorenz]

This is honestly just the dumbest thing and such a failure by node. This should have been solved years ago and pretty much all popular packages should be in esm now (or both). When typescript really took over like 2018/19ish there was maybe a 2 year period where some packages were really badly or not typed, but then they all either got typed or new ones took their place and it was over. This esm thing has been dragging on for like 3 or 4 years and there is no end in sight And i dont think people are all that split. Wouldnt a switch for a dev just be changing the tsconfig output to nodenext and then adding module in package.json? I think most people have been writing imports in esm syntax for years so its not like theres some weird style preference for require

[@ra2enjoyer708]

Why is it a failure by Nodejs? Its ran by volunteers and implementing another module system on top of existing one is a huge task which can only take huge amount of time in these circumstances. Funny you mention typescript, because it is at the center and is partly responsible for the trashfire of the situation. > And i dont think people are all that split. Wouldnt a switch for a dev just be changing the tsconfig output to nodenext and then adding module in package.json? Not really, because in this mode it will start to consume "ESM" exports of wrongly configured packages and you'll get cryptic errors at module resolution time. And you better hope this error happens at build time, because at runtime it's going to be a mere syntax error raised by nodejs ESM lexer pointing to transpiled code. > I think most people have been writing imports in esm syntax for years so its not like theres some weird style preference for require But they think they are interchangeable and that's the core of issue.

[@erikslorenz]

I mean that if es modules weren't a problem there wouldn't big any real difficulty getting people to switch over. It's not the idea of switching that stops anyone. People only stay with CJS because ESM ends up with a bunch of bugs as you said. Once JS moved to an official module system this should have been top priority. @@ra2enjoyer708

[@shapelessed]

Call me evil, but I don't care about people. All my NPM modules are written in CJS. Why? Why get stuck in an old system that's exclusive to a single runtime? Why not to a standard? Want to use my code in your CJS project? Tough luck, adopt the standard or use a bundler 😛

[@shapelessed]

(To be fair they are mostly helper tools. Such as my recent CLI to i integrate compilers and bundlers into one terminal, specifying watchers and other events that I couldn't be bothered to do by hand, it does need a JS config file though)

[@jamesm6830]

Bet you're fun to work with

[@Dude29]

Dont you mean written in ESM?

[@powerrampage]

1

[@dufifa]

require is still using in JS? AHhahahah