Thursday, October 16th, 2008

OSGI and JavaScript; Frameworks and building blocks for Ajax apps

Category: Dojo

Bill Higgins of IBM Rational has written up some thoughts on componentization and packaging for Ajax applications based on work that his team did on the Rational Jazz platform.

Some of what he built was:

  • A nice component model based on OSGi bundles and the Dojo module system
  • Request-time “building” of many fine-grained JavaScript files into monolithic files for faster download based on the introspected relationships between the files – i.e. no developer effort required for fast code loading other than writing good code
  • Making a subset of the Eclipse extension registry available in the web page and queryable via JavaScript APIs modeled off of the org.eclipse.core.runtime extension registry Java APIs, allowing for open-ended extensibility using the Eclipse extensibility model
  • A simple framework for demarcating UI states that made the back button, history, and page titles work seamlessly within the Ajax page, even when a user gesture resulted in crossing a component boundary (e.g. loading and displaying a new virtual “page” from a different component)
  • Dynamic, transparent loading of missing code in response to a user gesture that required it

He then goes on to explain the architecture of reusable building blocks, and a realization:

My recent realization (which seems obvious in hindsight) is that the useful functionality provided by frameworks and libraries need not be mutually exclusive. For instance, in our Ajax framework’s dynamic build system, rather than requiring applications to run within our framework to enjoy this capability, we could have created a simple callable library to perform dynamic optimization on a set of files, and then created a framework that simply used this same library.

Over the past month or so we’ve been refactoring our Ajax framework to extract the useful building blocks into simple callable libraries and making the framework proper smaller by delegating to these libraries. We’ve done this in the hopes that our code will be useful to other IBM teams but as a result of the exercise, we’ve gained a deeper knowledge of our software and the software’s quality has improved as we’ve decoupled the framework aspects from the building blocks aspects.

Going forward, it’s my intention that our team will generally start with building blocks first and then consider if we should provide some higher-level framework that uses these building blocks. I only wish we had taken this approach from the beginning but you know, live and learn.

Any kind of heavy packaging systems haven’t done hugely well in the Ajax community as a-whole, but there is a huge problem with components and being able to reuse them. The fact that someone builds a great jQuery plugin, that then gets ported to Prototype and Dojo and …. is frustrating (one example, it happens N times, with the original framework changing).

Posted by Dion Almaer at 7:23 am
7 Comments

+++--
3.9 rating from 19 votes

7 Comments »

Comments feed TrackBack URI

“no developer effort required for fast code loading other than writing good code”
.
I’m curious to what is meant by “good code” and what that is supposed to be a synonym for.

Comment by TNO — October 16, 2008

Hahaha, you got me on that one. I wrote that line while flailing my arms wildly.

Seriously though, my point was that my team creates infrastructure and we use Dojo infrastructure that deals with all the low-level gunk (componentization, extensibility, code-loading optimization, cross-browser normalization, etc.) so that application developers (e.g. the people creating the Jazz bug tracking UI) *only* have to write good application code. Writing good application code is in itself difficult, but it’s easier than having to write good application code *and* dealing with all of the gorpy infrastructure issues.

Comment by BillHiggins — October 16, 2008

“…in the Ajax community as a-whole…”

Hey! What did you call us? ;)

Comment by smith — October 16, 2008

Ugh, here’s one vote for no more Javascript packing by server side Js packaging frameworks. I’m forced to hack Richfaces internals currently in order to get it to calculate offsets currently. Thank god I can replace it easily with an implementation that kicks ass (thanks Jquery!)

Comment by ilazarte — October 16, 2008

@ilazarte: The point of that entry was that occasionally someone creates some useful functionality and if they do so, it shouldn’t be exclusively available via a framework. You should only have to use a framework if you *really* want to live within its world, not just to get at some useful capabilities. I think via your observation on Richfaces, you’re making my point.

Comment by BillHiggins — October 16, 2008

I tend to agree with ialzarte here. Somehow server-side packaging doesn’t sound very attractive to me. I am very interested in the OSGI for javascript stuff though. Javascript really is in need of some coordination of all the scripts that live on the page.

The trend I see now is that people want to create stand-alone scripts and to achieve it they just duplicate code from other scripts to avoid having to tell users of their script to make sure that script xyz is also included in the page. Thats a bit of a high price to pay in terms of maintenance I thnk.

I have been working on a system that does packaging on the client-side with no server-side code needed. The benefits to me are that i can even run the scripts from a file:// url to my local disk. I don’t even need to run a webserver at all. :)

Comment by StijnDeWitt — January 13, 2010

I just wanted to let you know that the first release candidate of my system (see previous post) “Packages JS” is available for download. I would be interested in feedback from other developers, so take it for a spin and let me know what you think:

http://packagesinjavascript.wordpress.com/

Comment by StijnDeWitt — April 9, 2010

Leave a comment

You must be logged in to post a comment.