JavaScript Toolkits Summit Discussion

Owned by Joseph Scheuhammer
Last updated: Sept 24, 2007Version comment
7 min read

Goals

While the ultimate goal is to decide on a toolkit (or toolkits), there should be a set of guidlelines upon which to make that decision. There needs to be a discussion of the various issues and of the criteria that guide the choice; to determine which issues are most relevant and of highest priority. With these in hand, the community can meaningfully evaluate each toolkit.

The need for the discussion is because the list of criteria is long, ranging from accessibility issues, to licensing, to technical issues such as ease of use from a programming point of view. Are all of these considerations of equal value? Are some more important that others? Which ones?

While thinking about the issues and criteria, it is expected that the discussion will bleed into discussing the merits of various toolkits themselves. That's not entirely a bad thing provided that it leads to a good approach to evaluation.

Finally, it would be useful during the summit to start the evaluation by actually implementing a component in at least one other toolkit. One can't really get a sense of a toolkit until one gets one's hands dirty with it. The Reorderer has been implemented using dojo. What would it be like using jQuery? Mochikit? Prototype?

Criteria vs. Issues

The evaluation of toolkits can be broken into two categories: issues and criteria.

An example of an issue is whether to allow/promote/avoid the use of more than one toolkit. Is this feasible? Desirable? Undesirable? And, what are the set of related issues? Licensing, for example, is a related issue. Can code from two different toolkits legally be used together?

A criterion is exemplified by "accessibility". To be extreme, a toolkit should be shunned if it makes it impossible to have an accessible UI. That's not likely; rather, the question becomes more of how difficult it is to implement accessible user interfaces in that toolkit.

Motivation

Why choose a JavaScript toolkit? What do they do for us that we couldn't do ourselves?

All are advertised as normalizing or compensating for different implementation of JavaScript within the different browsers. In particular they facilitate:

  • DOM access and manipulation
  • CSS access and manipulation
  • Event handling
  • AJAX

The Candidates

Note that not all define components or "widgets". Mochikit, Prototype, and jQuery (core) all simply define cross-browser support for DOM, AJAX, CSS, and Event handling. The latter is, however, relevant to user interface, since events capture user gestures.

Factors

  • Browser support
  • Use mulitple toolkits
    • Licensing
    • To what extent? ("core" vs. core+widgets). e.g. jQuery vs. jQuery+jQueryUI.
    • Do the toolkits play nice with each other?
    • How much more download overhead does this entail?
    • Concerns about different look-and-feels, and user experience consistency.
  • Client/Server division of labour.
  • Accessibility
  • Plays nice with server side technologies (e.g., RSF).
  • Technical
    • Ease of use (good documentation, tutorials, good packaging, easy to debug).
    • Download overhead.
      • jQuery core is quite small (v2.1 is 77.4kb uncompressed, all in one file).

Browser support

  • dojo: Latest Safari (2.0.x), Firefox 1.0+, IE 6+, Latest Opera (9+).
  • jQuery/jQueryUI: Safari 2+, Firefox 1.5+, IE 6+, Opera 9+.
  • Mochikit: Safari 2.0.2, Firefox 1.0.7, Firefox 1.5b2, IE 6, Opera 8.5.
  • Prototype: Various claims for cross-browser support for various features of Prototype, but no statement as which browsers/versions are supported.
    • script.aculo.us: Safari 1.2+, Firefox 1.0+, IE6+, Opera 9.
  • YUI: "Graded Browser Support":
    • YUI provides a table that lists various browsers, operating systems, and versions thereof, and defines what they support for each.
    • Tantamount to: Safari 2.0+/Mac 10.4, Firefox 2+, IE 6+/Win XP, Opera 9.0+/Win98-WinVista, Mac 10.3.
  • Ext: Safari 2+, Firefox 1.5+, IE 6+, Opera 9+

Overall, it appears that all the toolkits will meet Fluid's needs with respect to browser support.

Licensing

Happily, licensing is not an issue, and we can dispense with it quickly. Nonetheless, in order that is not a mystery, here is how it could be a problem from two perspectives:

  1. Compatible with other project licences (e.g., Sakai, uPortal, Moodle). The toolkit's licence must be compatible with ECL and BSD.
  2. Compatible with each other's licence (e.g., dojo combined with Ext). This is required if multiple toolkits are used.

The candidate toolkits are dual-licensed for the most part, and, in all cases, one of the licences is either, BSD, MIT, or LGPL. All three allow linking with any other code.

  • dojo: BSD licence or Academic Free License version 2.1
  • YUI: BSD licence.
  • jQuery/jQueryUI: MIT or GPLv2
  • Mochikit: MIT or Academic Free License v. 2.1
  • Prototype/script.aculo.us: MIT
  • Ext: Commercial xor LGPLv3*

