I may be missing something, but it seems like the purpose of this library is to solve the problem that if you run too much code in javascript in the browser at any given time you can hog the application thread long enough that it makes the user interface lag. So you can break up your operations into chunks that will be executed in order. This library will help you run functions in order and not all at once without having to use callbacks and setTimeout(function(){...}, 1).
One central reason why JavaScript can lag a page is that an infinite loop can occur in any function. Javascript is single-threaded, so this won't just slow down your computer; it can potentially crash your browser. Nothing else is allowed to happen until this function exits; if the function never exits, then the page is stopped and in some cases the whole browser process is stopped.
We could instead schedule these loops. That means that we'll check for browser events first before we go to the next thing in the loop. Here's some code which does this, implementing a simple for-loop structure:
function loop(start, end, fn) {
if (start < end) {
setTimeout(function () {
fn(start);
loop(start + 1, end, fn);
}, 0);
}
}
loop(0, 1000, function (i) {
// do some complicated calculation.
});
Is this what Pot.js does? Well, it implements a deferred "forEach" function, but if that's the goal, then that is not very clear -- especially because the main provided example (getting JSON) is already an asynchronous task in most implementations.
If that is the goal of Pot.js, then the library is an example of premature optimization and probably should not be used in new projects until it's determined that some loop is actually slowing down the page somehow. There are many reasons for this, but the simplest is that scheduling a function tends to kill a stack trace, and stack traces are more useful.
Unfortunately, the real use case probably isn't covered. The real case where I accidentally crash Firefox sometimes comes when I'm developing recursive functions. Consider this implementation of the Fibonacci numbers:
function fibs(n) {
return n <= 1 ? n : fibs(n) + fibs(n - 1);
}
Do you see the bug? It calls fibs(n) when it evaluates fibs(n), and goes into an infinite loop -- instead it should call fibs(n - 2). It's the sort of mistake that can crash Firefox if accidentally coded in Firebug.
Here is how the program would need to be structured if I wanted a magic protect() function to protect myself from Firebug crashes. Notice that everything needs to be made very ugly by wrapping it in callbacks:
var fibs = protect(function (n, callback) {
n <= 1 ? callback(n) : fibs(n - 1, function (u) {
fibs(n, function (v) {
callback(u + v);
});
});
});
Now, this function protect() can schedule the functions and while this will loop to infinity, it won't crash Firefox and I can copy important data to a text document before closing the tab.
Unfortunately, the above is so ugly that I will probably never be willing to write it again. So I also don't see the point here.
Just a small warning: don't click the menu items too quickly in chrome - it gets stuck in a loop scrolling back and forth.. Whether this is due to Pot.js or not I cannot tell without delving deeper!
