> I'm not a web developer so I had a very hard time understanding why there are so many different type of imports in JavaScript like require, import, umd, amd, etc and which one works in browser and which one works in node?

If I remember my history correctly, it's because when Node first came out, there was no import system in JS, let alone a standardized one; there was no sense of scoping (everything global), nothing about dynamic or lazy loading of dependencies, no tree shaking / removing unused code, and even going to the definition of something in an editor was difficult.

NodeJS adopted CommonJS (I don't recall if they invented it), which is a module and dependency system based on require() and exports. It was only a few years later when the JS standards body settled on import; by then, the JS (dependency / module management) world was already very divided.

Those have been supported for several years now :)

You need to tell Node to use the format by either naming your file `.mjs` or setting `"type": "module"` in your `package.json` file.

> Also why do so many libraries have this strange 5 line header code for this umd, amd, business. Is that to make their packages work with nodejs?

That's just old for "adapt the module system" from the old days and libraries just didn't bother updating.

I still use amd in my job at Microsoft though for some things so I guess it's not useless :)

"supported" is somewhat of a misnomer IMHO. It's only supported if the other tools you're using support ESM. Otherwise, it's not. And it's really annoying when libraries choose to go full ESM because it breaks things like tests and deployments in weird ways.

It's a pain in the ass.

It's really annoying when libraries don't support a 7 year old standard, as well.

Node supports ESM, full stop.

No, it doesn't. It forces you to use a special extension that breaks the code in browsers.

> either naming your file `.mjs`

But why? This makes it much harder to ensure that identical code works in browser and nodejs, to the point where I sometimes just can't use nodejs. And I don't use package.json, so having to name files ".mjs" is a really painfull restriction.

Browsers will happily accept `.mjs` files they don't actually care about file extensions only about `Content-Type` and type=module on the script tag :]

Plenty of (third-party) imports specifically reference "*.js" files so no, this doesn't work.

There is absolutely no need for a package.json when using ES6 imports without a build step. Package.json doesn't do anything when I'm loading the code in a browser, why would I have to use it when I want to run the same JS code with node?

this is a silly point. it's a different runtime, there are also different apis available - as is the point of this article. node is not an internet browser. but ok

If you're hosting the browser-based version over a server like Apache2 (to host the files), you could add a `RewriteRule` to redirect queries to `.js` resources to their `.mjs` counter-part files.

Example: RewriteRule "(.*).js$" "$1.mjs" [R=301 NC]

Reference documentation: https://httpd.apache.org/docs/2.4/rewrite/intro.html

Several years is a bit of an exaggeration. They were "experimental" until 20 months ago.

Import is slowly becoming the standard, but working with typescript professionally modules has easily been the most annoying part of the Node experience.

It works pretty well, and then you need to use something like Azure Functions and then suddenly it doesn’t. For various reasons.

My most recent example was using lodash, which works perfectly fine with import with typescript targeting esnext in node16, but then needs to be setup with require when you target an azure function and commonjs. I mean, maaaybe you could avoid it by using mjs, which is currently sort of needed to move into the node16 functionality in azure functions, even though they sort of run node16 just fine in part of them without it, and you sort of don’t want to use mjs files and so on.

I’m sure it’ll get there in a few years, but it is no doubt annoying to have to fight the toolset ever so often. Over something that feels like it should just be working.

That last part isn’t really exclusive to node these days though, is it?

I had the same problem so for serverless functions I am using standalone webpack config which transpires functions into the supported by the cloud format

In short, node has imports, browsers have imports, but node-related toolkits do not support it, and people still webpack bundles because development and deployment processes are a thing, and it doesn’t matter much which module system a “binary” bundle uses in the end.

Some people tried to force ESM adoption by making popular modules ESM-only for no technical reason, but tools are not there yet, and it only annoyed (predictably) half of the internet. Because even if you are pro-ESM or indifferent to it, you can’t do much to migrate your projects’ build pipelines. If you see typescript and webpack, you wouldn’t see “ESM” in there. It either doesn’t work or is too fragile for production.

People who claim it’s done say so because they are using particularly unaffected stacks (including no stack). Idk which way to promote ESM would be the most correct, but this one is too deceptive.

Going X-only for a political reason is not a good one, especially if the standard is of a different platform, which had no X at all back when the de facto standard was set.

Node supports ES Modules (the import statements you mention) natively now: https://nodejs.org/api/esm.html

> Does anyone who knows enough JavaScript point me in the right direction about it. I find all this very confusing.

There isn't a straight forward solution, but the closest for me is the combination of using a transpiler (Babel), and a bundler (Webpack).

A common criticism on node/javascript projects is the boiler plate setup required. As far as I know, there isn't an IDE that takes care of doing this part for you, where your experience developing outside of the web might (I like to think it akin to starting a project from scratch with C++, gcc, and make).

Some larger projects, do have scripts that do a lot of boiler plate for you, such as Create-React-App. https://github.com/facebook/create-react-app but that is for a specific use case.

  there isn't an IDE that takes care of doing this part for you

Did you try WebStorm? Any setup specifics that it doesn't support for you?

I've tried WebStorm in the past, but it was prior to the explosion of application development with javascript.

At the time, I was using sublime, and now I use AWS Cloud9 exclusively.

I been naming the files with .mjs file extension which allows import keyword and top level await. No special flags needed in the latest version. I use JS not TS.

I know this comment is not very helpful, but the lack of a module-system and the lack of threading are unfortunately the biggest issues that JavaScript had from the start.

Modules are pure joy now though. Im gutted it never really turned up in c++!