Promise based module loading

[unit-404]

If requirejs used for Web, so I suggest to add new syntax, based on await/async. Also, I suggest make script loading and caching, based on FileSystem API and file system URL.

(async ()=>{
  let module = await require("module.js"); // just require module with await syntax
})();

Or

// here "async" wrapper omitted 
let modules = require(["a.js", "b.js", "c.js"]); // load tarball of modules
let a = await modules[0]; // await this module (for example, caching or loading from cache)

[ddziaduch]

Nice idea, but... Many browser supports now ES6 module by default https://caniuse.com/#feat=es6-module and that support will only increase :)

[chrisknoll]

Not to start a flame war here, but, that ES6 module support (via script type=module) is no where close to a fully formed module loading system. They still need to work out loading semantics and name resolution before any of this goes anywhere (basically all the framework stuff you get with a loader like RequireJS).

[ddziaduch]

@chrisknoll do you have any article where I can read about it? It sounds interesting

[chrisknoll]

There's a few resources on the web that will give you the history, but the main source of info comes out of the WhatWG working group that is developing the standard: https://github.com/whatwg/loader.

Here's a fun nugget from their main README:

Status

A good chunk of this spec is out of date and is undergoing revision to realign it with Service Worker, the JS Realms API, and the dynamic import() feature.

Yikes. They've only been working on it for about 8 years now, and the're back at the drawing board.

If you look at how the node community is handling it, they decided to implement an extension .mjs aka 'The Michael Jackson Script' to differentiate a CJS from an ES6 module. That's what it's come to...defining new MIME types.

So, it's a mess, and from the node community standpoint, they have so much use of their code system, they can basically call the shots which leaves the asynchronous folks who work exclusively out of the web to rely on transpilers and build chains. Of course any node developer will tell you that build chains is a fact of life, but whenever I observe a node dev doing server side programming, there's no build step there! only for the browser....hmm

Anyways, do a couple of searches, you'll find how far ES6 is from being a complete solution.

[AllNamesRTaken]

So, is there a techincal reason that we cannot return a Promise and just resolve as when we would call the callback? I must be missing something but it feels straight forward?

If we only need someone to do it then that should be easy enough but I guess there are other things blocking.

[ddziaduch]

@AllNamesRTaken it would require a Polyfil because older browsers does not support Promise

[kohlmannj]

For what it’s worth, you can wrap a call to RequireJS’s require() function in a new Promise like this:

async function main() {
  const [dep1, dep2, dep3] = await new Promise((resolve, reject) => {
    require(['dep1', 'dep2', 'dep3'], resolve, reject);
  });
}

main();

Compared to awaiting multiple dynamic import() calls, I found this to be close in terms of ergonomics. Also, it works!