HTML5 UI Frameworks [closed]

There is so much in your question, that the answer won't be easy and won't be definite at all. It'll also be very opinionated. Looking at the list of framework you brought, I see very different things that are hardly comparable with each other. I'll try to group them somehow and add more frameworks to the list.

The main question here is not the pros and cons of a particular framework. The main question is: how much do you want? Did you really mean an application like Gmail or Grooveshark? Or did you mean something like Stackoverflow - a dynamic and not at all simple, but still a website. Let's consider all of these options.

Perhaps, you just want to enhance your website with some widgets, like tabs, dialogs, some draggable/droppable elements, text editing, etc and you are not willing to change your development model. I mean, you use your favourite Java/PHP/Ruby and do not wish to write the a lot of your app's logics and behaviour in JavaScript. In this case, jQuery-based plugin-like solutions will do for you, particularly, jQuery UI and jQuery Mobile.

jQuery widgets follow its plugin system. This generally means, that they are extremely easy to use. In order to create a button, you write:

$('#myButton').button();

Now if you want to disable it, you call a method using following pattern:

$('#myButton').button('disable');

And getting or setting values, e.g. on slider or datepicker, looks like this:

$('#mySlider').slider('value');
$('#mySlider').slider('value', 42);

As you see, jQuery-based solutions have no model. All your data is kept in DOM and is obtained via quirky method calls. If you need to dynamicly process your data, e.g. do some complex validations, load something in background, filter or sort, then you see that this will soon get messy. By the way, this is the problem why jQuery UI team has not provided a grid control yet - they can't do it without a model. In jQuery Mobile you get a nice mobile UI by the means of simple markup, but there is no official way to pass data between pages.

Summing this up: if you have a multi-page website, if you POST your forms, then use jQuery UI or a lighter solution like Twitter Bootstrap.

Perhaps, you want to build something more complex, more application-like (a single-page application?). You know you will need to work with data on client side. What are your options then?

You can use one of many JavaScript frameworks that provide you with models, data binding and probably other means of creating web apps and integrate them with why not jQuery UI. Or you can use a more complete framework like Kendo or Wijmo or jqWidgets. These frameworks rely on jQuery (Wijmo relies on jQuery UI) and provide additional means of data manipulation. They have a data models. Kendo implements its own solution (I think), while Wijmo and jqWidgets integrate with the popular Knockout JS.

So Kendo and Wijmo belong to the group of frameworks that provide both widgets/controls and some backing model. There are other frameworks like these, that are not jQuery-based, e.g. Dojo Toolkit. Add some dynamic data loading and you'll get a somewhat complex web application. What more can you wish?

Actually, the most important thing is forgotten - how do you structure (organize) you application? If you try to build a single-page app that communicates with server in RESTful way, then you will soon get into a mess if your application has no architecture. The features that are usually required for this are some concern separation (MVC, MVVM), templating, routing and module management. This is where SproutCore and Sencha appear. They provide a comprehensive solution for building web apps, where widgets are just a small part.

It may seem like SproutCore and Sencha are the winners here, because they are the most complete solutions that include both UI and the business logics and also structure your application. Despite all the pros, there are some cons. Some say they are too heavyweight or will require to adhere to their development model, which you might not like. For example, in Sencha you describe your GUI in JavaScript and use Sencha's type system. This adds a sort of heavy feeling that there are abstractions and wrappers, while you really like the ease of HTML, CSS and vanilla JavaScript.

But this is not the only way. The power of web is that there are many-many frameworks, libraries, tools out there, smaller and bigger ones, that will help you craft your app the way you like it. For example, consider AngularJS. It doesn't provide a set of controls itself, but combined with Twitter Bootstrap becomes a complete solution for RIA. Or, for example, look at EmberJS, a more lightweight framework from the guy who created the heavyweight SproutCore. It doesn't provide you with a set of widgets either, but is, in my opinion, a very good base for an app.

So here is my final thought instead of conclusion. All those framework usually show you their widget set, nicely looking themes and the other visual stuff. But what really matters is how you will actually develop you application, how you will structure it, where you will implement your logic. Get to know what the framework provides and think through whether you can substitute what's missing.

Infeligo's answer is top notch. My experience may be of interest to some. I use Ruby on Rails as my server platform where the bulk of my business logic resides.

At the front end I use dHTMLX which is a JS library of 'objects' the most powerful of which is their grid object. Most of my apps have business/accounting information processing/display requirements and the grid object is my mainstay there. However their object set is comprehensive including the ability to create additional 'windows' within the single application to provide a MDI type interface to the end user. I typically have a login form which when successfully applied opens a single HTML page with a menu at the top. Based on selection from the menu new windows are opened and closed to display / manipulate information. These windows are within the scope of the single HTML page.

All the objects have very good events associated with them and I do quite a bit of validation at the front end using these events. However I usually duplicate all validation of data within the Rails Model as well. It's additional work but I'm just extra cautious. There are also a number of abstract objects that help to connect data between the front end visual objects e.g. grid and back end server. Most of the data connections can be done using XML or JSON. I use XML over JSON simply because of my experience with that structure and the fact that Rails provides a decent XML builder. So in my case I rarely use any Rails based views as all of my visual objects come from dHTMLX.

The other thing I like about dHTMLX is the speed of their objects. For example the grid object will quite easily handle 10,000+ rows at very acceptable speeds.

The BIG DOWNSIDE of the suite is it's documentation. The company is an eastern European developer and therefore it is often difficult to understand exactly what their documentation means. Also their documentation tends not to document everything completely and so a lot of time is wasted in trial and error type learning.

Hope this helps