JavaScript Can Have An Interesting Interpretation of Order

There is an interesting little quirk with the way in which JavaScript decides which function it should execute next. You see, while the JavaScript engine has a single thread of execution, it creates the illusion of multiple simultaneous processes running at once by utilizing a queue of functions to execute. This means that every time you make a call to a function in your JavaScript, there is no absolute guarantee that it will be the next piece of code run, as there may have been other events triggered that beat your custom function onto the execution queue.

You may be thinking that this is interesting and all, but what does it matter to me? Well, lets take the following snippet of code as an example.

var func1 = function() {
    func2();
    $(form).submit();
},
func2 = function() {
    var iframe = $('<iframe src="blank.html" class="hidden" id="testiframe"></iframe>');
    $("div:last").after(iframe);
    $("#testiframe").on("load", onIframeLoad);
};

So, based upon looking at the code above that utilizes some jQuery to make things a bit more straightforward, does the function onIframeLoad get run first or does the form get submitted to the server first? Does the function onIframeLoad ever get called?

As is the case with many things in the world of JavaScript and Web Development, the answer is that it depends. Lets address the second question first. We cannot be absolutely certain that onIframeLoad will ever be called because we are not certain that the blank.html file will load after we are able to attache the event handler to the newly created iframe. It is possible that there is so much else going on with the JavaScript on the page that blank.html will load before we setup the event handler. However unlikely, this is a definite possibility.

As for the first question, it again comes down to a question of timing. Without more knowledge about what exactly is going on with all the other JavaScript on the page and what ever plugins are running in the browser. In general, I would expect onIframeLoad to be executed first, but I would not want to base the functioning of my website on that expectation. If you wanted to guarantee that onIframeLoad is run and is run before the form is submitted, I would change the above code to something similar to the snippet below, which forces the order to be respected instead of guessing at the order.

var func1 = function() {
    func2();
},
func2 = function() {
    $("document.body").on("load", "#testiframe", onIframeLoad);
    var iframe = $('<iframe src="blank.html" class="hidden" id="testiframe"></iframe>');
    $("div:last").after(iframe);
},
onIframeLoad = function() {
    $(form).submit();
};

Related Posts

Jul 16, 2014
2 minutes

Write Software for People, Not Computers

Throughout a normal day, I end up reading a lot of information about current issues in technology, and today is no different. There was a debate raging about whether or not high-level math was required for programmers that was sparked by this article by Sarah Mei Programming is not math. While it is an interesting topic, and, surprisingly, I mostly agree with Sarah on this issue, that is not the most important portion of her post. The important part is instead a quote from Structure and Interpretation of Computer Programs from MIT Press, and is as follows:

Mar 31, 2014
2 minutes

JavaScript Templating

Many times it becomes useful to be able to make an AJAX request for some data, insert it into some HTML that is already on the client, and then display it to the user. There are a few ways to implement this, each approach has its benefits and drawbacks.

String Concatenation

Possibly the simplest way to accomplish the templating in JavaScript is to use simple string concatenation with ‘+’. This is the approach that I see many newcomers to JavaScript use in their code, as it is the simplest to implement. However, it does have a major drawback in that this method has the worst performance of all, especially in older versions of Internet Explorer. This could be implemented as below:

Jun 2, 2014
2 minutes

Defensive Development - Fail Fast or Go Home

Defensive Development is a programming practice that is frequently misunderstood, but is nevertheless a critical practice to follow when working in many environments. I have seen articles written that argue that defensive development simply causes nonsensical null checks to be written, and as a result of seeing people writing bad code defensively, argues that no one should practice defensive development. There are other articles that, like many things in software development, argue that you should always use defensive development for everything.