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.


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.

Join the Conversation


  1. GusC,
    I’m not a expert, but I think you may have misunderstood one of the goals of jQuery UI. You seem to be looking for a web application (widget) framework, but as far as I can tell jQuery UI is just a way to enhance the functionality of web pages (progressive enhancement). One difference is, with a web application framework the GUI can be created almost completely from (JavaScript) code, while with jQuery an existing web page can be improved so it has more (or easier to use) features. A second difference would be that you could build up a widget framework from a single base component, but a library supporting progressive enhancement must extend (or read and replace on the fly) a large range of DOM elements.

    1. I understand the goals quite well, and I’m fine with them. This topic is more about the way those goals could be reached. My opinion here is that creating building blocks and great ecosystem would attract more developers, thus speeding up the development cycle, thus extending the jQuery’s native UI library more and more. And as we can see the project itself is struggling. It could have been a small step for a man and a huge leap for the web. Although we haven’t lost anything yet, these ideas could be used for next major iteration of the project.

      1. rolf, i thought absolutely the same thing as adam.

        here’s the thing: just start your own ui library, trust me, if it works ppl are gonna love it.

  2. You need learn OOP Javascript and an OOP/widget based framework like Dojo Toolkit or ExtJS

    1. It’s almost impossible for a normal developer to do OOP with JavaScript. JavaScript is mainly a functional language that makes OOP very painful.

      As for the suggestion to use ExtJS. That’s a bad idea for most companies, because ExtJS uses the business unfriendly GPL3 license. That license is so bad, even Linus Torvalds won’t use it.

      This whole article highlights the mess web development is in because of JavaScript. We need a true OO alternative to JavaScript. Fortunately, Google is working on such a language: Dart.


      A stable version of Dart is expected before the end of 2012. This is sooner than the long delayed next update to ECMA JavaScript.

      1. Dojo Toolkit is open, and implements class based API (OOP) for logic and widgets, Prototype too. ExtJS is only another option.

        Stop creating new languages for replace javascript, is waste of time.

    2. Well Dojo Toolkit and ExtJS aren’t really a topic about jQuery, are they? And, Yes, ExtJS has a license issue, as i’m working mostly on commercial projects, not open-source.

      So let’s stick to the topic about jQuery’s world.

Leave a comment

Your email address will not be published.