When it comes to executing Javascript in .NET, there are quite a few options. We have narrowed it down to Jint and Jurassic. They are quite similar, but they have some key differences which I will address here.

Jint

Jint is an interpreter based on ANTLR which means that the Javascript code is interpreted and executed each time a script is run.

Jurassic

Jurassic isn’t an interpreter like Jint, but has a compiler that compiles the Javascript into .NET byte-code. While that does offer a performance boost on subsequent runs of the same compiled code, we probably wouldn’t notice that since we’re going to compile and execute all scripts every time they run for simplicity’s sake.

Pros and cons

I’ve evaluated the two quite and lot, and I’ve dug through the code to look at how easy it would be to fix things I run across. Both projects are well structured, and it’s easy to find you’re way in the source code.

Jint

Pros

• Easy to get started with, just one dll and it just works.
• Extremely easy to expose .NET objects and functions to Javascript, and to return Javascript objects and functions.
• The source code is nicely structured and easy to understand and modify.
• When Javascript errors occur, you get a really nice error message with line numbers as you’d expect.
• Exposes a debugging API, which means that we could implement our own debugging GUI for Javascript

Cons

• All of the ECMAScript5 functionality isn’t implemented, such as Array.prototype.every. This is a minor con, since it’s easy to either implement it in Javascript or add them to Jint.
• Doesn’t respect “use strict”. Instead you specify strict mode as an option to the engine, which means that it’s either on or off for the whole script and you can’t trigger strict mode for a single block. Also a minor con since we would want all of our scripts to run in strict mode, regardless of “use strict”.
• The implementation is not as rock solid as Jurassic. I’ve had to hunt down and fix some bugs myself (#6950, #6949, #6948). It does worry me that these bugs existed, but since it has been a pleasure to work with the well structured code in Jint, it’s been quite easy for me to fix them.
• The project doesn’t seem to be as actively maintained as Jurassic.

Jurassic

Pros

• Seems like a more solid implementation, I didn’t find any bugs like I did with Jint.
• Easy to get started with, just one dll and it just works.
• The source code is nicely structured and easy to understand and modify.
• The project seems to be quite actively maintained.
• All of ECMAScript5 is implemented, and future Javascript features will likely come to Jurassic before they come to Jint.

Cons

• Isn’t nearly as easy to expose .NET objects as Jint. All objects you want to expose to Javascript needs to inherit from the Jurassic ObjectInstance class. I understand and appreciate the reason behind it since it means that all objects in Javascript can be treated the same way, regardless of whether it’s an exposed .NET object or a Jurassic object. But it means that we need a proxy class for each object we want to expose that transform the object into a Jurassic ObjectInstance. You could probably automate this by using reflection, so this is sort of a minor con.
• When Javascript errors occur, you don’t get the offending line number. This is a real show stopper for us. VBScript (which we currently use as a scripting language) doesn’t give us this either, and it’s one of the biggest reasons for us to change language.
• Offers debugging, but it seems like it’s only inside Visual Studio, which our script authors won’t have access to. And when debugging is enabled, the compiled assembly isn’t released from memory, which could become an issue for us.
• This is more of an annoyance, but Jurassic doesn’t allow a return statement outside of a function, which means that your script can’t look like this:

  var obj = {
    prop1: 1
  }
  return obj;
  

  and then evaluate that script and get the returned Javascript object. Jurassics Evaluate method takes the last line in the script, evaluates it and returns it, which means that you’d have to do something like this:

  var result = engine.Evaluate("var global_return = function() { " + scriptCode + " }; global_return();");
  

Conclusion

We will probably use Jint as our Javascript engine. It’s a tight race, but there were some things that made us choose Jint.
While Jurassic is a more solid Javascript implementation, the errors we’ve found in Jint are either edge cases or easy to fix. The things that tipped the scale in Jints favor are the detailed Javascript errors, and how easy it is to expose .NET objects to Jint.

If our needs were more geared towards having a lot of logic and functionality in Javascript, and not how easy it is to expose .NET functionality and having small pieces of Javascript to control the flow of the application, we would probably have chosen Jurassic instead.

The application is a LOB app with offline capabilitites, so it’s mostly a standard CRUD app. While developing this application, I’ve learned a lot about the different quirks in the browsers on Android and iPhone, and this is what this blog post is going to be about.

Application Cache

Using the application cache is a must for anyone who wants to develop a web app with offline capabilities. At first we ignored the application cache, because we just couldn’t get it working. The problem was that as soon as the application cache was updated, it was impossible to send a request to the server. Turns out that we just didn’t read the spec, and we were missing:

NETWORK:
*

in the manifest.

User specific cache

To use the application cache, we needed to cache views depending on which user was logged in. So setting:

<html manifest="/Manifest">

on our start page was out of the question, since that would mean the browser would download the manifest even if you’re not logged in. Instead, we decided to use an iframe which loads once you have logged in. The contents of the iframe looks something like this:

<!DOCTYPE html>
<html manifest="/Manifest">
<head>
    <script type="text/javascript">
    var app_cache = window.parent.jQuery(applicationCache);

    app_cache.bind("cached checking downloading error noupdate obsolete progress updateready", function(event) {
        window.parent.ApplicationCacheEventDispatcher.trigger(event, applicationCache);
    });
    </script>
</head>
<body>
</body>
</html>

So when you log in, we use Javascript to append an iframe pointing to that html file. The Javascript in the iframe makes sure that any application cache event that is caught in the iframe gets passed on to the main window, which lets our application display a loading message to the user.

Just don’t forget to print out the user id or something unique for the logged in user in the manifest, otherwise the application cache won’t be updated if the user logs out, and logs in with a different account. Our solution to this is to print out the user id and application version as a comment in the manifest, like this:

CACHE MANIFEST

# version: @Version
# user: @User.Id

CACHE:
/
[...]

Forcing an upgrade

Sometimes you need to make breaking changes between versions, and you need to make sure that the application cache is updated on all devices before your users can continue to use the application.

An issue we ran into quite a lot at first was that after a customer had upgraded the application on the server, random errors occured for their users. This happened because the users still had the old Javascript files. That is, the application cache wasn’t updated fast enough.

To get around this, we started to pass the version number along with every request to the server. That gave us the option to check the version that came with the request, compare it to the server version, and tell the client to update the application cache if necessary.

HTTP status == 0

A couple of weeks ago, a bug report came in where a user was using the offline mode in the application. He went to another site, then came back to the application only to find it unusable. None of the pages would load from the application cache. Turns out that by browsing to another site and then returning and trying to fetch something from the application cache can result in getting a HTTP status of 0 instead of 200 in Android. And because of the incorrect HTTP status, jQuery reported it (correctly) as a failed request. So we needed to change the code to take this into account. A somewhat simplified version:

function get(url, on_success, on_error) {
    $.get(url, {},
        function succ(response, textStatus, XHR) {
            on_success && on_success(response, textStatus, XHR);
        },
        function err(jqXHR) {
            if (jqXHR.status === 0) {
                if (jqXHR.responseText.trim() == "") {
                    on_error && on_error(jqXHR);
                } else {
                    on_success && on_success(jqXHR.responseText, "ok", jqXHR);
                }
            } else {
                on_error && on_error(jqXHR);
            }
        }
    );
}

localStorage

LocalStorage works mostly as you expect it; it’s a simple key-value-store with a finite amount of storage, and once you hit that you get an exception. But we got a really wierd bug report from a user where he would browse to another site, and come back to the application to find that all of his settings and data were gone.

Turns out that under some circumstances, Android doesn’t load the localStorage data when you hit the back button. I’m guessing it has something to do with the fact that Android doesn’t always reload the page when you go back, it loads it from the browser cache (not the application cache) instead.

So to get around this Android bug, we set a persistent value in localStorage which we use as a check to see if localStorage is correctly loaded.

var check = "1234567890"
localStorage.setItem("android_check", check);

and when we want to fetch something from localStorage, we do:

var hasItem = function() {
  return (typeof localStorage[key] != "undefined" && localStorage[key] !== null);
}
var getItem = function(key, def) {
  if (!hasItem(key)) {
    if (localStorage.getItem("android_check") !== check) {
      // Reload the page so Android reloads localStorage
      window.location.reload();
    }
    return def;
  }
  return localStorage.getItem(key);
}

overflow: scroll

Our application sometimes needs to open a popup menu with different options, and that menu needs to be scrollable. This is simple in iOS5 since it supports overflow:scroll but in Android, not so much. And it’s not just that, there are differences in how you have to solve it for Android 2 and 3. This because you can’t set scrollTop on elements with overflow:hidden in Android 3, but it works for Android 2.

The way we solved it in Android 3 was to set overflow:visible and setting a fixed height on a wrapper element, and then adjusting the menus margin-top in a touchmove event handler. Needless to say, the scrolling experience in Android 3 is horrible compared to iOS5 and Android 2, but at least it works.

Inputs in Android

I don’t know how many hours I’ve spent fiddling with making inputs on Android play nicely. The root of the problem is that Android doesn’t use the browsers built-in input controls, but instead places some other wierd, internal input above the browsers input field.

Setting focus on an input field

The forms in our application works in a quite specific way. Instead of just displaying the input fields directly, we have a display element that is hidden and replaced with the real input when you tap on the wrapping element.

That is, the tap event handler for the wrapping element calls .hide() on the display element, and .show().focus() on the input. The reason we do this is to be able to format the display in a different way than when you edit the value.

The problem with this is that calling .focus() on an input in Android doesn’t bring up the keyboard, unless the call to .focus() happens in a click event handler. This is a minor issue for us, because the tap event handler gets called about half a second before a click event occurs, which gives us time to show the real input, and when the actual click occurs, the input is visible and catches the click, and the keyboard is displayed.

The real problem is if you want to give an input focus when you click somewhere else in the application. It simply doesn’t work, the user has to tap twice for that; once on our custom edit button to show the input, and then once on the input to get the keyboard.

Page animations

When you go from one page to another, the old page is transitioned out to the left, and the new page comes in from the right. While CSS transitions is very much possible in Android, it’s actually a much smoother experience to use jQuery.animate(), espcially if the pages are long. But I hear that Android 4 has hardware accelerated CSS transitions, so I hope to get a better result there.

An issue with page animations is the scroll position when you go from one page to another. When you hit the back button, you want to land on the same scroll position as when you left that page. This just works in Android, the scrolltop is automatically set correctly. But on iPhone, you’re back to the top of that page, which kinda sucks.
The way we’ve solved this is to save the $(window).scrollTop() before a page animation starts, and then when the pages have finished animating, check if there is a saved scrolltop for the current url. If there is one, we set the $(window).scrollTop() to that, but only if $(window).scrollTop() == 0.

In .NET, there is something called Extension Methods, which are basically the same as extending a builtin object in Javascript. It might look something like this:

using System;

namespace MyAppExtensions
{
    static public class Extensions
    {
        public static string ToUpperFirst(this String s)
        {
            return s.Substring(0).ToUpper() + s.Substring(1);
        }
    }
}

using System;
using MyAppExtensions;

namespace MyApp
{
    public class SomeClass
    {
        public SomeClass()
        {
            var myString = "one short sentence".ToUpperFirst();
        }
    }
}

The key thing here is that you can hide your extension methods in a specific namespace, here called MyAppExtensions. So if anyone wants to use this extension, they need to add “using MyAppExtensions;” in their code. So it doesn’t pollute the global namespace, which is good. You also get a compile-time error if you use two namespaces which define the same extension method.

But you can achive basically the same thing in Javascript by using closures. Let’s say that you’re writing a game where you need to pick a random element from an array often, and you would really like to be able to do:

 [1, 2, 3].random()

You could just add random to Array.prototype, but you know the risks of it, so you don’t. Instead, you can do something like this:

var extendArrayWithRandom = function(fn) {
    if (typeof Array.prototype.random != "undefined") {
        throw "Cannot redefine Array.prototype.random";
    }
    var random = function() {
        var key = Math.round(Math.random() * (this.length - 1));
        return this[key];
    }
    Array.prototype.random = random;
    fn();
    if (Array.prototype.random !== random) {
        throw "Array.prototype.random was redefined";
    }
    Array.prototype.random = undefined;
}

And use it like this:

extendArrayWithRandom(function() {
    console.log([1, 2, 3, 4, 5].random()); // will output a number between 1 and 5
});
console.log([1, 2, 3, 4, 5].random()); // will throw an error because
                                       // random is no longer a method on
                                       // the array prototype

This way, [].random will only exist inside the function that you pass into extendArrayWithRandom(), and if anyone else has defined a global random function for Array, an error is thrown so we don’t risk any confusion. It also checks that noone has redefined Array.prototype.random during the execution of our function. This because it would possibly produce even more confusing results if someone defined global extension during run time without checking if one already exists.

Callbacks

As mentioned in the comments below, this gets a little tricky if you combine it with callbacks/asynchronous events. Take this for example:

extendArrayWithRandom(function() {
    loadJson("/settings", function(settings) {
        var rand = settings.random();
    });
});

Now assuming that loadJson does an Ajax request, the function that we pass into loadJson will execute later than the one we pass into extendArrayWithRandom. This means that Array.prototype.random is no longer available in the Ajax callback, because as soon as the function we pass into extendArrayWithRandom is finished, we remove our implementation of Array.prototype.random.

To get around it, we need to be able to let extendArrayWithRandom return a new function. Something like this:

var extendArrayWithRandom = function(fn) {
    var random = function() {
        var key = Math.round(Math.random() * (this.length - 1));
        return this[key];
    }

    return function() {
        if (typeof Array.prototype.random != "undefined") {
            throw "Cannot redefine Array.prototype.random";
        }
        Array.prototype.random = random;
        fn.apply(this, arguments);
        if (Array.prototype.random !== random) {
            throw "Array.prototype.random was redefined";
        }
        Array.prototype.random = undefined;
    }
}

We can still use it like we used to, but we have to make sure that we execute the function that it now returns:

extendArrayWithRandom(function() {
    console.log([1, 2, 3, 4, 5].random());
})();

Notice the extra () at the end, which means that we execute the function directly when it’s returned to us. Since we’re now returning a function instead, we can get back to our Ajax example:

extendArrayWithRandom(function() {
    loadJson("/settings", extendArrayWithRandom(function(settings) {
        var rand = settings.random();
    }));
    console.log([1, 2, 3, 4, 5].random());
});

Since we have two functions that will execute separatly, we need to call extendArrayWithRandom twice to make sure that these two functions will have Array.prototype.random, and that we clear it right after they have executed.

Conclusion

Adding methods to global objects is something that you should be quite careful with, simply because it changes the global state of your application, and it’s hard to predict the implications of that.

This method isn’t foolproof, since you can be affecting others by using it. As soon as you call another function in another module inside your extendArrayWithRandom, Array.prototype.random will be accessible to them as well. Now that probably won’t cause trouble, but it’s hard to know for sure.

DI is about pushing object creation and wiring as high up in the application as possible, which gives you one central location for the flow of logic.

Code components have dependencies, whether you’re using Java or Javascript. When your UI widget needs to make a server request to fetch some content, you depend on some code to carry that out. There are usually three approaches.

1. Use a global symbol, such as $.ajax in the world of jQuery.

2. Use a service locator, something like:

function updateCustomer(locator) {
  var server = locator.server();
  server.get("...");
}

Or having the locator being a global variable.

3. Only pass in what you need, like this:

function updateCustomer(server) {
  server.get("...");
}

The first option is the simplest. $.ajax is just a global function that anyone can use. This is also why it’s the most problematic, because if anyone can use it anywhere, you will end up with no idea of which parts of your application is making Ajax calls. You’re basically saying “use any tools you like, I don’t care” to your function.

The second alternative passes in a service locator instead, which is better because you have control over what functionality you expose through your locator. It’s like saying “here’s a bag of tools, you can’t use any other than these, but do what you want with any of these in the bag”.

The third is the most straight forward. It’s like saying “here’s a screwdriver, it’s what you’re gonna use”. Since we’re just exposing the server object, there is no risk that other features using other objects will be added to our function. That is a risk with the other two solutions, since they expose more functionality than needed. Another benefit is that it’s very easy to spot what dependencies your objects have, since they are declared in the constructor. With a locator or with globals, you might have dependencies hidden in large chunks of code that are easy to miss. You are forced to think very hard about how your application is layed out, because it becomes very easy to spot if an object is doing to much, if it requires too many dependencies. You also have to think about how to pass these dependencies around.

Dependency injection is hard

So if the third solution is so great, how come most people use the first two? Simply because it’s hard to achieve. Using a locator is simpler, since you just pack a bag with lots of things and pass it around. But if you use the third option, you have to keep track of who wants the different tools, and make sure that they get them. You also need to make sure that everyone can’t ask for anything.

In other languages, there are frameworks that help you with these things. Automating object creation in a language like Java or C# is somewhat simple, because you have type hints in the constructors. You can inspect a constructor and find out what it wants. But there is no way to do that in Javascript, since it doesn’t have types or type hints. Because of this, making a DI container in Javascript is bound to get messy, because you need to define construction rules for all objects. This is problematic because new objects can’t be added to your application without modifying the wiring code.

A shot at an automated container in Javascript

So we now basically know what we need. A container that is semi-smart and can assemble hierarchies of objects. It needs to be able to create objects by convention instead of configuration.
To achieve this, we have a few options. First off, we can cast a constructor to a string which gives us the whole method body and then parse out the argument variable names and use them to map to objects. This is a brittle and error prone idea, since someone might rename a variable and that might take down the entire application. Another option is to add a sort of type hints. Something like this:

function Server() {
  return {
    get: function(...) {}
  };
}

function updateCustomer(server) {
  server.get("...");
}
updateCustomer.dependencies = ["Server"];

It’s a little unorthodox and perhaps not so Javascripty, but it makes our object more self contained. Our function still isn’t grabbing Server direcly as with a Service Locator, it’s merely saying that it would like to get some implementation that behaves like Server does. But it isn’t very pretty, because the type hints are below the function body, which can be an issue with a more lengthy function. So here’s some syntactic sugar:

var updateCustomer = dependant(
  ["Server"],
  function(server) {
    server.get("...");
  }
);

The dependant function just maps the function together with the type hints, and it also gives you a simple way to check who has which dependencies.

So now it’s just a matter of inspecting the dependencies array of a constructor to be able to map it together. Here’s a proof of concept:

var dependant = function(dependencies, func) {
    func.dependencies = dependencies;
    return func;
}

var Container = function() {
    var namespaces;
    var instances;
    var constructors;

    return {
        _init: function() {
            namespaces = [];
            instances = {};
            constructors = {};

            return this;
        },
        addNamespace: function(namespace) {
            namespaces.push(namespace);
        },
        get: function(klass) {
            if(!instances[klass]) {
                if(constructors[klass]) {
                    instances[klass] = constructors[klass]();
                } else {
                    instances[klass] = this.create(klass);
                };
            };
            return instances[klass];
        },
        create: function(klass) {
            for(var i = 0; i < namespaces.length; i++) {
                if(namespaces[i][klass] && typeof namespaces[i][klass] == "function") {
                    var constr = namespaces[i][klass];
                    if(constr.dependencies) {
                        var args = [];
                        for(var j = 0; j < constr.dependencies.length; j++) {
                            args.push(this.get(constr.dependencies[j]));
                        };
                        return constr.apply(namespaces[i], args);
                    } else if(constr.length == 0) {
                        return constr();
                    };
                };
            };
            throw "Cannot create '"+ klass +"' because there isn't a registered instance or \
                   constructor, and there was no way to auto wire it.";
        },
        registerConstructor: function(klass, creator) {
            constructors[klass] = creator;
        },
        registerInstance: function(klass, instance) {
            instances[klass] = instance;
        }
    }._init();
};

And some usage code:

var ns = {};
ns.Alerter = function() {
    return {
        alert: function() {
            alert("Mjello!");
        }
    }
}

ns.MyObject = dependant(
    ["Alerter"],
    function(alerter) {
        return {
            doStuff: function() {
                alerter.alert("Mjello!");
            }
        }
    }
);

var cn = Container();
cn.addNamespace(ns);

var o = cn.get("MyObject");
o.doStuff();

I haven’t used this type of DI in a Javascript application yet, so I can’t really say if it’s any good, but I get a good vibe from it so I’m planning on using it for a Javascript application that I’m about to create.

An added benefit here is that the dependencies array can contain anything, not just strings with function names. It could contain CSS selectors to let you decouple DOM access, and maybe even remove the tight coupling with a library such as jQuery or YUI. It could also contain an array of method names, something like:

ns.MyObject = dependant(
    [["alert"]],
    function(alerter) {
        return {
            doStuff: function() {
                alerter.alert("Mjello!");
            }
        }
    }
);

This says, “I need one object, and I need it to have an alert method”, which is basically a flirt with a structural type system that is a very good fit for Javascript.

Conclusion

Javascript is a very open language. You can choose to go OO or procedural, and you can even choose which type of OO you want to use, classical, prototypal or parasitic. It’s only natural then that there are also a number of different ways to manage dependencies in an application. So when you start a new project in Javascript, you have a smörgåsbord of ways to write code. There’s no wrong or right, there’s only what is appropriate for your application. But when you’ve decided which way to go, stick with it.

By using parasitic inheritance, you can avoid using the new operator all together. The new operator isn’t evil, but it’s problematic in that if you write a function and you expect it to be called with the new operator but someone forgets it, wild thing can happen, and it can be really hard to debug. Let’s take an example:

function greet() {
  alert("Welcome, everyone!");
}
function Greeter(name) {
  this.name = name;
}
Greeter.prototype.greet = function() {
  alert("Welcome " + this.name);
}
function Person(name) {
  this.name = name;
  this.greet();
  return this;
}
Person.prototype = new Greeter();
Person.prototype.toString = function() {
  return "I am " + this.name;
}

// Example 1
var name = "Andy";
var person = new Person("Coffeescripter"); // alerts "Welcome Coffeescripter"
alert(name); // alerts "Andy"

// Example 2
var name = "Andy";
var person = Person("Coffeescripter"); // alerts "Welcome Andy"
alert(name); // alerts "Coffeescripter"

This way of writing a class and saying that Person inherits from Greeter is rather ugly, so check out John Resigs implementation for some eye candy: http://ejohn.org/blog/simple-javascript-inheritance/

If you’re not familiar with how this works in Javascript, this may blow your mind. But it’s perfectly valid code, it’s just that the this variable points to different places depending on whether you used the new operator or not. When the new operator is used, this points to the new instance that was created. When you’re not using the new operator, this points to the object that the function was executed in, which in this case was the window object, and that is why this.name = name is overriding the value of the global variable name. This because var name = "Andy"; here is technically the same as window.name = "Andy";.

You can’t tell from inside the function if the new operator was used or not, so you can’t throw an exception if the new operator was omitted. You could just say that “all functions that begin with a capital letter should be called with the new operator, or else you’re stupid” and be done with it. And while that might be true, you’re still going to be the one debugging for an hour or so when the new guy who doesn’t know Javascript that well forgets about the new operator.

Parasitic Inheritance

So how about that parasitic inheritance then? It works like this instead:

var Greeter = function(name) {
  return {
    greet: function() {
      alert("Welcome " + name);
    }
  };
};
function Person(name) {
  var obj = Greeter(name);
  obj.greet();
  obj.toString = function() {
    return "I am " + name;
  }
  return obj;
}

// Example 1
var name = "Andy";
var person = new Person("Coffeescripter"); // alerts "Welcome Coffeescripter"
alert(name); // alerts "Andy"

// Example 2
var name = "Andy";
var person = Person("Coffeescripter"); // alerts "Welcome Coffeescripter"
alert(name); // alerts "Andy"

The behaviour is the same if you call Person with the new operator or not. And because of that, it simpler just to forget about the new operator. To me, this code is more straight forward and less magical than the first example, which is always a good thing. One issue people is having with this approach is that for every Person you create, you also create new versions of the greet and toString functions. With the first example, all Person objects share the exact same greet function. That of course means less memory usage, but it also introduces a somewhat scary thought. If all Person objects share the same greet function, what happens when someone decide to replace a persons greet function, it doesn’t just affect that object, it affects all person objects.

This trouble with parasitic inheritance

Something I kept running into with parasitic inheritance was how I didn’t have access to the created object in the beginning of the function, like this:

function Person() {
  var bazooka = Bazooka(this);
  return {
    shoot: function() {
      bazooka.shoot();
    }
  };
}

var Bazooka = function(parent) {
  return {
    shoot: function() {

    }
  }
}

Disregarding that we have a cyclic reference here between Person and Bazooka, the problem is that this in var bazooka = Bazooka(this); isn’t pointing to the person object that we are creating, but the object that the Person function is running in; the window object. So how do we get around this? We could do something like:

function Person() {
  var obj = {
    shoot: function() {
      bazooka.shoot();
    }
  };
  var bazooka = Bazooka(obj);
  return obj;
}

But that’s about as pretty and clear as VB’s let’s-use-a-variable-with-the-same-name-as-the-function-as-the-return-mechanism-because-function-names-never-change-and-nobody-will-forget-to-update-all-references-to-the-return-variable-when-the-function-is-renamed. So yeah, we can do better. Something like this:

function Person() {
  var bazooka;
  return {
    _init: function() {
      bazooka = Bazooka(this);
      return this;
    },
    shoot: function() {
      bazooka.shoot();
    }
  }._init();
}

It looks a lot better, and if you’re used to classical inheritance, you’re probably used to looking for property declarations at the top, a constructor right after that, and methods down below. If you’re the suspicious type, you might have noticed that by doing this, we are exposing the _init function to be called again. Which is true, there is nothing stopping you from doing: var p = Person(); p._init(); But if this means the end of the world for you, you can always add this._init = undefined; as the first line in the _init function, which makes it impossible to call it twice.

Privileged functions

In the first example, there is no way to have a private function that all your public functions can call, not even with John Resigs prettier version. But with parasitic inheritance, it’s very natural to hide variables and functions through closures, like this:

function Person(name) {
  var bazooka;
  var greet = function() {
    alert("Hi! I'm " + name);
  };
  return {
    _init: function() {
      bazooka = Bazooka(this);
      if(name == "Andy") {
        greet();
      }
      return this;
    },
    shoot: function() {
      if(name != "Andy") {
        bazooka.shoot(name);
      }
    }
  }._init();
}

Through the closure that the function call to Person creates, both shoot and _init has access to greet, bazooka and name.

Conclusion

The key difference between classical and parasitic inheritance is that the classical way is much more focused on an objects type. Change one object, and all other objects of that same type get’s changes. Parasitic inheritance doesn’t care about types. It’s more about assembling functions and properties to create a logical unit. Instead of caring if an argument to your function is of the type Person, you only care about whether or not it has the function greet. There is no right or wrong here, and the two can happily co-exists, but the thing that makes me use parasitic inheritance is how it’s aligned with the dynamic nature of Javascript.

But even with ASP.NET MVC, and Django, I still come back to doing web development in PHP in the projects I do on my spare time. And the reason is definitely not language elegance, but it’s very much because of the framework/library Konstrukt.

Most of the other MVC-ish frameworks out there use the idiom of “/controller/action/id/some/other/parameter”, and it just doesn’t feel right. It feels right in simple cases like “/users” and “/users/12″. But what about “/users/edit/12″? The url should – if you ask me – be hierarchical, and it should always be possible to remove the last url segment, and still get a logical response. But if you remove 12 from “/users/edit/12″, what do you get? A bunch of forms, so you can edit all users at the same time?

Instead, Konstrukt handles this by using hierarchical controllers/components. So instead of mapping a request to one specific controller, one controller handles each url segment. So if you have a url like “/users/12/comments”, you’d start of by having the root controller handle the “/” part. That controller sees that the whole url isn’t just “/”, so that controller is responsible for mapping forward to another controller, to handle the “users” segment. That controller also sees that there’s more in the url, and maps forward to a controller that handles “12″, and then – last but not least – the controller that handles the “comments” part. That controller sees that it’s the last part, so it’s responsible for rendering the result. You might think that ends up being an awful lot of controllers, and it sure does, since one controller basically does just one thing. But that’s a good thing. Instead of having a User-controller with Add, Remove, List, Edit-actions. It also lets you reuse controllers very elegantly. You might have both “/comments”, and “/users/12/comments”, for which you can reuse the same controller. Each controller has access to it’s parent controller, so the controller can use it’s parent as a way to filter out comments per user, or display all comments.

I know that I can use routing in most other frameworks to get almost the right result, but it just ends up feeling like I’m wedging it in, it’s not as elegant as with Konstrukt, mostly because of the “one controller with many action methods” thing.

This, together with having control over controller creation which allows you to use a DI container to create them, together with excellent support for different content types, together with the fact that it’s very (almost extremely) loosely coupled, makes me love PHP. I like PHP, but Konstrukt makes me love it. If I start a new web project in Python or C#, I start of with a great feeling of how elegant those languages are, but I always end up really missing PHP because of Konstrukts elegance. If I could just find the time to port Konstrukt to C# and Python…

function onMousedown(e) {
  initDrag(e);
}
function initDrag(e) {
  document.onmousemove = onMousemove;
}
function onMousemove(e) {
  element.style.top = e.pageY +'px';
  element.style.left = e.pageX +'px';
}

But I would suggest that the code to reposition the element should be moved away from the event listener. Not just moving that code into it’s own function, and let the event listener call that function (even though that’s a good thought). Instead, let’s create a queue:

function onMousedown(e) {
  initDrag(e);
}
function initDrag(e) {
  document.onmousemove = onMousemove;
}
var new_positions = [];
function onMousemove(e) {
  new_positions.push({top: e.pageY, left: e.pageX});
}

And then code to process the queue:

var paint_interval = setInterval(
  function() {
    if(new_positions.length) {
      var pos = new_positions.shift();
      element.style.top = pos.top +'px';
      element.style.left = pos.left +'px';
    }
  },
  50
);

So what’s the use of this? Doesn’t it just add unnecessary complexity? In this very simple example it sure does, but there’s still a beauty in it since we are separating concerns. On one side, there’s code that listens to what the user wants to happen, and adds that to the queue. On the other side, there’s code that decides whether to actually listen to what the user wants to do, or to deny it, and the two sides doesn’t need to know about the other.
You could add logic in the queue processing function (the function in the interval) that checks if the queue is too large, and then ignore the first 10 queue items and move directly to number 11, which would save the browser having to paint those 10 steps and move directly to number 11.
Another reason could be that you only want to allow the element to move X number of pixels per run, regardless of how fast the user drags, and then eventually catch up with the mouse position. Or if you have a lot of stuff going on, and you don’t care if the dragging is smooth, you can change the interval to run 5 times per second, instead of 20.

This is essentially the Command Pattern, except that a Command is executable in itself, and my queue items are just data holders, and it’s up to the queue processor to make sense of that data. The Command pattern is more general, as any command can be added to the queue/stack, and thesehere queues are more specialized, since all queue items are of the same type.

So the point is to separate logic, and decouple different parts of your application to make them more isolated. The queue processing doesn’t care where a queue item comes from, it’s only concern is to process the queue. That enables you to add queue items from other parts of the application as well, and the code that listens to mousemove events doesn’t need to be touched.
That enables you to let your application grow and meet new requirements without making a mess of the code with lots if nested if statements, since you have separated logic. If nothing else, you can impress other people by telling them about your fancy queue processing architecture. It probably won’t impress beautiful women at your local bar though.

So let’s say you have code like this:

var User = Class.extend({
  _friends: [],
  _name: '',
  init: function(name) {
    this._name = name;
  },
  name: function() {
    return this._name;
  },
  addFriend: function(friend) {
    this._friends.push(friend);
  },
  greetFriends: function() {
    alert('Hi '+ this._friends.join(', ') +'!');
  }
});

var fred = new User('Fred');
var mike = new User('Mike');
var jennifer = new User('Jennifer');
var sara = new User('Sara');

fred.addFriend(jennifer.name());
fred.addFriend(sara.name());

mike.greetFriends();

You would expect that Mike who nobody seems to like would just alert “Hi !”, but he alerts Freds friends as well. And that’s because objects in Javascript (arrays are objects as well) are passed by reference. So all of Freds friends also become Mikes friends, since they share the same friend array.

So to get away from this, the trick is to declare your properties in the constructor, like this:

var User = Class.extend({
  _friends: [],
  _name: '',
  init: function(name) {
    this._name = name;
    this._friends = [];
  },
  name: function() {
    return this._name;
  },
  addFriend: function(friend) {
    this._friends.push(friend);
  },
  greetFriends: function() {
    alert('Hi '+ this._friends.join(', ') +'!');
  }
});

Since the constructor (init) is called every time a new user object is created, the friends array is set for only that instance. But sometimes you might forget to reset the variable in the constructor, so I usually do this:

var User = Class.extend({
  _friends: false,
  _name: '',
  init: function(name) {
    this._name = name;
    this._friends = [];
  },
  name: function() {
    return this._name;
  },
  addFriend: function(friend) {
    this._friends.push(friend);
  },
  greetFriends: function() {
    alert('Hi '+ this._friends.join(', ') +'!');
  }
});

Just to make sure that there’s no risk of a shared array. You might even skip the declaration at the top, but I’m used to looking there for property declarations, so I set them at the top.

I’m sure that you already thought about this by know, but this feature in Javascript makes it possible to have “static” properties that are shared between all instances of the same class. I would advise you to use such a strategy sparsely though, as it’s not very obvious that it’s a shared variable. But the good thing about it is that this Javascript version of static properties doesn’t suffer the same problems that statics do in Java/PHP, since the static can be turned into a local just by resetting it in the constructor, without it affecting other objects. Something like:

var User = Class.extend({
  _friends: [],
  _name: '',
  init: function(name, share_friends) {
    this._name = name;
    if(!share_friends) {
      this._friends = [];
    }
  },
  name: function() {
    return this._name;
  },
  addFriend: function(friend) {
    this._friends.push(friend);
  },
  greetFriends: function() {
    alert('Hi '+ this._friends.join(', ') +'!');
  }
});

var fred = new User('Fred', true);
var mike = new User('Mike', false);
var jennifer = new User('Jennifer', true);
var sara = new User('Sara', true);

fred.addFriend(jennifer.name());
fred.addFriend(sara.name());
mike.addFriend(fred.name());

mike.greetFriends();
sara.greetFriends();

This code now tells us that Mike only has Fred as a friend, whereas Sara shares friends with Fred, and has both herself and Jennifer as her friends.

Happy coding!

You can see it here (it’s a work in progress, please be gentle).

After quite a lot of tweaking, bug fixing and making sure it works in popular browsers, I’ve now released version 1.0.0. If you find any bugs, or have any features you’d want for it, please don’t hesitate to send a comment here.

Happy coding!

It basically takes the best of an input field, and a select box/list, and mixes it together. It takes a real select list and transforms it to an input field with options, and mimics most (if not even more) of the features of a real select box. Since it’s a real select list from the start, it degrades nicely for those without Javascript.

You can find the code and an example here:
http://coffeescripter.com/code/editable-select/