Show HN: Chunkify.js – A functional API to unblock your JavaScript thread | Hacker News Reader

Show HN: Chunkify.js – A functional API to unblock your JavaScript thread

yangmillstheory.github.io

You should have the "chunkify" checkbox on by default (or at least warning before people hit one of the Map/Reduce buttons).

People are likely getting their browser tab (perhaps their whole browser) frozen when they click those buttons and having to bail out on your page/submission.

Also, add some overview text instead of a blank page with a ball on it like:

https://github.com/yangmillstheory/chunkify

Thanks for the reply! I was just thinking I should have that on by default.

I'll add an explanation of what's happening.

I usually just do something like this:

    var loop = function() {
      for (var i=0; i<1000; i++) {
        // do stuff
      }
      setTimeout(loop, 0);
    }

It might not be as fast in some cases, but it works for me.

It works - and that's the core of what's being done if you look at the code. I just wanted to make something re-usable, configurable, and play around with ES6 generators :).

Do you think it would be possible to dynamically adjust the chunk size for optimum performance on different hardware/browsers? That would be very useful.

The API exposes the chunk/delay parameters as options, so it's definitely possible.

If you mean having the library code "learn" the optimal chunk/delay for a given run, that's possible too, but I'd have to wonder about alternative solutions at that point.

I you look at the demo site again, I made the chunk size and delay user-configurable, and I'm displaying the current running code.

Another alternative, quite viable today, Web Workers.

It's impossible to use web workers across domains or while using non aliased cdns. Which can start to feel really restrictive.

I got over that limitation by converting the code to a data URL, like this:

    var blob = new Blob([worker_code_string], {type: 'application/javascript'});
    var worker_uri = (window.URL || window.webkitURL).createObjectURL(blob);
    var worker = new Worker(worker_uri);

The path to the scripts imported with importScript() must be absolute, though. I add the path by modifying worker_code_string. Alternatively they can be fetched and prepended to the code string (or passed in the array of Blob()).

I was reading about that. It seems pretty strange that these heavy security restrictions on origin are in place but you can create a worker from a string.

in my project HashcashIO[1] i get around that using iframe and loading main script for same domain. while restrictions exist, i believe it is easier to get around them (basically write code in secure fashion) rather than trying to break work into junks in the main thread.

Although, depending on task i see cases where chunkify.js will be useful, since i myself used this idea, granted with adhoc implementation instead of using well defined library.

[1] https://hashcash.io/

One problem I found with web workers is that they do not respond to messages when inside a tight loop, which can be problematic in certain circumstances. I actually used a similar technique inside a web worker for that reason.

Reply on news.ycombinator.com