What’s wrong with jQuery UI?

In overall, jQuery and jQuery UI are really great. As for the former, and speaking purely in subjective terms, it’s the best thing that has happened to the web. But with great power comes great responsibility, so this post is about where jQuery UI team is making a mess.

First let’s talk about release cycle – it’s been almost two years since they announced the development of version 1.9, which would come with such a great tools as a menu and tooltip, but still no select-box (although the button element already can serve as a radio/checkbox replacement) . So for me it looks like the development is quite chaotical.

My view on a UI design in OOP language.

OOP is great to build UIs, becouse of all the “objects” and “inheritances”. I’ve done a few UI frameworks in my days (mostly for some closed source projects, where big and blatant frameworks would kill the performance).

First you look at the language or system where you implement the UI – is it built with a renderer or do you have to render every object your self with some low level APIs. For example Flash has a great starting point – the Sprite object (as is C#/.NETs UserControl), it has a graphics object which can do drawing and Flash it self is all about rendering. On the other hand there is C++, which by it self does not do any rendering at all – you have to use some libraries (think Cairo or GDI) which interact with a graphics adapter. JavaScript with HTML and CSS is more like a Flash – it’s all about visual presentation and dynamic interaction. So your starting point is all about positioning.

My Flash UI library has a starting point which extends Sprite and overrides all the width, height and scale properties, so that Flash does not stretch my inner workings, but x and y coordinates are left as is for native positioning.

Next you think about the simplest UI object that could be used as a graphical base for any object you need. This way you extend the object tree up to the most complex graphical object possible. In my UI library it’s a UIPanel object, which extends UIObject and simply introduces things like background and border and padding properties. And so the chain goes up to UILabel, that adds a TextField object and formating options. Then you have a choice – weather you can extend UIButton over UILabel, making a “is a” inheritance, or use UILable inside a UIButton (extended over UIPanel) making a “has a” inheritance. And so on the story goes until you have UIDataGrid or UIDialog objects.

jQuery UI – the chaos I see

When jQuery UI was first released – I was really happy to see decent datepicker and dialog, but these where the only decent widgets I could (and I wanted to) have in use. Later on came the autocomplete (long requested feature), now there is a menu widget coming.

Do you see the pattern? It’s going all the way backwards – they started with a most complicated thing (date picker and a modal dialog with dragging functionality), but the more basic things like menu are coming later on. What about code repetition? What about the size of the library? This approach might be a performance related decision, but it does not help the project to grow. If you look around on Google – how many user made widgets there are? Very few! There are some commercial ones that just parasite on the flaws and the slow pace of jQuery UI development.

Ok now, inheritance in Javascript. It’s messy, it’s possible, but it’s not what you’d expect from standard OOP language, because it’s not. You can’t have protected methods and members and at any point your public method can be overwritten without notice. But that’s also a good thing as it gives great versatility and possibilities which where not possible in the languages mentioned before (except for a classical Class extends BaseClass and standard method overrides). But it does not mean that you can not have a “has a” inheritance for your objects.

Possibilities in parralel universe

Let’s say jQueryUI team had made a panel widget – you just simply grab any block element and create it as a panel as this:

$( "div" ).panel({
  floating : false,
  width : "auto",
  height : "auto",
  modal : false
});

It’s just a box with rounded corners and all the contents stay within it and are styled with jQueryUI CSS framework (which by the way is pretty-well thought out and simple). Great for tooltips, menus, dialogs, drop-downs etc.

Now the building process can start. Brick by brick and the house is on the way:

1. They’ve built a button widget – which is as good as it is now, it just styles any button or input element or a label for checboxes and radio buttons and it looks like a button – how simple can you be (by the way in our reality this feature was again – after more complex dialog and date picker);
2. Next up a menu – this widget just utilizes panel and button elements creating a list of buttons and adding some interaction with sub-menus;
3. Toolbar – it’s just a simple menu with buttons – basically the same thing only it might have it’s own style.
4. Going forward – input field – nothing to see here, just a CSS styled input field that conforms with the overall UI style, but it’s helpful to have an option to just call $( “input” ).input();
5. And here we are at the candy shop – autocomplete and drop-down select – they both are basically extending menu with some logic of their own. Autocomplete could even be used in the input widget as an option like $( “input” ).input( { autocomplete : { … autocomplete options … } } );
6. Dialog itself is just a panel with a titlebar and some buttons at the bottom as a toolbar widget.
7. Datepicker, timepicker, colorpicker, *picker – they all are panel or even dialog widgets and buttons with some custom bussiness logic on top;
8. And so on it all goes to the very top of UI chain, creating DataGrids and Trees and Tables etc.

Conclusion

I wish the guy’s working with jQueryUI would read this. I know they are doing hard work, and some of them even spending their free time on this project. I’m really grateful to them for the job they’ve done, but maybe my little cry could help to build version 2.0 with a better extensibilty in mind.