NIX/WIN/WEB » JavaScript

jQuery vs. Prototype – Part 2

grdinic — Sun, 23 Oct 2011 20:23:12 +0000

In the first post of this series we looked at the common misconception of jQuery being the “lightweight” JavaScript library. In this post we’ll leave the sidelines and jump right into some real-world scenarios. I want to see what makes jQuery tick by comparing it to my beloved Prototype.

A quick note as we get started: I’ve never coded in jQuery before, so my apologies ahead of time if I miss something obvious!

A Button Clicking Example

In this first example let’s see what a typical event handler for a button click looks like when following the design pattern of separating design from implementation:

Prototype:






Prototype

jQuery

$(document).ready(function() {

	syntax = 'verbose';

	if(syntax == 'quick'){
		$('.dynamic-element-wrapper > INPUT').click(buttonClicked);
	}

	if(syntax == 'verbose'){
		$('.dynamic-element-wrapper > INPUT').bind('click', buttonClicked);
	}

});

function buttonClicked(e){
	$('#console').html(e.target.id + ' Clicked');
};

Please note that as the HTML doesn’t change the jQuery code sample is limited to just the SCRIPT block.

So a couple items of note:

As a long-time Prototype guy jQuery’s automatic array return when using $() sits in stark contrast to Prototype’s use of $$(). I have to admit I’m torn on this one, as in a way the jQuery way makes more sense. The selector and knowledge of the document, combined with the function our event listeners call should be all that’s needed from a selector. In practical terms then differentiating between $() and $$() is admittedly more work without a huge gain in readability.

That aside, in Prototype we also get a bit more syntax heavy having to resort to .invoke() or .map(), whereas jQuery’s .click() makes short work of the job — providing a quick and concise way to perform such a common task is a huge win.

On the event processing side our buttonClicked() call is very similar. Once again jQuery’s love of shortcuts impresses me. .html() for getting and setting text is quite nice, and from what I can see, is duplicated via .val() of the form field side.

The this Reference Binding Issue

So here comes the main event. The example above in terms of design pattern is going to be just fine for most projects. Our design code is free from implementation code and when we click the element we get the info we need — everything just works.

But what happens when we follow a slightly more complex design pattern? Many times allowing UI implementation code to hover in the global script scope is perfectly acceptable. But their are times, either by virtue of space or code cleanliness, that wrapping our event code into objects is desirable or required.

An example of doing so in Prototype looks like this:

var buttonFactory = {

	_limit: 10,
	_secure: true,

	bindObjects: function(){
		$$('.dynamic-element-wrapper > INPUT').invoke('observe', 'click', this.buttonClicked);
	},

	buttonClicked: function(e){
		$('console').update(e.element().id + ' was clicked. ' + 'The limit value = ' + this._limit);
	}

};

// bind each button
document.observe('dom:loaded', function(){
	buttonFactory.bindObjects();

});

As you can see instead of binding our event listeners in the global scope we issue a simple call to buttonFactory.bindObjects(). If this was a much larger project it’s not hard to see why this would be a great way to work. Our document.observe code would simply be a series of calls to code that initialize other parts of the UI. The initialization code would then perform all sorts of long-winded tasks while leaving our document.observe call far from the down and dirty details.

But all’s not well. When coding this way — if not just to save space but to also create more complex event handling logic — we would expect that our buttonClicked() code would handle the reference to this._limit but it doesn’t. We’ll get this when we click a button:

button-2 Was Clicked. The limit value = undefined

That’s not at all what we want. You’d think this._limt should return with a value of 10 but it doesn’t. Why?

The problem is when we bound our event listener the this reference wasn’t part of the process. This means when we trigger a click event the this refers to the event object, not the buttons original parent object (buttonFactory).

Prototype has a solution for this via a call to bindAsEventListener(). bindAsEventListener() takes the object we wish to use as the this reference when invoked. To implement this fix in our example code we’d change our bindObjects() call to:

//
//
$$('.dynamic-element-wrapper > INPUT').invoke('observe', 'click', this.buttonClicked.bindAsEventListener(this));
//
//

Now when we run our code it returns the following when a button’s clicked:

