Your expectations from a non-render blocking module proposal

I have been working on this concept for a large(ish) project I am maintaining. Decided to write a small tutorial app this afternoon for it with no libraries:

medium.com/@ibowankenobi/pausing-resuming-browser…

Here is the result:

ibrahimtanyalcin.com/taskq

It basically allows you express all logic with async scripts in microtask queues and pause/resume execution. If you see any other features/pitfalls that can be useful to add/fix please let me know so that I can add them to a TODO for upcoming versions. Many thanks!

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

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.

If it were truly "non-render blocking" there would be CONTENT semantically marked up for it to show BEFORE any of the scripting started. Without that you just have a staggered scripting load.

... and assuming that was used to deliver actual content, a WCAG violation.

Oh, and if your last "else" is a return false and all other conditions return, you don't need to else. :D

Also if you actually look at a page's load order, you don't NEED to play with that silly async property or any of the rest of the extras. Move the scripting to right before </body> so that the DOM exists and rendering already has started. Putting them into <head> is part of what makes them blocking, especially your first one.... REGARDLESS of what tricks you play inside the scripts themselves!

-- edit -- also this is 2018, you can stop saying type="text/javascript" and realistically if you need to set the charset of the scripting in the markup, there's something WRONG with your scripting or the server delivering it... and of course pixel metric font sizes are inaccessible crap... NOT that setting it on the HTML tag makes one lick of sense.

I understand:) Server side rendering is of course another option as always but that makes the DOMContentLoaded fire too late at some point. In this case you can for instance preload batches of images after a load event and append once it is fetched etc.

But thank you for your points, I am grateful

PS: putting them inside the head is much render blocking as any other DOM operation you can think of. But the script's iief does not execute the task, the task is pushed and then enclosed in a requestAnimationFrame + Promise much later with captured arguments --> that is the core concept.

Otherwise it is quiet difficult to do the same with 0 DOM operations, they are taxing yes we can't avoid that too much.

Thread

Your expectations from a non-render blocking module proposal

Responses(2)

Recent threads

Search Hashnode

Your expectations from a non-render blocking module proposal

Responses(2)

Recent threads