NetBen Ramblings about JavaScript and frontend development.


JSoo goes to the fridge

Whilst this blog was accomodating sound space for crickets, JSoo changed a lot since my last post. However a lot has happened since my last post as well, most importantly, YUI3 and google's closure got open sourced as well as ECMAScript edition 5 being published!!! JSoo was a good learning ground (especially to identify low level problems), however it's original purpose is redundant leading me to put JSoo itself into the proverbial fridge.

Disclaimer: All findings are based on first impressions superimposed on my knowledge and expectations. Please try it out yourself and form your own opinion, beware false prophets!


YUI3 is just brilliant, in many ways it killed JSoo, but in my honest opinion, it's a happy death ;) YUI3 is a great allround library and for me "allround" entails a collection of abstractions to work with the DOM, HTTP and browser environments, mechanism(s) to modularize your code and means to "progressively enhance" your websites and applications.  There's still room for immediate improvements though, for example while it's great Yahoo provides their own modules, using your own modules is more work then using YUI's modules simply because you have to repeat and resolve dependencies at "deploy time". I mean, you first need to construct your webapplication(s) sorting dependencies and then you need to sort dependencies again when you want to deploy your code into your website/app.

For me the logic place to resolve and define dependencies would be at module level, not implementation level, but I do understand why Yahoo chose for this, when you fire up a module chain, you want to parallel load all dependencies. Though in my opinion, using initializers might be an awnser to keep dependency resolutions in one place, in fact, I will be releasing a mini lib soon that does just that, based on some of JSoo's old code.

Google Closure

It's brilliant as well, but a monstrousity. Closure in it's entirety is not intended for your average run of the mill website, but for hardcore web applications. The API and documentation feels like it's written by hard core programmers for hard core developers, containing classes and tools that in my opinion should've been abstracted away from plain site. Now all it does is confuse people and scare developers. Luckily some people realize that and Micheal Bolin (formerly of Google) created Closure Lite, so if you're interrested in Google Closure, first delve into Closure Lite to first identify the good abstractions from the low level abstractions (I can't call them bad ;) ).

The compiler is interresting, but like compiling in GWT, it assumes everything is good at compile time and thats not really what asynchronous-on-demand-progressive-enhancement development is about. It forces a strictness where dynamic freedom is required, it feels like going backwards instead of forwards using ideoms that work great for other languages ignoring the fact this is a whole new playground we're all dealing with. In all fairness, thats my beef with all "compilers", they still put a lot of architectural decisions into the developers hands and frontend architecture is a mess where a good cleaning is needed.

The templating system of Google Closure is a fail. The ES side is nice, we frontend developers are used to silly names, but no selfrespecting Java developer will import the dependency "" and use it. The mindset of most Java developers is that if it sounds like crap, it's probably crap. What's in a name? A lot actually, clarity is quite important in Java. Shame really, besides the name, the templating system is rather funky ;)


Google Closure Tools is brilliant, but it's old school, I feel it will become redundant very soon. Google NEEDED to release a JS library to compete with Yahoo as GWT simply adresses a too small a market and right now they are behind. Google can gain up on Yahoo if they invest more into the compiler so it compiles to an on-demand-asynchronous-progressive-enhancement application. Right now, Yahoo is imo. the winner out of the two, so for big ES projects, use YUI3 (or Dojo).

How did Dojo get in here!?

Filed under: JavaScript, JSoo No Comments

JSoo progress.

It's been a turbulent few days since I first released JSoo to the public, but since then my ideas and vision towards JSoo expanded substantially. I'm personally quite excited in the direction I chose for JSoo, though I soon must take some time to write proper documentation, routemap and dump it all into an opensource repository/wiki for collaberation. In any case, if you look to the right, you can now see a text bit with the hours I've worked on JSoo, it's a simple way to see if JSoo is progressing ;)

For now, a little update/teaser:

A-synchronous property hash assignments
Assign inheritance from a non-existing property hash for later use, when defining the property hash later on, JSoo will synchronize inheritance and all methods will appear on instances drawn from the JSoo property hash reference. This grants powerful potential to JSoo#Externals.