button-1 was clicked. The limit value = 10

That’s more like it. Sure this is a synthetic example, but it’s absolutely essential to creating portable code.

Portable is the key word here, as yes, we could just do this to our buttonClicked() call:

//
//
$('console').update(e.element().id + ' was clicked. ' + 'The limit value = ' + buttonFactory._limit);
//
//

But this would be in bad form in my opinion, as now we’re making all sorts of assumptions of how this object will be consumed.

So the point is Prototype gives us a sleek, consistent way of holding objects together in event-driven code.

How does jQuery solve this issue?

jQuery

var buttonFactory = {

	_limit: 10,
	_secure: true,

	bindObjects: function(){
		$('.dynamic-element-wrapper > INPUT').bind('click', this, this.buttonClicked);
	},

	buttonClicked: function(e){
		$('#console').html(e.target.id + ' Clicked' + 'The limit value = ' + e.data._limit);
	}

};

$(document).ready(function() {
	buttonFactory.bindObjects();
});

The method signature of .bind() as we’re using it is:

.bind( eventType [, eventData], handler(eventObject) )

Thus, my solution is to simply pass our object reference as the eventData argument. We then pick up on the value via the event.data object in buttonClicked() and away we go.

Seems simple enough but again I do not have…well…any jQuery experience, so I would not be surprised is this is wrong in terms of implementation. What I can say though is it works just fine, and once again the syntax is pretty slick. For Prototype adding bindAsEventListener() is every bit as cumbersome as document.getElementById() if you catch my drift…

I say it works fine as for my part I did issue a test call of:

e.data._limit = 20;

under the #console update call and sure enough, the buttonFactory object was updated accordingly. From this we can tell this is passed as a reference, which means for my money this is an acceptable, working solution.

For the sake of completeness it appears we can also use .proxy().

When used our code changes to:

var buttonFactory = {

	_limit: 10,
	_secure: true,

	bindObjects: function(){
		var bProxy = $.proxy(this.buttonClicked, this);
		$('.dynamic-element-wrapper > INPUT').bind('click', bProxy);

	},

	buttonClicked: function(e){
		$('#console').html(e.target.id + ' Clicked' + 'The limit value = ' + this._limit);
		e.data._limit = 20;
	}

};

$(document).ready(function() {
	buttonFactory.bindObjects();
});

I’m not entirely sold on this method as now we’re once again in the mode of hand-wrangling specific behavior from our objects. It’s nice to know it can be done, however.

Conclusion

The title of this post has a vs. in it so who wins this round? Somewhat unsurprisingly I think it’s a draw, though if I had to pick I’d say jQuery. jQuery’s ability to pass this as an event parameter and it still works is fine by me and easier to code, and considering we can just as easily wrap this into a larger structure is better still.

Of course I’m ready and willing to have any and all ignorance corrected, so if you’ve seen something that’s not right with my solution(s) please let me know!

The bottom line is jQuery has some real time savers in its bucket of tricks; the fact that $() returns arrays is worth the price of admission alone.

Color me continually intrigued.

jQuery vs. Prototype – Part 1

grdinic — Sat, 22 Oct 2011 18:50:27 +0000

One of the hottest JavaScript libraries on the planet is jQuery. It’s opened up a world of web developers to functionality and ease they would not otherwise know, and has done so without stepping on anyone toes. Their are hundreds of great extensions for it made by a first-rate community that’s almost always helpful and supportive. When it comes to getting a job I’d say jQuery knowledge is almost becoming requirement, if not right away then as part of your integration into that job.

Prototype JS is…well…it’s another JavaScript library. But it’s the library I know and love. It’s what drives FormBoss and while not as exciting or popular as jQuery, I swear its day will come (again). Their are many reasons for this belief, but the first is due to what I believe is a fundamental misconception about jQuery vs. other libraries — its payload size.

In this first of a multi-part series we’ll take a look at the physical delivery size of each library. In the next post well dive into practical programming. First though, a bit of background.

Background

As a professional Web Developer I had a decision to make in mid-2008 as to what JavaScript library I would use for FormBoss. At that time I was looking for a library that fixed JavaScript’s core issues and had good AJAX support. (Little did I know that while AJAX support was important, far more relevant would be DOM handling and event binding, but more on that latter).

