Module loader is responsible for loading modules.

What I know is module loader loads modules in browser asynchronously whereas in Node.js it loads synchronously.

I wanted to confirm whether this information is correct or not.

Module loader is responsible for loading modules.

What I know is module loader loads modules in browser asynchronously whereas in Node.js it loads synchronously.

I wanted to confirm whether this information is correct or not.

• javascript
• node.js
• module
• ecmascript-6

• 1 What's the question? ES6 doesn't specify how modules should be loaded and supports both. – 1983 Commented Aug 4, 2015 at 12:28
• So, which specific module loader are you asking about? Notice that node doesn't have an ES6 module loader at all yet, so we can hardly tell you anything about it. – Bergi Commented Aug 4, 2015 at 18:38
• @Bergi: Now it has. So what's your answer? – NeoZoom.lua Commented Mar 24, 2022 at 13:22
• 1 @Rainning Dependencies declared with import statements are loaded before any code is evaluated, so whether loading is async or sync is not observable. Module evaluation can be asynchronous; while evaluation of monjs modules continues to work as it did before. And then there's import() expressions which have an asynchronous return value, but it's not stated whether they load files synchronously or not. – Bergi Commented Mar 24, 2022 at 13:38
• 1 @Rainning I don't see how that ment is an answer to "What's the benefit of using ES6 module syntax" – Bergi Commented Mar 24, 2022 at 14:13

2 Answers 2

ES6 module loaders will be asynchronous while node.js module loaders are not.

Here are some key aspects of module loaders:

• Module code automatically runs in strict mode and there’s no way to opt-out of strict mode.

• Variables created in the top level of a module are not automatically added to the shared global scope. They exist only within the top-level scope of the module.

• The value of this in the top level of a module is undefined. Does not allow HTML-style ments within the code (a leftover feature from the early browser days).

• Modules must export anything that should be available to code outside of the module.

https://leanpub./understandinges6/read#leanpub-auto-modules

Modules, in general, solve several problems for developers. First, they allow the developer to separate code into smaller pieces, called modules. Second, they make it easy for developers to load (inject) those modules into other sections of code. Having modules injected like this helps keep project code uncoupled from the module (read: improved testability). And third, modules can load scripts asynchronously. This means that apps can begin loading faster, as they don’t require all scripts to be loaded prior to executing code.

http://chimera.labs.oreilly./books/1234000001623/ch03.html#_default_values

On the other hand because node.js is based on require which is synchronous this means node.js does not provide an asynchronous variant out of the box.

Of course there are async module loaders for node (async-require), but natively (with require) is not supported.

ESM is intentionally async (to acodate loading over networks) and the rationale behind import also aims at knowing during code interpretation what dependencies exist (e.g. allowing bundlers to do treeshaking etc). This is also the reason to have imports at the beginning of your files and they can't be conditional (unless you use the await import() syntax).

You can also not eval(readFileSync(moduleFile)) if you use ESM syntax in the loaded file.