I’d like to introduce a new JavaScript/Ajax framework that my company is creating. We’re calling it Protowidget because it uses Prototype and does things with widgets. And yes, we know it’s 2006 and this is something like the 800th Ajax framework released this year. We think this one is new and different, though (of course, every parent thinks their baby is beautiful). It is being created out of real needs while building applications for customers and is helping us create better stuff. Please note that this is just a preview. Not everything works like it should or has been tested to the degree we would like. In particular, under certain circumstances, the library leaks memory. We know what needs to change to fix this but haven’t gotten to it yet.

Motivation

The best tools are born out of pain. With regard to existing Ajax tools, here is a brief list of some of the pain we felt and wanted to address:

• ID-madness: Some frameworks (ie. Dojo) attempt to avoid this, but most make the primary coupling point between JavaScript and HTML be the ID attribute. While many have shown this to work, it is somewhat offensive to have only one flat namespace. This becomes an especial problem when trying to create repeating sections or scoped, re-usable components. Since the namespace is flat, it also causes problems when one component needs to logically interact with others.
• Non-standard UI construction: At the end of the day, HTML+CSS is a pretty good tool for laying out web-based UIs. We can certainly come up with better representations, but they are rarely as rich and they are typically not designer friendly. Despite a lot of other great ideas, I consider this to be OpenLaszlo’s primary failing. Other frameworks which take the Swing-esque approach of coding the UI programatically by assembling objects are even weaker.
• No client side model: Years ago someone co-opted the long standing MVC design pattern and claimed that having servlets and views somehow conformed to the pattern. Maybe it technically does, but it is certainly not in the spirit of MVC as seen in real client-side apps. Today, we have an interesting inversion going on where most people think that the web-MVC (type II or whatever) pattern is classical-MVC. We need to be applying some classical-MVC principles to our client-side interfaces. Otherwise, we will end up with as much spaghetti as can be found in an old-school VB6 app. OpenLaszlo and Flex with their pervasive property bindings provide the building blocks for this type of development. Few others do.
• Separating form from function: This is the holy grail, and likely no tool will ever get 100% there. The idea is that the visual layout and characteristics should be specified out-of-band from the code that manipulates it. A good framework should have well-defined intersection points where the visual bits mix and interact with the programmatic bits.

In the end, we really liked the simplicity of Prototype, the widgets/templates from Dojo and the event-based property binding support from OpenLaszlo/Flex.

Example

Here is a link to one of the Protowidget test pages. It’s not much to look at and certainly doesn’t do anything that can’t be done elsewhere. The magic is in how it is done, and that is what the rest of this post w