I checked a few libraries starting with Yahoo’s YUI and Dojo. Forget it. Far more complex than I needed, they seemed to make even simple tasks difficult (disclaimer: I haven’t looked into these libraries for some time now, they may be better, or perhaps my initial impressions were wrong!).

What I really wanted was a library like PHP. Provide a solid foundation that was not unto itself a framework. All I wanted was something that extends and smooths over vanilla JavaScript but also provides glue functions for doing more advanced stuff.

It wasn’t long before I narrowed my decision down to Prototype and jQuery (at versions 1.6.0.3 and at 1.2.6., respectively). Both seemed strong – jQuery on the count of its small size and simplicity, Prototype because of its more robust feature-set and AJAX support (again though DOM traversal and event binding played no part in this process, but would become crucial later on).

In the end I went with Prototype for a simple reason — it seemed more “complete” in terms of a programming construct. jQuery, always bragging about how small it was seemed almost too small, too limiting. I wasn’t looking for flash but utility, and Prototype fit the mold. For the most part I haven’t regretted this decision one bit–in the intervening years Prototype has been wonderful to me and always delights. In places where it needed improvement like upgrading to the Selectors API it’s done so in a reasonable time-frame, and for just about everything else, such as animation and event binding, it’s never let me down.

But always in the back of my mind has been jQuery, a nagging sense that I’m missing something. Why has it gotten so popular and does this mean I should be using it too?

Modern jQuery – The Popular Place To be

The base answer to our question of why so popular can be found right at the top of the jQuery home page:

Compare that with Prototype:

Ugh. It’s no wonder jQuery has more hype — seriously — by download link alone jQuery simply looks cooler and more advanced.

But it’s not just that…well not entirely : )

When you look at the jQuery download options you see that magic value: 31KB.

How brilliant can they be? Think about all of those large newspaper, e-commerce, and other highly trafficked sites. Bandwidth is money, and when it comes time to tell your boss you need to add more weight to a site it had better be as little as possible and worth it. More importantly, even as recently as 2009 broadband adoption in America was still only 67%. Sure that number continuies to rise but now consider our rising mobile Internet use. Truly two steps forward and one step back.

The point is size still matters, and Prototype’s stubborn lack of a minified version and frankly boring site and download page mean of course jQuery’s flashy site will draw more users in, both from a aesthetic and practical standpoint.

In Reality…

But of course we’re developers so we go deeper than that, and in preparation for this post I was–admittedly–floored by a simple test:

Had you asked me just five minutes ago I would have said “Of course jQuery is smaller, everyone knows that!”.

As of 1.6.4 jQuery has actually grown larger than Prototype in terms of raw source , 6084 lines vs. 9048 (and almost twice as large in terms of raw source code size in KB). More importantly though is while the minified version of Prototype is still larger, the minified + gzipped versions are identical. More importantly still: the minified jQuery is not 32KB but ~90KB. This is important because the jQuery website makes you feel like you’ll be getting all of that functionality for 32kb, but only if your server is gzipping content. The simple fact is almost all shared hosting plans won’t be doing do, which means your 32KB is actually closer to 90KB. And no, it’s not just the smaller plans, it happens with the big boys as well:

http://shop.nordstrom.com/

Run a Firebug NET session on that site and you’ll see what we’re about to cover below. They use a minified but not gzipped version of jQuery (version 1.5.1), which means payload size is 51KB.

In that light it’s instructive to see what happens with no server size gzipping with the latest versions of each library:

Prototype.js

jQuery

Here we can can very little server time spent on the requests, but with jQuery’s minified version definitely being smaller. Again though, the 32KB shown on the jQuery website, while true as it clearly states “Gzipped”, is not what we get without the server actually gzipping, as we would expect.

