Category Archives: frameworks

OSGI for Javascript

We recently started working with OSGI (1) in our project and it’s petty nice. It’s a system for managing dependencies at runtime, enabling deploying and undeploying modules at runtime, with modules (‘bundles’ in OSGI terminology) automatically being stopped when a module it depends on goes away for some reason, and restarted when it comes back. Not too big or complex, just a small framework that gets the job done. Actually OSGI is a specification and the framework is an open source implementation of it called Apache Felix (2).

We develop in Eclipse and recently I stumbled upon an article about Eclipse E4, the soon to be fourth incarnation of the Eclipse IDE.

What was interesting about it is that the Eclipse people are looking at projects like Firefox with very succesfull add-on systems and are aspiring to implement the same ability to be able to write plugins in Javascript. Traditionally Eclipse plugins are written in Java and deployed as OSGI bundles, but OSGI is not available for javascript. Javascript doesn’t even have packages and namespaces, let alone bundles. But the cool thing about javascript is that you can bend it to your will. So they implemented javascript namespaces in the same way the people of Dojo (3) did and on top of that created a system that will let you write OSGI bundles in javascript. How cool is that? This kind of clear dependency management is what’s needed to scale javascript powered web applications to the extent that they can rival desktop applications.

(1) http://www.osgi.org
(2) http://felix.apache.org/site/index.html
(3) http://www.dojotoolkit.org

Is Prototype evil?

Let me begin this critique by saying that I think Prototype JS is an inspired piece of work and that it inspired me to think about javascript in a whole different way. It’s also a stable framework that gets the job done and is used on a large number of websites. And it’s very comfortable programming when you know prototype is on the page, because it offers a lot of nice and handy feautures which are not natively available cross-browser.

So it must be good right?

Well… here’s where my story begins about what I don’t like about Prototype JS. But first, take a look at the source code for prototype 1.6.0. You don’t have to read it all, just glance at it and scroll through the file a bit. That’s a lot of code right?

This blog is about unobtrusive javascript… but I really can’t call prototype unobtrusive due to the sheer size of it. If unobtrusive code should not get in your way, how can a mammoth like prototype qualify?

Don’t get me wrong here. I don’t really care about the size of the file. I care about the size of the codebase. The number of objects and methods that it exposes and I thus should know about. Because unobtrusive javascript is about not getting in each other’s way. It’s about working together with other scripts on the page. By having a rather large API, with a fair amount of short identifiers in the global namespace, other scripts sort of have to ‘know’ that prototype is on the page and adjust for it. Just read about the dollar function clash between jQuery and Prototype JS.

But that’s not all of it. Just having a large API does not make prototype evil. But prototype is monolithic. It’s not a large set of modules in one file, though it may look like that. It may even be stored like that in CVS. But it’s not.

Some pieces of code may be worse than others, but the pieces of code that I have personally tried to pull out of prototype were very interwoven with the rest of prototype.

For example prototype tends to ‘enhance’ DOM objects and arrays using functions $() and $A(). Those functions then add some extra methods to otherwise native types. Those enhanced methods are happily called everywhere, but they are prototype specific.

Then there is the Prototype object that contains a load of useful properties and functions. Those are used throughout the code. Very convenient, but it makes all that code dependent on that object. A lot of times, the offending line of code could easily be replaced by an only marginally longer line of code that avoided the dependency.

The same goes for a lot of functions that prototype adds to native objects. Such as Object.isFunction(), which just returns typeof object == “function”. Ok so your checks become a teeny bit shorter and more readable. But it makes your code dependent on a function that is only available in prototype. It’s the spirit of coding that prototype was built with: no duplicate code. That’s good to some degree, but if it comes at the expense of modularity, I choose modularity. It’s the old story of tight cohesion, loose coupling. Prototype is tightly cohesive as a whole. I think they should have separated the code more into modules and introduce loose coupling between the modules. As it stands now, it’s monolithic.

And this monolithicness seems to be contageous. Code gets infected by it. Hey if you want to use function A from prototype, you need to include all of it, so you get function B for free as well. And since it’s there.. why not use it, right? And then, if your code is useful, why not include it right into prototype? This way, the framework never stops growing…

Prototype viral? Well that may be pushing it, but just read this article about pimping some code for inclusion into prototype that I think illustrates what I’m saying here, and draw your own conclusions.

I told you prototype inspired me. It was inspiring to see how much you can bend javascript to perform the way you want it. And when I realized it was monolithic, it inspired me to create a solution: Modular javascript with Packages JS.

I’ve given up on trying to make protoype modular. It’s just too interwoven for me to get any joy out of doing that. So instead I’m trying to build up my own personal framework of scripts I like using Packages JS. Give it a try!