JS Frameworks

[Colin Clark]

Hi Eli,

I've been slow to respond to this post, and we've had a few 
conversations in other contexts since then, but I thought it might be 
worthwhile to respond on-list as well.

Eli Cochran wrote:
> I'll raise my hand and /volunteer/ to join in the effort. I have a fair 
> amount of experience working in jQuery and I'm open to picking up 
> another framework as well (although I'm pretty fond of what I know... 
> <indicating a bit of prejudicial preference>) 

This is great! I know there are others who have been working with jQuery 
and will be interested in helping to implement a version of Reorderer 
(Josh Ryan and AZ!) in it. We're not quite there yet, however.

In the meantime, there are a few of areas where you can get involved now:

1. Helping to make improvements and fixing bugs to the current Lightbox, 
all of which are documented in Fluid's issue tracker under the 
"Lightbox" component:
http://issues.fluidproject.org/

2. Adding any remaining ARIA drag-and-drop markup to Lightbox's HTML 
template and testing its behaviour with screen readers.

3. Working on a test plan for doing user testing of the Lightbox.

4. Merging the Fluid branch of Gallery back into the UCB version. Or 
more accurately, replacing the old version with our branch. This may 
include fixing a few minor bugs in the slideshow JavaScript as well.

> Since we're using this exercise to evaluate different frameworks I 
> assume that the intention is to create framework specific versions of 
> the component as opposed to trying to develop framework agnostic 
> version. I only ask because I've been very impressed with the EXT 
> component library (http://extjs.com/) which has built an abstraction 
> layer in order to allow their components to work under under four 
> different frameworks: jQuery, Prototype, YUI, and their own EXT 
> framework. It's an interesting approach, and it seems to work very well 
> for them. But I have no idea how much work it is for them to pull this 
> off or what they lose by not plugging into the framework directly. 

This is an interesting question. I know people have different opinions 
about what toolkits we should use and even the possibility of supporting 
multiple toolkits. Here's my thinking about the issue:

We need to be very careful about mixing and matching different DHTML 
toolkits, particularly when it comes to user-facing widgets and 
interactions. The very real risk is that there are subtle differences in 
the behaviour of the toolkits that will totally destroy the effect of 
interaction consistency that Fluid is striving to offer. This is a bad 
thing.

So while I can imagine using aspects of several toolkits for low-level 
utilities and libraries, the reality in my mind is that we're going to 
have to be very careful about choosing a single toolkit for any 
user-facing widgets that we use. At the moment, Dojo is way ahead of the 
rest in terms of accessibility. Implementing the Reorderer in several 
toolkits--which we will take a stab at during the Fluid summit--will 
provide us with some common ground on which to compare them.

Here's a synthesis of a months-old thread now on Fluid work of the 
various criteria we need to keep an eye on when comparing toolkits:

http://wiki.fluidproject.org/display/fluid/Criteria+for+Selecting+a+DHTML+Toolkit

Colin


-- 
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org