However, as soon as we enabling server size gzipping [via Apache’s mod_deflate using:

LoadModule deflate_module modules/mod_deflate.so

we get:

Prototype

jQuery

The minified version of Prototype is made via this minifier, and as we can see is essentially the same size as jQuery.

However, note that the non-minified version of Prototype is only ~5KB larger, and just as importantly, only take ~3 ms of extra server processing time (remember that gzipping in Apache is not free!). In other words we’re about even in that we do not need to create a minified version of Prototype and we’ll still deliver, in terms of processor load and payload size, the same thing.

In Conclusion

In this first post we’ve found that when properly delivered both libraries are essentially the same size. I would actually give Prototype the win however, as its smaller uncompressed size means we can simply plop the uncompressed version in to our delivery or ‘live’ section, and then in testing, instead of nonsensical minified error messages get actual line numbers we can refer back to. True this shouldn’t happen often, (it should be our code with the error, not Prototype or jQuery), but still handy in the larger scheme.

In non-gzipped environments however it’s clear that jQuery gets the win. This will be important for shared hosting plans of anywhere else we do not have access to server-side gzipping.

It’s also noteworthy that in order for Prototype to gain some of the more advanced animation framework goodness that (I assume) jQuery already has in the base library, we’d need to add Script.aculo.us, which would of course make the total payload larger.

Those considerations aside, what’s fascinating to me is that the perception of jQuery being “the” light-weight library. In the past 3 years I firmly believe this has been the primary driving force behind its mass adoption and popularity. I don’t know about you but I’ve been specifically told by bosses to not include Prototype because of its size — but at the same time given the go-ahead for jQuery. I’ve also made similar decisions for FormBoss based on the same reasoning (though not to instead use jQuery, just vanilla JavaScript).

Now that this is no longer true for the right environments (and truth be told, this has always been the case in the right environments), I think the time’s right for Prototype to take back some of the users it rightly deserves.

The irony of course is back in 2008 jQuery 1.4.2 was in fact smaller: 3549 lines of code vs. Prototype 1.6.0.1′s 4321. But success comes with a price, and jQuery’s potential bloat can only be a good thing for users looking to ‘trim’. How wonderful : )

Please understand though: I have nothing against jQuery, I simply feel that Prototype deserves more recognition and is in many ways the superior library for some specific types of work.

This will only happen though, and I cannot be more serious, if the Prototype folks get off their collective butts and do the same thing as jQuery – advertise, as prominently as you can, the fact that when minified and gzipped your library is the same size.

Links

http://thinkrelevance.com/blog/2009/01/12/why-i-still-prefer-prototype-to-jquery.html

Benchmarks: JavaScript vs. PHP vs. HPHP vs C++

grdinic — Wed, 06 Jul 2011 20:04:01 +0000

Just a quick spattering of some benchmarks I ran while testing a program I’m developing internally.

The first three are of the fannkuch benchmark found on the sunspider test site, only ported over to C++ and PHP in addition to the JS version. The browser used for all tests was Firefox 5.

The HPHP listing is a compiled Hip Hop PHP version, which is interesting as it shows the relative difference between it and vanilla PHP.

The last item, Benchmark.php, is the same benchmark file you’ll find in a PHP source download.

See the full benchmarks after the jump!

access-fannkuch – n=9

JavaScript: 0.204

PHP: 1.624

HPHP: 0.538

C++ .20

access-fannkuch – n=10

JavaScript: 3.062

PHP: 19.058

HPHP: 6.395

C++ .189

access-fannkuch – n=11

JavaScript: 40.297

PHP: ~4 minutes

HPHP: 23.713

C++ 2.265

Benchmark.php

PHP: 2.542

HPHP: 0.547

Testing JavaScript In Modern Browsers

grdinic — Sat, 04 Jun 2011 17:33:00 +0000

I recently installed Internet Explorer 9, and while the browsers interface seems nice, the JavaScript performance in terms of running FormBoss leaves something to be desired: In short, it’s completely unusable.

This was not at all the case in IE 8, and when you consider IE 9 was supposed to be the release that finally fixed JavaScript this is quite disheartening.

As any serious JavaScript programmer can attest to, the irony of IE has always been that in many ways its been more ‘correct’ in terms of standards than the other browsers. That is, what passes in Firefox in terms of JavaScript code fails in IE not because IE is wrong, but because Firefox is so forgiving (and by extension, wrong). This is doubly true when we add a JavaScript library like Prototype JS into the mix, in that the libraries attempts to smooth over browser differences may expose us to subtitle differences in core JavaScript behavior.

