Import vs Require: The Biggest JavaScript Divide

the JavaScript Community is split into the JavaScript Community is always arguing about something or other but this argument has lasted four years and shows no sign of stopping it's about something that's pretty fundamental to the way that we write JavaScript apps which is how should we split up our code you might think especially if you've come from another language well that sounds pretty basic surely you would have figured it out by now and the answer to that is yes and no let's talk about common JS and Es modules the reason JavaScript was invented was as a scripting language for web browsers but when node.js came out people realized they could use it for servers and other applications too in the browser you didn't really have to think about modules everything was just in the global scope but if you were building a complex server you couldn't just have it all in one file so they invented a module system called common JS which uses a function called require to let you pull in JavaScript from other files and access functions that are exported from them eventually JavaScript itself thought this is a really good idea let's take these ideas and do it in a way where it's going to work on the web so for a now famous version of JavaScript called es6 they came up with imports and exports and if you're writing modern JavaScript today this is pretty much always what you're going to be using you might think why didn't JavaScript just use the require calls that were already there well require is synchronous this works great in an environment where you assume you know all the files are there but not in the browser where you might have to wait for external resources and so the split was born a lot of people moved to the new es modules because they were cool and really nice to use but a lot lot of people stayed on the common JS let's talk compatibility if you're using ES modules you're absolutely fine to import comma.js but if you're using common JS you can't import es modules except for if you do it using this kind of async function thing that mimics what an import does anyway this means that if you're publishing a package then you have to be really careful with what you're shipping if you only ship es modules then your common JS users are going to be really annoyed but your es modules users don't want to import common.js because that's going to break in the browser so it is a mess and Publishing a package becomes extremely hard because you need to cater to both of these situations and if a user does a require and an import on the same package they'll end up with two versions of that code running which can cause all sorts of issues that's called dual package Hazard by the way there's a wrinkle to explain here too which is the bundler's role in all this if you're using any kind of bundler or transpiler or compiler then you're probably writing imports and exports a compiler like Babel or typescript will take those imports and exports and they can either turn them into imports and exports or turn them into common JS and this is the really weird part of the debate it doesn't matter what you're actually writing it depends on what you're emitting and a lot of people fall into the category of using ES modules or thinking they do but actually emitting common.js if you're not sure what you're using go take a look at your built code if you see required calls then you are emitting common JS but if you see imports and exports then you're a part of the future we should talk about bun 2. one of Bun's main selling points apart from performances that they've fixed the interoperability issues between common.js and esm so if you're using bun then you don't have to care about this divide they've done this in a way that is not actually spec compliant in other words they've patched together the issues between common JS and esm to make it work this is really exciting and I'm really Keen to see if it works and if it works really well maybe they can change the spec and boom problem solved but I have a little inkling of Doubt but who knows there are a bunch of 10xes maybe they've just got it mailed but if you're not using bun and hey even if you are using bun I still think you should care about esm JavaScript tool chains can be incredibly complex and one of the core reasons they are so complex is needing to support these two different module systems if you adopt es modules today you are helping make the web a less complex place to code in we have figured out the one module system that works everywhere all versions of node with long-term support are now using esm it's time for you to start using esm wherever you can and I'll link to a post below that explains how you can get started you should check out the other videos on this channel this is a Channel full of typescript craziness and JavaScript Madness and you should also check out my course which is at total timescript.com and otherwise I will see you very soon

Channel: Matt Pocock

Views: 50,823

Keywords: typescript, web development, advanced typescript

Id: 6_JNPmjSevo

Length: 4min 2sec (242 seconds)

Published: Wed Sep 20 2023