Javascript Toolkits

Like alot of people, I'm really impressed with google's applications. They have created web applications that behave alot like desktop ones. Core to this is the javascript tricks that hold it together.

In the past few years I've been building applications using XUL, that provides a similar set of functionality, and is pretty fast to develop with. However we have run into a few issues

• Its not cross browser, which is ok for intranet style applications, obviously is a little problematic for public internet ones.
• After many projects we began to see that dialog, modal prompts where better for user input, as the prevent the user modifying the application state while entering data, along with making it less likely to forget to press the submit button. Recent builds of Firefox have disabled the modal feature of popup window, and along with the noticeable speed penalty on most modern operating systems for opening new windows, these issues begins to dig into the benefits of this approach.
• WYSIWG editors are still not easy and simple to use...
  

Since one of my pet projects, an online accounting package needed a bit of sprucing up, and testing my home grown JavaScript code on IE is such a nightmare, I started looking at JavaScript toolkits.

The biggy from countless blog posts recently has been YUI, Yahoo's interface toolkit. I spent quite a while looking at this, the website for it is very complete, along with a comprehensive set of widgets. There was alot too like about it, however as I dug deeper, I began to dislike some of the things i saw.

• silly things like all the JavaScript code libraries appeared to use a weird, double lined coding standard.yes I know it's silly, but it makes a difference when you read code to see something that odd.
• (from what i remember ), alot of those set*, get* methods.
• almost all the demos appeared to create the widgets in JavaScript and using js associative arrays to configure the widgets , rather than using extra attributes on existing html tags, and doing some kind auto conversion.
• the constructors did some strange namespace hack.

In general, it looked like using the widgets was very un-javascripty.

So after some consideration, I started looking for alternatives. The first I came across was prototype which looked more like someone rewriting JavaScript than a toolkit, then i came across dojo,
which looked alot more promising. The website has focused on the demos, which is pretty good. There is documentation (i'll talk about that more later)

Best of all it works alot more like the widget based JavaScript code i've written. it focuses on converting existing dull html widgets into super js enabled ones at the flip of a switch.

Concept

Conceptially, as show on the demo's, takes the HTML page, and when the library is loaded, it hooks into the onload method of the page, and looks for all the widgets with the attribute dojotype="Select" or similar, and has a javascript class to handle each "dojotype".

The dojo widget class takes a look at the attributes, and sets the javascript object properties to match those HTML attributes (hence behaving like the configuration for the widget). Then it builds the new widget based on those attributes, and merges it in with a template file (which is in dojo/src/widgets/templates/*) or uses a text attribute of the javascript object for the template. It then adds all the behaviour and just makes stuff happen.

Features

Dojo has all the basic features that you would expect from a javascript widget toolkit, dialogs, windows, autocompletion, clever select widgets and more. It also has quite a library of backend tools for formating dates, doing xmlhttprequests. and more. What is nice about this, is that these libraries are not forced on you, rather they are used by the widget libraries, and you dont really need to know about them, or learn them. And offer a gradual learning path. So when you are ready you can start diving in and seeing if they are usefull in other parts of your code.

Most of the really usefull stuff is in src/widgets/*

Flaws

Well, nothings ever perfect, and looking at the huge number of bugs in the dojo bugtracker, I suspect they developers are having difficulting keeping up with it's popularity.

There are a few design decisions that where annoying (although this has to be taken against the fact that the majority where excellent). The key ones being:

• CSS interaction, Widget's can load their own CSS from the template directory, This makes modifying the CSS for widget's rather difficult. (unless you treat the template directory as your own working space - or override it somehow). The more I worked with it, the more I thought it would be better to provide a generic CSS file that contains all the CSS needed for the widgets (or a file that @imports all the individual ones) , and force you to load it manually. - hence allowing you to replace the CSS quickly and simply. As often the dojo styling can conflict with any generic CSS that you may have already for your application.
  
  In addition, there are quite a few style="..." tags in the HTML templates used by the widgets, these should really have been moved into the CSS files, allowing more flexibility.
  

• Creating your own widgets. based on the dojo ones, It looks like a theroetically simple task, but an example in the demo's would probably help out alot (eg. a single file with an extended dojo widget example) - not a sexy demo, but would be really handy..

• Documentation of attributes. as I mentioned before, the two set's of documentation - API and Manual miss out on the esential part of dojo, the use of HTML attributes to change settings. This could probably be generated or displayed in the API manual but is missing.

• Missing widgets, or features lacking. There are many little things missing from dojo, that seem obvious, yet are not there (yet),

• Dialogs that are more complete, the basic dialog is very baren, having no OK/Cancel built in, and no styling that makes it look particularly sexy.
• No Basic Dialog set's like prompts, warnings etc. that just display messages or get simple user feedback
• Interaction of the button widget with things like wizards and dialogs - you would expect these to be used by default on the standard wizard, but the default is a rather poor looking button
• The great love of blue - the standard button widget uses rather a inelegant blue colour, a faded grey would probably be more neutral for generic applications.