On that springs to mind is how some Prototype JS objects property counts are handled. In Firefox an object may be shown to have a length of 1, but in IE that same object had a length of 2. Another example, if memory serves, had to do with valid names of objects. IE has always been more strict in terms of using names that start with numbers, and so on.

Such differences can be hard to spot in production code, and almost always leads to hours of careful testing and debugging.

Thus, as part of my own production process I’d like to share two links that may help you determine if such issues reside in your code or the browser/library begin used.

Google Labs Sputnik JavaScript Test

http://sputnik.googlelabs.com/

This test is very interesting to me as it confirms, among other things, that IE 9′s JavaScript engine is generally more ‘correct’ in terms of standards that the competition. For example, when run in IE 9 I get 71 failed tests, whereas Chrome Canari generates 136 and Firefox 4 181.

In almost all of the cases that ‘fail’ we see the failed test is something the casual JavaScript author may easily do.

For example, in test s12.5_A9_T1 we check for a function declaration within an ‘if’ statement:

// Copyright 2009 the Sputnik authors.  All rights reserved.
// This code is governed by the BSD license found in the LICENSE file.

/**
* @name: S12.5_A9_T1;
* @section: 12.5;
* @assertion: Function declaration within an "if" statement is not allowed;
* @description: Declaring function within an "if" statement;
* @negative;
*/

if (true) {
    function __func(){};
} else {
    function __func(){};
}

testCompleted();

Have I ever done this? No. Could I see others or even me late at night? Sure. The point being that as you peruse some of the test that say, Firefox 4 fails, it becomes obvious that many of the failures stem from Firefox being ‘fast and easy’ with some of the rules, which ironically, can make creating JavaScript code easier.

Framework Library Test

http://dante.dojotoolkit.org/taskspeed/

This test highlights the differences in the major JavaScript libraries. Of core importance to me are the functions that manipulate the DOM, such as append, insertbefore, insertafter, and so on.

Sunspider Benchmark in C++

grdinic — Sat, 23 Apr 2011 20:27:54 +0000

The Sunspider JavaScript Benchmark is a popular test of Web Browser performance.

As great as the newest browsers are I though it would be interesting to take a random test and port it to C++ for the sake of comparison.

I decided the rather short fannkuch test was a good candidate. The results:

Not surprisingly the C++ version is 18x faster than Firefox and 8x faster than Chrome. For the curious, the ported C++ code is after the jump.

I should mention one thing changed from the stock Sunspider site (e.g., the link above), is the number of iterations was upped from 8 to 10. At 8 iterations the C++ version was sub-millisecond, meaning I’d have had to roll a custom assembly timer to get a benchmark value. That said, when we lower the iterations down to 9, the stack heavy algorithm starts to benefit the browsers more, with Chrome coming in only 3 times slower and Firefox 11.

Lower the iteration count to the “stock” 8 and Firefox actually catches up to Chrome, with both browsers reporting ~21ms. Interesting.

The C++ Code

int MainWindow::Fannkuch(int n)
{

    int check = 0;
    int perm[n];
    int perm1[n];
    int count[n];
    int maxPerm[n];
    int maxFlipsCount = 0;
    int m = n - 1;

    for (int i = 0; i < n; i++){
        perm1[i] = i;
    }

    int r = n;

    while (true) {

        // write-out the first 30 permutations
        if (check < 30){
            int s = 0;
            for(int i=0; i> 1;
                for (int i = 0; i < k2; i++) {
                    int temp = perm[i]; perm[i] = perm[k - i]; perm[k - i] = temp;
                }
                flipsCount++;
            }

            if (flipsCount > maxFlipsCount) {
                maxFlipsCount = flipsCount;
                for (int i = 0; i < n; i++) maxPerm[i] = perm1[i];
            }
        }

        while (true) {
            if (r == n) return maxFlipsCount;

            int perm0 = perm1[0];
            int i = 0;

            while (i < r) {
                int j = i + 1;
                perm1[i] = perm1[j];
                i = j;
            }

            perm1[r] = perm0;
            count[r] = count[r] - 1;

            if (count[r] > 0) break;
            r++;
        }
    }

}

