View Full Version : Really simple question!

01-20-2009, 12:11 AM
Hi all,

When one function follows another, like:


Does someOtherFunction() wait to execute until someFunction() is finished, or does someOtherFunction() run as soon as someFunction() starts running?


01-20-2009, 12:47 AM
I'm pretty sure that it goes through the first function, stays in there until it's executed all the code in there, and then moves on. It can't move ahead just randomly.

Although the first function can call the second, so in that case it does jump, but it's still really in the first function.

Please correct me if I'm wrong anyone.

Hope that helps anyway,


01-20-2009, 01:20 AM
For example:

var funca = function(){
var funcb = function(){

With something like that, it would be called in order. The confirm, alert, and those functions are the kind I call 'delay' functions, they delay the whole page. The above code is just a longer way of saying:


Something like this wouldn't be a delay function:

var funca = function(){
var funcb = function(){

I guess that kinda answered your question.. I don't have a complete answer though. =/

01-20-2009, 02:31 AM
Hmm... So what about this:

var holdup = true;
var funca = function(){
var timeout = setTimeout(function(){
holdup = false;
// Let's pretend it took some code in funca 1 second to process.
var funcb = function(){

In this case, which alert would you see first?

edit: wait I'm retarded, I can test that myself. v_v

edit2: lol, that froze my browser.

01-20-2009, 02:37 AM


Will never stop... because true is always true. =/

01-20-2009, 03:11 AM
Even though there's the setTimeout that changes holdup to false after 1 second? The timer doesn't continue to count down during the while() stuff?

01-20-2009, 03:15 AM
From looking here (http://kevin.vanzonneveld.net/techblog/article/javascript_equivalent_for_phps_sleep/), I assume the while() function delays.

01-20-2009, 04:39 AM
Thanks for your info Nile.

01-20-2009, 04:48 AM
Glad to help. :)

01-20-2009, 02:02 PM
Javascript is single-threaded. That means that it's never really executing two things at the same time (which is why you don't have to worry about things like mutexes and semaphores in JS). When you setTimeout() a function, the runtime will wait until it isn't doing anything else before executing that function, even if that means that the function executes quite some time after it was scheduled to execute.

All functions 'delay', as jlizarraga put it. The only difference between an alert() and a document.write() is that document.write() simply writes the data and then returns, while alert() waits to return until the presented box has been closed. This is standard flow of control in all imperative programming languages, not specific to Javascript.

If you have some code:
01. function a() {
02. var i = 0;
04. while (++i)
05. if (b(i))
06. return;
07. }
09. function b(n) {
10. if (n > 2)
11. return true;
12. else
13. return false;
14. }
16. function c() {
17. alert("Foo!");
18. alert("Bar!");
19. document.write("Baz!");
20. }
22. setTimeout(c, 0);
23. a();First, a pass is made over the script, at which point the top-level functions are parsed and pre-compiled. Then, the interpreter will start again at the top and scan down until something is executed, namely line 22. The interpreter will make a note to execute c when it is free, then continue down onto line 23. Line 23 tells it to jump to line 01, to begin execution of the function a(). It then executes line 02, defining i, and then onto the while statement. The value of ++i will always be true, so this is a prima facie infinite loop. However, on line 05, it calls b(1), jumping to 09 and proceeding to 10 and then on to 12 since the condition is false, skipping 11 entirely. At 13 the function is instructed to return false, and does so; control jumps back to a() at line 04, where we now know that the value of b(1) is false, so the condition is not met and we go back to line 04. ++i is still truthy (now having a value of 2), so we go through the whole thing again until we end up back here. This time, though, when we go through the loop with a value of 3, b(i) returns true (10 -> 11 -> 05) and thus we return. After this, the runtime has nothing else to do, so it executes c(), whose delay expired the moment we set it (since it is zero). Control jumps to 16 and then continues to 17 to alert("Foo!"), and remains in the alert() function until the user closes the alert, at which point it moves on to 18. The same thing happens there, and then it executes 19, where it jumps into document.write() and stays there until the provided text has been written to the page, before continuing on to return from the function (all functions have an implicit return; [which is equivalent to return undefined;] at the end).

01-20-2009, 07:23 PM
Wow, thanks a ton!

01-21-2009, 02:08 AM
That was one of Twey's best in the "explain how something works" category. I would only want to add that javascript can be so quirky at times that it is best to also test out your code to see how it executes. And that almost if not always when it looks like the code flow isn't behaving as Twey has outlined, it is because of other issues.

Just as an example, I've recently been playing around with some code that seemed to be suffering from a lapse in the rules outlined, but only in Fx. As it involved jQuery effects (several .animate() calls strung together without queue), it was gong to be a nightmare to trace the execution order with any certainty. But it turned out to be something else, at least as far as the fix went. I'm still left wondering though, "Why only that browser?"

01-21-2009, 02:42 AM
What was the problem? I know you don't like to boast of your burgeoning expertise with jQuery in the forums, but perhaps someone could shed some light on why it only occurred in Fx. :)

01-21-2009, 05:59 AM
It all started out when someone wanted help using a mootools gallery with a prototype sidebar sliding menu. The history of this is rather convoluted, so I will skip a few steps. They found a mootools clone of the sidebar, but it was still incompatible due to different mootools versions.

We worked all of that out (there were even more issues). I was impressed with mootools in that it gave no errors, not even strict warnings, unlike prototype and jQuery, but at the same time wondered if I could port to jQuery which I like for other reasons. Somewhere along the way I decided to switch from id to class selectors and to make the whole thing OO. It has a lot of potential and is nowhere near a finished version from my perspective.

Enough back story (feel free to ask questions on that part though, as I've left a lot out). Here is a link to a good version:


which has a link on it to the bad (bad only in Fx) version.

You can just do a compare files on the two .js files -





to see the minor differences.

Hopefully the visual differences between the two demo pages (in Fx only) will show why I thought it might have to do with execution order, though hindsight is always 20/20, so my reasoning may not be as apparent as I might like it to be.

Bear in mind that GC, Safari, Opera, and IE all are fine with both versions.

01-21-2009, 06:12 AM
Hmm... they look exactly the same here (in Fx3.0.5).

01-21-2009, 06:26 AM
Did you click on the bars?

Anyways, assuming you did/do and they still perform the same, it may be partially the OS/computer, because I too am using 3.0.5.

Here's a screen shot of the bad version's menu in the act of deploying in Fx 3.0.5 on my machine:


01-21-2009, 06:42 AM
That sidebar thing is rad!

01-21-2009, 07:17 AM
Oh, I see... yes, that does occur. I suspect it's just a rendering glitch in Fx, though: I don't think it's anything to do with your code (I don't think it's possible to get an element to render like that if you tried).

01-21-2009, 10:01 AM
Well, I wasn't exactly worried about it. In part it is an artifact of porting from mootools to jQuery, as mootools' Morph constructor requires a from/to approach with effects, while jQuery's roughly equivalent .animate() method doesn't. However, I'm at a loss as to why going from 0 to 200 should be any different than going from 137 to 200. It seems to have to do with an absolutely positioned container's lower edge being exceeded by its content element, presumably right along that jagged line. But with overflow: hidden; on the container, it shouldn't. The fact that the contained element has itself a ul element may be contributory in some quirky way.