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.

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.

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.

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.

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.

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