Five Times 2 – HTML 5 For Safari 5

grdinic — Fri, 11 Jun 2010 02:21:20 +0000

Apple released Safari 5 on June 9th, the fastest and most advanced browser from Apple yet. It’s loaded with new features and enhancements, and from a cursory look, this is an intriguing release indeed.

Thing is though, if your a non-techie all this talk of HTML 5 probably makes you say “Wah?” — While those of us in the development community are left wondering when we’ll get to implement this cool stuff as the giant elephant in the room sits docilely in the corner.

It’s a confusing release really, filled with more promise and hope than tangible benefit–or is it?

As a guy who runs a web software company I thought I’d share my quick thoughts on Safari 5 and provide some links to learn more.

HTML 5

HTML5 AJAX History

This is an interesting one in that it’s a feature in need of a web infrastructure to support it–or at least if I understand the feature correctly. I assume this is a system for storing application state, but I haven’t had much luck finding out for sure. Regardless, it’s interesting to me as someone who wrote a full AJAX based web site that utilizes AJAX history state saving. It was done using a script called Real Simple History, and was as you would expect, a direct answer to the annoyances of losing your save state if the user hit the back, reload, or forward button. It works well enough, but just as with HTML Draggables, would be nice to have built in.

HTML5 forms validation

Sorry, not too informative, but I did find this link which describes more on this topic.

WebSocket

I like to think of this as a extension of the HTTP Request object introduced in IE 5 way back in ’99. The basic idea is that we can open a direct link to a server on what’s called a Full Duplex channel (e.g. your telephone), which allows simultaneous two-way communication.

http://code.google.com/p/phpwebsocket/

What is this good for? Chat logs I suppose, but it may lead to more advanced types of form validation…

Web workers

I’ve actually covered these guys in another post on this blog, but the basic idea is that web can run concurrent JavaScript code to speed up execution. Now Safari 4 already supported Web Workers, though with a reduced feature-set as compared to FireFox. So the real question is, have they been enhanced in any appreciable way? I’ll have to test the feature set in a future post, but for now, here’s a quick look at performance between FireFox 3.6.3 and Safari 5:

Firefox 3.6.3:

Fibonacci Set 1 Time Taken: 1.16

Safari 5 (initial release)

Fibonacci Set 1 Time Taken: 0.2

Of course this is the horrible inefficient stack smashing way, the optimised iterative version favors FireFox slightly:

Firefox 3.6.3:

Fibonacci Set 1 Time Taken: 1.08

Safari 5:

Fibonacci Set 1 Time Taken: 1.52

HTML5 draggable attribute

This is an interesting one, if for no other reason than here we have another Microsoft originated API from IE 5!

http://html5doctor.com/native-drag-and-drop/

As far as it’s integration into web applications–I think the greatest benefit of a native API to handle drag and drop will be from a performance perspective. Right now in FormBoss, for example, dragging multiple items isn’t as precise as I would like it to be. This is not necessarily a performance problem, but a native method should mean we can sample more efficiently during the drag operation, which should help smooth things out and improve precision.

Their is more to it of course, to which I simply defer to: http://html5doctor.com

Developer Tools and Closing Comments

The last thing I want to look at is the all-important subject of Safari 5 as a developer friendly release.

FireBug simply rules them all–this has been, and most likely will continue to be, the clarion call for all serious web developers. Yet in the recent years it seems as if inline JavaScript debugging is becoming the norm, not the exception. IE8 has a debugger, Chrome, and of course Safari.

Problem is, they’ve always fallen well short of Firebug for one simple reason: FireBug is about more than just debugging, it’s about the DOM too. Without a good way of viewing the DOM a debugger is nearly useless for complex work. To be clear, by DOM I mean the entire DOM starting from the window element, not just the visible page bits from the HTML element on down. FormBoss, like most web applications, makes extensive use of the root DOM object to store objects and arrays.

The strange thing is Safari will gladly show you the window element if you open the Console and type:

eval (window)

…but not from the comfort of the main debugger, or even from a separate DOM tab.

Unfortunately, while the developer tools in Safari 5 seem very slick, they do not address the DOM viewing issue, and they also seem to be a touch unstable. While viewing the property of a paused debugging session the entire browser crashed. I’ve had FireFox get twitchy, but not outright crash.

That said, the tools are slick, as I said. Syntax coloring is very nice to see, as is the clean and intuitive user interface. Now if they could only add a proper DOM inspector!

Multi-Threaded JavaScript — A Quick Look.

grdinic — Thu, 20 May 2010 00:31:18 +0000

The strange thing about this post is that this isn’t exactly news–ever since FireFox 3.5 came out in June of ’09, and along with Safari 4 and Google Chrome using a slightly different mechanism, these browsers all support OS Level multi-threading.

The question is, should you care?

The short answer for right now is absolutely, just don’t expect to place any of your multi-threaded code into a live environment any time soon. Until Internet Explorer decides to implement this API we’re left with a world where more than half your users won’t see your threaded code anyway.

Of course this is a pity, as it’s not hard to imagine the many uses spawning worker threads would have. As I type this I’m looking at one right now…the TinyMCE text editor. Sure it’s fine for most web editing tasks, but in FormBoss there are several instances of hooks I need to write into the processing engine to update various data structures, and sometimes these really take a hit with larger data sets. Of course loading times are also quite slow, even on relatively fast machines like I’m using now.

Opining aside, the purpose of this post is to learn a bit more about these guys, how they are used, and what type of performance boost you can expect.

General use

I’m going to stick with the kind of threads that FireFox and Safari use.

The basic work flow is you write a calling script like this (index.html):

var iteration = 30;
var worker1 = new Worker('fibonacci.js');
worker1.onmessage = function(event){
if(event.data == 'Done!'){
StopTimer('fib1timer');
}
document.getElementById('fib1').innerHTML += event.data + '\>';
};
worker1.onerror – function(error){
dump("Erorr with thread:" + error.message);
throw error;
};
// call worker 1
worker1.postMessage(iteration);

…whose job it is to create a worker (the second line), listen for messages from the worker, listen for errors from the worker, and finally, start the worker with some task (the last line).

The interesting thing to me about this code is how in the first line we initialize a Worker by passing in an argument of a JavaScript file. This is not a mistake, it’s how these guys are created. We do not pass functions, we pass files. I’ve heard grumbling about this, but I personally think it’s rather appropriate, at least for now.

Before we take a look at that file argument code though, note the event handlers (onmessage, onerror). These are required, and the names cannot be changed as they are built in functions that need an implementation from your application.

Right, on to the fibonacci.js fie:

// main fibonaccci cycle — careful with anything over 30!
function fib(n) {
var s = 0;
if(n == 0) {
return(s);
}
if(n == 1) {
s += 1;
return(s);
} else {
return(fib(n – 1) + fib(n – 2));
}
}
// worker thread 'gateway' function.
onmessage = function(event) {
var n = parseInt(event.data);
var i;
for(i = 0; i <= n; i++) {
postMessage(fib(i));
// wasteful, but shows how the messaging system can be called
if(i == n){
postMessage('Done!');
}
}
}

So the basic idea is we define an onmessage event listener to wait for our initial call. Think of this as the ‘gateway’ into the threaded function. Once this message is received by fibonacci.js, we grab parameters from the event.data argument and kick off our first iteration of the fibo cycle by issuing a call to postMessage(fib(i)).

As we are passing a function as an argument, and because that function returns a value, the postMessage(fib(i)) call will receive a Fibonacci value back. If we look at the first code block again (index.html), you’ll notice we defined a event handler for these postMessage() events, the function onmessage().

So just to be clear: in index.html we start our thread by calling:

worker1.postMessage(iteration);

This call is received by the event handler in fibonacci.js via onmessage(). Then, when we want to talk back to index.html from fibonacci.js, we do so once again via postMessage(). This call is then also handled by an event handler called onmessage().

In other words, both scripts have a postMessage() call, and both have event handlers for this call, onmessage().