Load external .jsoo files where JSoo property hashes are declared for better property hash management and code reuse.

Declare which methods a property hash MUST contain and use it to remove redundant inheritted methods from a property hash. This is taken from Classical OO, though I find Interfaces to be a rather useful tool for team collaberation. It will ofcourse be optional to use Interfaces.

At this point, JSoo is becoming rather bulky, while still a small size and up for further code refining, it would be nice to compile the code into a bare minimum needed to run the code. Turning JSoo into a development tool rather then an addhoc .js library. This extends my personal preference to mix and match .js libraries rather then using a full sized js framework. I have quite some hurdles to cross to achieve this and it might not be compatible with all browsers, but since in this case you'd use the compiled code rather then the original JSoo declarations, you can use a supported browser to build your applications.

I am considering in splitting JSoo up for 2 applications, one being development and the other being an addhoc library to use out of the box in your projects. This will depend on how bulky #Interface and #compile become.

In closing
JSoo is growing beyond being an alternative of creating "classes/prototypes", wether this is good or bad, time will tell. In any case, there are a lot of "Class/Protoype" builders out there, which fit certain purposes much better then JSoo on convenience or sheer size. It's silly to compete with them or boast my way is better, instead I'd rather build something new and potentially useful for developers while having fun doing it.

While other frameworks/libraries offer a lot of functionality and convenience methods, I like JSoo to be a tool to manage the code developers themselves write while using frameworks.

Filed under: JavaScript, JSoo No Comments

Ok, it’s called JSoo now ^^

Ok, so naming a library Prototype wasn't a wise choice, which I knew in advance but inocently thought it be harmless since I created this lib as plugable functionality. It safe to say, I was dead wrong about that... In other news... I renamed the library to JSoo as suggested by shadedecho, I really do hope I am safe on this name... *crosses fingers*.

Andrea Giammarchi from Web Reflection also made it clear to me that I didn't succeed in making clear in how JSoo differs from other Class constructing systems. So I better try harder now. First of all, some basics.

In JavaScript inheritance is arranged through prototypes, you basically attach a property hash to a function's prototype attribute.

    var Properties = { // property hash
        method : function() { alert("foo"); }
    var aClass = function(){}
    var instance = new aClass();
    instance.method(); //-> foo

One can declare the properties hash directly to a function's prototype attribute, however I deliberatly didn't do that in the above example. In the above example it is also possible to stick the Properties hash to another function's prototype attribute if desired and this is the rudementary concept behind JSoo. It makes the defined property hash leading instead of linking to the prototype attribute of a function. So we kinda steer clear from the Classical OO concept and approach the Object.beget idea more. Lets continue using what we set in the above example.

    Properties.method = function(){ alert("bar"); }
    instance.method(); //-> bar

By changing/overriding the method in the "Properties" hash, we also change the methods in the function's prototype attribute and thus all the instance of that function as well. Changing the methods on the function's prototype attribute also works, but you can see this as changing a property through a reference to "Properties". So by creating a seperate hash variable before assigning it to a prototype attribute, we basically have a method set to play around with without even touching any functions. This IS basic prototypical inheritance.

The next thing you want is a means to mix multiple property hashes into new hashes (multiple inheritance), a means to keep them out of the global scope and manage them more tightly, a means to call the methods from donor hashes in case you want to override a method on an instance, a means to call the original method with the same name but from donor1 and donor2. JSoo supplies those means.

        observe : function(){ /* do stuff */ },
        stopObserving : function() { /* do stuff */ },
        fire : function() { /* do stuff */ }

        load : function() { /* do stuff */ },
        send : function() { /* do stuff */ }

        load : function(url) {
  "loading", {message:"Loading the list"});
            this["::Connector"], url);
        observe : function() {
  "observe", {message:"I am being watched!"});
    }, "Observer", "Connector");

    var CityList = function(){ /* do stuff */ }
    CityList.prototype = JSoo("ListLoader");

The above example is just to give you an idea what you can do with JSoo.

