Category Archives: dojo

Multithreaded elements of style in javascript

This other day I was just coding and stuff when it suddenly struck me – multithreaded programming! My general ideas about it always revolved around things like scalability, synchronization, and those philosophers who refuse to eat with their hands. What I completely missed was the human side of it – the way it helps developers express their thoughts in code with so much ease and elegance even when they’re not pursuing head-spinning performance. In fact, lots of multithreaded code out there has nothing to do with scaling up and is all about breaking down code into logical sections.

Core Javascript Multithreading

You’re probably thinking I’m way off here because everyone knows javascript is completely single-threaded. That’s right – those DOM events, AJAX, timed events – all executed by the same thread! (see John Resig’s article). The general idea is that javascript executes short-burst pieces of code and can afford to run all events in the same thread. By doing that, it avoids tricky synchronization issues and greatly simplifies the way we work with it.

AJAX and DOM events in javascript are a great example of using multithreaded paradigms (simulated multithreading that is) to simplify coding. The alternative would have been to write your own loop that does something like:


Instead, the javascript runtime already does that for you, so all you need to do is supply the callbacks. In addition, it also runs each event with its appropriate call stack so the multithreaded illusion looks very real in firebug.

Dojo Promises

Building on the existing body of knowledge on futures and promises, Dojo defines the concept of a Deferred.You may have also seen this exact same concept in Python, or a very similar one in Java’s java.util.concurrent.Futures. Java Futures are literally running in a separate thread so getting the future value can afford to block. In Javascript otoh, no blocking is possible since there’s only one thread executing the whole shebang, so the alternative is to provide a callback to execute when the future value becomes available. This means the promised value always gets processed in a different call stack even though it’s all in the same physical thread. However, that’s not a big issue in Javascript since the concept of an execution context is extremely flexible thanks to functions like apply() and call() (or wrappers like dojo.hitch()).

You may have noticed that Java Futures already return an object of the expected type, so you can use the Future as a proxy for the concrete value. For example, we could invoke the process() method below using a String


or we can just as well give it a future String value:

Future<String> future = ...
process(future.get()); // blocks until String is ready

The interface therefore remains uniform whether we use a Future or a concrete value. Since this is not the case in Dojo, we have a solid workaround for it in the form of dojo.when(), which does the extra work of normalizing promises and concrete values for us.


Dojo.declare Vs Javascriptzilla

This other day I’m like coding and stuff when I suddenly gained a whole new level of appreciation for what dojo.declare does for humanity and especially javascript developers. It’s hard to describe… it’s just … wow!

Quick background. Javascript was apparently supposed to come off as a simplified version of Java. As part of that simplification, rather than use classes for defining object blueprints, it uses object prototypes. You know the prototype pattern, right? It’s when you create one model object and clone it each time you want to create a new object of that type (analogous to creating a class and instantiating the class each time you want a new object). That gets you rid of having to create classes at all so you only deal with objects. However, by itself that’s not sufficient – you still need a constructor, which is that piece of logic that initializes the object when you create it. In addition, you need inheritance, meaning if a property or method is not attached to this object, check its superclass, and then the superclass of that… all the way up.

We can certainly define the constructor as a function, but where should we keep it so that it remains connected to the prototype object? In what’s no doubt one of the biggest hacks of the century, javascript decided to have that constructor function masquerade as the class (a concept it apparently tried to avoid all along), and attach the prototype object to that function under the prototype property. Strangely enough, the prototype object itself has a constructor property that points back to the function. So now you can totally invoke the constructor function as a regular function (and expect the unexpected if you do that), but what you really want is invoke it using the new operator, which is the psychedelic way to tell the machine to clone the attached prototype object and initialize it by running the constructor function on it!

Sound confusing? Adding inheritance to the mix makes it about ten times worse. Inheritance needs a few things like:

  • Creating a class instance should invoke the superclass constructor first (all the way up)
  • Invoking an inherited method should work as expected
  • Changing a static value in a superclass should be reflected in all the subclasses that don’t override it

Javascript immediately fails the first one because it doesn’t chain constructors. It can be done, but you have to do it yourself. The last two have been a source of some confusion but generally can be resolved by using javascript’s prototypal inheritance. The confusion arises from simplistic implementations that mixed in properties of all super-prototypes into a single prototype object, thus creating a denormalized object prototype; the problem with such implementations is that they fail the last point – changing a static value in a super-prototype does not get automatically reflected onto the sub-prototypes. This last issue is really more of a documentation problem since it’s resolved by the correct usage of prototypal inheritance.

Dojo.declare solves the aforementioned problems without much fuss and does a whole lot more. While javascript’s native prototypal inheritance solves the problem of single inheritance (except for the constructor part), Dojo takes that whole concept further to implement multiple inheritance. The classic problem with multiple inheritance revolves around collisions – when the same method is present in both left and right superclass (as in the Diamond problem). Dojo utilizes a relatively recent concept known as C3 linearization (aka C3 Method Resolution Order) to correctly simulate multiple inheritance. It has to simulate it because each object can only have a single super-prototype, so that’s done through some creative use of mixins. Of course dojo users don’t need to worry about it because it JustWorks(TM).

The result of calling dojo.declare is very much the same as that of manually creating a function that masquerades as your constructor/class, assigning it a prototype object, establishing the prototype and constructor chain, etc. Dojo.declare returns a completely normal-looking function object, which we can call using new to create new instances. Even small details are taken care of, such as if it’s a named function, dojo adds it to the global scope for us, and if called without new disaster is averted. As if that’s not enough, the mixin mechanism allows taking bare-bones interfaces and mixing in existing partial implementations into them – all using a single call to dojo.declare!