This is super important to understanding how Web Workers function with respect to their inherit limitations–the long and short of it is when we spin off one of these threads the code in the external .js file is for all intents and purposes disconnected from your main script. The code in the web worker cannot change the DOM, and can only pass values back to your main script via postMessage().

Thus, in the code above when the fib() function returns a value it does so as an argument to the postMessage() function call, this value is then received by the “main” script (the top one, index.html), which updates the DOM via:

document.getElementById('fib1').innerHTML += event.data + '';

So yes we can update the DOM with results and data from our threaded functions, but not from within the Web Worker, only from the messages we send back to the calling script.

This actually brings up two important points:

Safari only supports a simplified version of the messaging system. Whereas FireFox supports full on JSON, Safari only support simple values.
Communication has a cost…

Communication has a cost

Yes it does. One of the main hassles of threaded programming is dealing with the headaches of race conditions, deadlocks, and other data dependencies. Web Workers hide much of this from us, making it quite hard to create such problems at the cost of some flexibility.

That said, to help illustrate how web workers can be used, I’ll created three different test cases ( **see download link below).

single-thread

worker-threads

worker-threads-optimized

single-thread , as the name suggests, simply takes our fib() function and calls it twice on page load, both with 30 iterations. Some defining characteristics of this approach is we loop around 14,098,246 times, and our web page is effectively ‘blocked’ during this time, causing the DOM to freeze until the operation finishes.

worker-threads is basically the same code as above, but now we define two Web Workers, both of which call the same fibonacci.js file. We then loop through the same code as we do in single-thread, but because each call is using its own thread, the operation finishes roughly twice as fast (provided you have a two-core machine!).

Some characteristics of this approach are quite pleasing indeed. Yes the operation finished twice as fast, but this is kind of a generic case anyway. For me, the real benefit is a) our timer call actually runs independently of the main operation and provides an accurate result. b) the DOM is no longer blocked, in fact it’s updated dynamically, which is a pretty neat effect.

Finally, we have worker-threads-optimized. In this case we give up the embarrassingly inefficient recursion-from-hell fib() function and use a far more efficient iterative version:

function fib(length) {
for( l = [0,1], i = 2, x = 0; i < length; i++ ){
l.push(l[x++] + l[x]);
//postMessage(l[x]);
}
return l;
}

When I first ran this code I was surprised to see just how much faster it was. With the old function anything over 35 was trouble. With this version we can easily pass 10,000,000.

But there in was a problem: During testing I would set the sequence number to around 300,000 for each of my two threads and wait as I monitored CPU load. Problem was, my CPU load never went over 25% on a four-core machine–I was running single threaded again. But how? Did I run into some limitation of what files could be run, what variables could be used, or what functions called?

I won’t lie: I pondered over for quite a while before it finally dawned on me: the worker-threads version, while computationally expensive, was doing almost nothing to tax the DOM. At 30 iterations each the DOM would receive a request to update every 150 milliseconds or so, leaving plenty of time for the Web Workers and browser to grind away. In other words, we could run at the full potential of the threaded code because the DOM update calls we infrequent enough to not matter.

But not so with the new version. The new version was absolutely pounding the DOM with hundreds of thousands of requests every second. Their was no way it was going to keep up, and so in the end the browser itself started blocking the postMessage() function calls.

That’s why that postMessage() call above is commented out. So long as we’re not trying to call that we use both cores as expected. Lesson learned: If you truly want parallelism you’ll need to forgo DOM communication if the number of calls becomes too great relative to the time between each each DOM update.

In the end, the gateway function ended up being:

// worker thread 'gateway' function.
onmessage = function(event) {
postMessage('start!');
fib(parseInt(event.data));
postMessage('Done!');
};

When we first enter the function we pass a simple start message, and when done, pass a message that we’re done.

In Conclusion

What a wonderful world it could be if we had better standards in the world of web browsers. Alas, for the foreseeable future Web Workers shall remain an enigma to most, which is a shame. Used right they can provide a significantly improved user experience, as well as open the doors to a more dynamic and interesting web. Let the wait begin!

Download the scripts discussed in this post!

worker-thread-benchmarks