Asynchronous module.import(path)

There is a TC39 proposal about standardizing dynamic imports through a globally available import(path) callback, which will return a Promiseso that modules can be loaded, hence exported, asynchronously.

Already Impossible To Polyfill

The importstatement is reserved for ECMAScript 2015 modules, meaning we cannot create a function import(path) {/**/}and use it or the Syntax parser will complain.

On Web Workers side, we also have a synchronous importScript(...paths)feature on the global WebWorker scope.

As we can see, trying to avoid confusion and global scope pollution to finally have an asynchronous loader on the Web is already hard.

CommonJS To The Rescue

The “practical Web” already moved forward adopting the only de-facto standard when it comes to loading modules. The npm registry is where everything is, and bundler that resolve modules dependencies and injections are many.

I’ve written already in 2012 why AMD lost the battle, but yet in 2017 we are incapable of requiring, asynchronously and on demand, JavaScript modules on the Web.

The AMD module loader was born in a Promiseless era, where generators and asyncor awaitweren’t even spoken in the ECMAScript mailing list.

Today we have an official Promisebased proposal, a name everyone agreed on, and only one realistic way to bring it to the masses: enrich the CommonJS module with an import method.

The Best From All Worlds

Let’s start the journey assuring everyone everything as we know will work already. The module.import(path)is an opt-in operation, not something that requires changes at all. Following a basic example.

Modules are still cached once resolved, but always returned asPromise. This would grant consistency, whenever modules have been exported asynchronously or not, so that on the browser, and why not on the backend too, we could have asynchronous exports.

About Multiple Dependencies

We are in Promiseland, and we can Promise all. Both asynchronous import or exports can be easily performed as such:

Cool but … How Can I Do This Now !?!

On NodeJS side, all you need to do is to enrich only once per project entry point, the module prototype.

That’s it, you’ve implemented asynchronous module loader.

On the browser, you can use this simple and tiny common-js utility, and specify an entry point for your application.

If you’d like to quickly try it, you can use this script as src. Remember, you can even require modules synchronously, but synchronous and blocking network operations on the main thread are deprecated so stick with the asynchronous use until the day all you’ll have to do is to substitute module.import(...)with just import(...) .

As Summary

This proposal should be on track with what TC39 is discussing, it requires zero overhead and zero effort on NodeJS side, it unleashes new possibilities for both client and server module loading, and it’s the best moving forward, zero hassle, pragmatic approach I can think of, and read about, in years.

I hope you liked the idea, and I hope you’ll embrace the approach.

P.S. for those that don’t like typing too much …

Web, Mobile, IoT, and all JS things since 00's. Formerly JS engineer at @nokia, @facebook, @twitter.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store