*At this point, Sakai's licensing compatibility documentation lists only LGPLv2.1 as a compatible licence.  That is probably because LGPLv3 was just published in June, 2007. What is/will be Sakai's position on LGPLv3 (to the extent that Fluid wishes to use Ext)?

Client/server division of labour

This division of labour is also known as markup driven vs. data driven, or, perhaps, static vs. dynamic. "Markup driven" means that the server ships the majority of the markup (html, css, and javascript) to the client. This is how the Fluid lightbox works. See, for example, Markup-Driven Components.

The data driven view is that a significant portion of the markup does not exist on the server; rather, the server inserts javascript that is run on the client at some well defined time, such as "onpageload". The javascript generates the markup on the client. An extreme example of this would be a page whose <body> element contained only a script tag:

...
<body>
  <script>makePage();</script>
</body>
...

The above tagging is an exaggeration to make a point. In reality, no toolkit is this extreme.

In this regard, dojo leans in the direction of a larger amount of page construction effected on the client.

Which is better? Or, what is the correct point to divide the labour? An argument is that servers are good at delivering markup, so why not use this tried and true methodology? What, on the other hand, are the benefits of markup generation on the client?

Accessibility

  • Components are easily made accessible
  • ARIA Support

Generally speaking, if a toolkit is not "accessible", then it will not be used by Fluid. But, what does that mean, exactly?

First, "accessible" entails that the toolkit makes it easy to build accessible components. For example, the components are either keyboard accessible out-of-the-box, or are easily made so by adding such things as key board support.

Similarly, the toolkit either has built-in ARIA support, or ARIA markup is easily added.

With respect to this criterion, dojo is the clear winner. Much effort has been expended to make dojo and its widget set accessible and ARIA-ready.

However, consider how Fluid's Reorderer has been implemented. The Reorderer is derived from the base dojo "widget" class. Nonetheless:

  • the keyboard handling was done "by hand" within the Reorderer itself. Admittedly, it was done via 'dojo.connect()', but it could have just as easily been done via 'MochiKit.Signal.connect()'.
  • the ARIA markup was added to the associated HTML also "by hand".

This begs the question: what did the Reorderer get "for free" by basing itself on dojo? It's possible we did something wrong; that is, could we have gotten more out of dojo by coding the Reorderer differently? Is that desirable? This issue possibly relates to the division of labour issue noted above, in that if we had used dojo in a different way, then we would have a11y and ARIA for free, but only by generating a larget proportion of the Lightbox html on the client, not the server.

Plays nice with the server side

One of the reasons Fluid chose to employ AJAX was to avoid platform dependence. That is, AJAX is independent of the context running on the server, be it servlets, php, or otherwise.

In theory, then, Fluid components should work fine with any server side technology. However, that's just a theory.

What are the issues with respect to?:

  • use with RSF, or other presentation framework.
  • use with Sakai.
  • use with uPortal, or other portlet environment.
  • use with Moodle.
    • does php pose any additional problems?

Plays nice with other toolkits

  • Mochkikit detects the presence of dojo, and uses
    • dojo.provide() to register the Mochikit modules
    • dojo.require() to load other Mochikit modules
  • Jonathan Bond-Caron's effort to integrate dojo, jQuery, and Ext.
  • YUI: based on the Bond-Caron's efforts, jburke of dojo has done preliminary work on loading YUI using the dojo loader, calling it "Yojo".
  • jQuery: advertised as usable with other libraries, see Using jQuery with Other Libraries
  • Ext: Early versions of Ext required that other base libraries be included, one of YUI, jQuery, or Prototype/Script.aculo.us. The latest version of Ext no longer requires this, but allows one to do so. See the Ext FAQ
  • Caveat: Mochikit, jQuery, and Prototype all define a $() function that requires minor finesse to avoid a conflict.

There is some effort to allow the toolkits to integrate with each other. Note, however, that the effort is a technical one (going out on a limb here). Another issue is whether it is a good idea, from a UX point of view, to mix user interface elements from multiple tool kits?

Bond-Caron thinks so - quote: "Why should I have to choose one framework over another when all I want is nice widget X from framework A and nice widget Y from framework B?" He hopes for some kind of convergence: "There's any amazing amount of (free) time that is wasted developing 'competing' widgets while that time could be spent developing open-source components that are re-usable for other toolkits."

Ease of use: Documentation and testing

The following lists the main site for the given toolkit's documentation and tutorial pages.  It also lists the toolkit's unit tests, some of which can be run immediately in a browser.  This provides a quick way to see if a toolkit works with a given browser and operating system.

Also, these links should provide a useful background for porting the Reorderer to other toolkits.