JSoo supplies multiple inheritance through augmentation without having to search the scope chain since donor references are directly tied to the this keyword and prefixed with "::" to force a writing style to make you think twice on what you're doing as opposed to this.$super, which is pretty linear to begin with. You also don't have to assign a constructor or initializer when storing a property hash, some like that, some don't, imo. method sets (property hashes) should be portable and abstract, reducing reliance on constructors as much as possible, working more through arguments.

I will do a proper explanation on the JSoo.Module function in another installment.

Filed under: JavaScript, JSoo 1 Comment

So I reinvented prototype.js…

** EDIT, Library name is now JSoo, leaving this post intact to remind me of my stupid name choice for a library **

No, I am not talking about prototype.js from I've actually created a prototypical Prototype Multiple Inheritance System and Module Pattern decorator library. Considering what the library does, I found Prototype was the best name for it and my appologies in advance to the prototypejs crew for naming it likewise. I also have to add, this is merely a working draft version and imo. good enough to release, namespace issues will be a later concern (though I am using a special namespace pattern for plug and play action ;) )

As a reaction to the Javascript Inheritance Performance post on Ajaxian, I found myself thinking; "Why is everyone trying to superimpose Classical OO on Prototypical OO" and "There should be a better way according to what Douglas Crockford tries to teach us through his articles and book". So I got to work and Prototype + Prototype.Module is my idea on how to handle inheritance in a nice and orderly way.

Other inheritance systems solve it function.prototype = {} >here<.
This inheritance system solves it >here< function.prototype = {}

A complete description of Prototype & Prototype.Module can be found here. *EDIT LINK CHANGED*

The library can be downloaded to play around with here. *EDIT LINK CHANGED*

A quick example to entice and show what the library does.

Prototype example:

The Prototype function basically leaves the functions alone and only handles property hashes, so we can assign them to functions AFTER they're properly defined. It also supports multiple inheritance the prototypical way and allows back references to donor property hashes.

    Prototype("MammaCat", {
        talk: function() {
            return + " says: miauw";

    var MammaCat = function(name) { = name;
    MammaCat.prototype = Prototype("MammaCat");

    var Pookie = new MammaCat("Pookie");
    alert( //==> Pookie says: miauw

    Prototype("Kitten", {
        talk: function() {
            return + " says: meep";
        myMommaSays: function() {
            return "my momma " + this["::MammaCat"].talk.apply(Pookie);
    }, "MammaCat"); // <-- Inherit methods from Cat.

    var Kitten = function(name) { = name;
    Kitten.prototype = Prototype("Kitten");

    var Bella = new Kitten("Bella");
    alert( //==> Bella says: meep
    alert(Bella.myMommaSays()) //==> Pookie says: miauw

Prototype.Module example:

Prototype.Module provides a neat way to organise Module Patterns as well as allow the sharing of private variables over multiple Module Patterns through closure techniques.

    Prototype.Module("combat", function(cache) {
        cache.baseDamage = 10;
        return {
            rake: function() {
                alert( + " rakes for " + cache.baseDamage + " damage");

    Prototype.Module("specialAttacks", function(cache) {
        return {
            claw: function() {
                // yes, we reference a value set in another module pattern through the cache argument!
                alert( + " claws" + (cache.baseDamage + 10) + " damage");

    // the cache argument in the module patterns gets shared as long as you assign the
    // modules in a single call.
    Prototype.Module.attach(Pookie, "combat", "specialAttacks");
    Pookie.rake(); //==> Pookie rakes for 10 damage
    Pookie.claw(); //==> Pookie claws for 20 damage

The code is at version 0.0.1 and is basically a first draft to show how inheritance can be solved the prototypical way. I do understand people want to make JavaScript look and behave more like Java, but it's simply not a classical OO language. Use and embrace the prototypical way of scripting!

I am sure people can find errors, performance issues and have better ideas or suggestions, feel free to post them and I will incorporate it, proper credits will be given ;)

And if someone knows of a better name then Prototype (to avoid possible conflict with the good and nice lads at, then I am very much open to suggestions.

Filed under: JavaScript, JSoo 11 Comments