Comment by Matt Strom on "Your expectations from a non-render blocking module proposal"

I'm not sure that I see the gap that this is filling. Couldn't the same behavior by achieved with generator functions and dynamic imports?

If fallback for older browsers is what you're going for, then I'll give your that. But I can't imagine that the polyfills for generators and dynamic imports are larger than your library.

let stopped = false;
let generator;

function timer(duration) {
 return new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve();
    }, duration);
  });
}

function stop() {
  stopped = true;
}

function resume() {
  stopped = false;
  generator.next();
}

function restart() {
  stopped = false;
  generator = tasks();
  generator.next();
}

async function* tasks() {
  await timer(3000);

  if (stopped) {
    yield;
  }

  await import('./first.js');

  if (stopped) {
    yield;
  }

  await import('./second.js');

  if (stopped) {
    yield;
  }

  // And so on...
}

generator = tasks();
generator.next();

These 50 lines become only 98 lines when transpiled with TypeScript, so TypeScript only adds another 50 lines to polyfill generators, async-await, and dynamic imports.

typescriptlang.org/play/index.html

Thank you for your post Matt,

Taskq is 6kb. Couple of questions,

how will you deal with arguments order?
The solution you propose it single branch linear push, whereas in Taskq there are 2 threads. A main thread of initial pushed functions/async script tags, and a second thread that halts the first thread in case there are other nested dynamic imports that needs to be completed. How will you solve it?
how will you make sure the arguments are not in global namespace but private enclosed while scripts are separate.
how will you solve recursive dynamic imports/exports
how will you pass arguments from one script to another, just calling them does not solve the issue
you need to devise a push mechanism that makes a shallow copy of current tasks and sorts them, otherwise recursive calls will blow the stack
How will you deal with the dependencies of one script to another?
In Taskq, thennables can be controlled and paused using a single internal resolver via res.init, then res(true|false). It is reused, every single time. However to do that in native ES6, you will need to return another brand new Promise inside that then handler each time which I think is a big performance hit --> imagine doing that with the medium post example's draw function --> not that great.
And also in your solution entire scripts are called with import --> this is not complete non-render block proof , where as in my case it is guaranteed that every ~17ms there is one, and only one task is called which is further enclosed in a Promise, if possible.
How will variables exported with one script can be changed by another script within itself? (ex: the draw function has access to earlier parameters although it is in a different script, sure you can move the entire draw function inside the main index.js but that is antipattern, takes you back to square 1.)

Admittedly I haven't fleshed these answers any further than just writing them down here. I'm not positive they work.

RE: Arguments order — Please clarify.
RE: Single thread — Promise.all() would handle parallel "threads", no?
RE: Global scope — I've taken for granted that a module system is being used. Since each module forms a closure, there is no risk of polluting global scope.
RE: Recursive Imports — I'm not certain what you mean here. Do recursive imports differ somehow from resolving successive nodes of a dependency graph? Again the module system would handle resolving the dependency graph. And tasks would not be encapsulated as a script. It feels like you're trying to mimic the web workers API.
RE: Passing args between scripts — I suppose I would structure tasks as functions or a more complex class.
```
class Task {
constructor(context: TaskContext) {}
start(): TaskContext {
  return newContext;
}
}
```
RE: Push Mechanism — Again I think the module system would have dealt with this when resolving the dependency graph. Tasks are objects that can be instantiated multiple times.
RE: Dependencies — Again the module system takes care of these.
RE: Thenables — I think the generator functions take care of this.

Also, while it is most definitely heavier than your library, I usually use RxJS for advanced event stream handling. RxJS has constructs for pausing, resuming, and cancelling async logic. It offers a large selection of schedulers for delegating tasks onto other thread-like mechanisms in JavaScript.

reactivex.io/rxjs

Taskq does not rely on any module system, no bundling like rollup, webpack etc. And no require calls etc. That was the plan,

Arguments: you do a import on a script that has an iief and function enclosed in it:

!function(){
    function someF(a,b,c){
    }
}

with taskq i can pass those a,b,c.

Promise all resolves as soon as soon as all the promises in the array are resolved --> there is no concept of order there. And also this is a single dimensional array where in real life you have script1 --> script2 -->script3 while if script2 has internal imports real time in browser!, script3 should wait. If you do plain await that won't work because if one of the dynamic scripts within script 3 etc. keeps importing itself, you will get stuck. You need a system to throttle those.
You have taken that granted in Taskq? yes it is handled like that. But in your case you are not holding pointers to exported variables anywhere, so the generator can't reach them.
Recursive imports are cases when a script within itself imports itself. If this happens you need to pause the main thread, allow the script to import itself while throttling this behaviour and allow it to reach exported variables meanwhile. Plain await resolves as fast as it can, you cannot throttle that without returning another Promise --> less economy of motion.
That is not very relevant, refer to point 1
I'm not using a module system. I do series of schwartzian transforms to sort dependencies of main thread. Then I can halt the main thread if some dynamic imports are seen.
Thennables do not take care of pausing resuming their own execution unless you return another Promise to resolve/reject where as in my case I can recycle an entire resolver through the whole main thread which I can think better memory vise. Imagine you have 600 dynamic scripts loads to run, you will return 600 Promises or a single object to recycle?

For RxJS I think it is an ammaaazing library! But it is an entire concept of wrapping everything up in their own terminology including ajax calls etc or even browser events so that they can provide control flow. It is an entirely separate layer. So for example someone could use that within tasks pushed to Taskq!! In taskq there are 4 things to learn: export, push, perform, load.

Where as in my case I wanted someone to have let's say 10 async script tags in his html, browser would fetch them asap, taskq would sort their dependencies, get their inner functions, pass the correct arguments and execute them while pausing if for instance within one script, I realize the client's browser is super old and I need to load one more script, then resume the rest of those initial async scripts etc.

This way I could have a modular system without touching a single piece of module bundlers + pollyfills starting from ie9+ with 6kB.

In general I find bundlers quite antipattern --> Some people loose their minds when they see 100 scripts, I loose my mind when I see a single 500kB bundle.js with tens of pollyfills which I haven't looked into them in detail.

For some projects I use a bundler for instance, but for larger projects I want to see BOTH on development side and client side what is going on at all times (I am willing to give away from loading time here). At some point I can always combine taskq and a bundler, taskq would deal with the bits I push to it and I could still have the rest of 'heavy cannons' in my app.

Now everyone is into concepts like bundling, treeshaking, static analysis etc and I think with wide use of HTTP2.0 this pattern 'might' revert as things that were bottlenecks won't be anymore.

And lastly, the idea of taskq stems from not just ordering asynchronous calls, but also use all the microtask queues available in the browser. So far we had 3, setTimeout/Interval (which for obvious reasons cannot use), requestAnimationFrame (to throttle), Promises (to offload even more). ~17ms throttling is a reasonable time frame for parts of an application that does not need to load asap. I used this sort of throttling for data visualization for years, which I spoke bit in detail in one my articles in ieee:

ieeexplore.ieee.org/document/8291800

I talked too much..It was great conversation Matt, thank you!

Nice work though! This type of library is not the easiest thing in the world to write.

Search Hashnode