HTML5 UI Frameworks

I found many HTML5 interface frameworks, for example:

I kind of overflowed again with a lot of resources. I looked at some of them, but almost everything seemed too slow and heavy.

I am a little confused about what I will learn. Each of their websites speaks of its product as if it were the best on the market. (obvious marketing strategies).

As a newbie in web application development and client-side JS, you guys, based on your experience, which you recommend for the rapid development of desktop web applications, given speed, widget collections, complexity, appearance, support, etc.

Which one do you recommend me to start studying?

I know that there can be many answers, and everyone may prefer different ones, but this could help me teach a little and have some critics of some of the most popular frameworks.

+53
user-interface html5 web-applications frameworks javascript-framework
Oct 18 '12 at 18:41
source share
2 answers

There is so much in your question that the answer will not be easy and will not be definite at all. It will also be very stubborn. Looking at the list of frames that you brought, I see very different things that are hardly comparable to each other. I will try to group them somehow and add additional frameworks to the list.

The main issue here is not the pros and cons of a particular structure. 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. Consider all of these options.

Perhaps you just want to improve your website with some widgets, such as tabs, dialogs, some drag / drop, text editing, etc., and you don’t want to change your development model. I mean, you use your favorite Java / PHP / Ruby and don't want to write a lot of application logic and behavior in JavaScript. In this case, you will use plug-in solutions based on jQuery, in particular jQuery UI and jQuery Mobile .

JQuery widgets follow its plugin system. This usually means that they are extremely easy to use. To create a button, you write:

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

Now, if you want to disable it, you call the method using the following template:

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

And getting or setting values, for example. on a slider or datepicker, it looks like this:

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

As you can see, jQuery-based solutions do not have a model. All your data is stored in the DOM and obtained using fancy method calls. If you need to dynamically process your data, for example. do some complex checks, load something in the background, filter or sort, then you see that it will soon become messy. By the way, this is the problem why the jQuery UI team has not yet provided grid control - they cannot do this without a model. In jQuery Mobile, you get a good mobile user interface with simple markup, but there is no official way to transfer data between pages.

To summarize: if you have a multi-page site, if you submit your forms, use the jQuery interface or a lighter solution like Twitter Bootstrap .

Perhaps you want to create something more complex, more applied (single-page application?). You know that you will need to work with data on the client side. What are your options?

You can use one of the many JavaScript frameworks that provide you with models, data binding, and possibly other tools for building web applications and integrating them with the non-jQuery UI for some reason. Or you can use a more complete structure like Kendo or Wijmo or jqWidgets . This framework relies on jQuery (Wijmo relies on the jQuery user interface) and provides additional data manipulation tools. They have data models. Kendo implements its own solution (I think), while Wijmo and jqWidgets integrate with the popular JS knockout.

So, Kendo and Wijmo belong to the group of frameworks that provide both widgets / controls and some support model. There are other structures like these that are not based on jQuery, for example. Dojo Toolkit . Add dynamic data loading and you will get a somewhat sophisticated web application. What more could you wish for?

Actually, the most important thing is forgotten - how do you structure your application? If you try to create a one-page application that interacts with the server using RESTful, then you will soon encounter a mess if your application does not have an architecture. Typically, this requires separation functions (MVC, MVVM), templates, routing, and module management. Here are SproutCore and Sencha . They provide a complete solution for creating web applications, where widgets are just a small part.

It might seem that SproutCore and Sencha are the winners here because they are the most complete solutions that include both the user interface and business logic, as well as structure your application. Despite all the pros, there are some disadvantages. Some say that they are too heavy or require you to stick to your development model, which you may not like. For example, in Sencha, you describe your GUI in JavaScript and use a system like Sencha. This adds some kind 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 the Internet is that there are many frameworks, libraries, tools, smaller and larger, that will help you create your application the way you like it. For example, consider AngularJS . It does not provide a set of controls on its own, but when combined with Twitter, Bootstrap becomes a complete solution for RIA. Or, for example, check out EmberJS , a lighter base from the guy who created the heavyweight SproutCore. It also does not provide you with a set of widgets, but, in my opinion, a very good base for the application.

So, here is my last thought, not a conclusion. All these frames usually show you their widget set, beautiful themes and other visual materials. But it’s really important how you actually develop your application, how you structure it, where you will implement your logic. Find out what the infrastructure provides and consider whether you can replace what is missing.

+128
Oct 18
source share

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 the JS library of "objects", the most powerful of which is their mesh object. Most of my applications have requirements for processing / displaying business / accounting information, and the grid object is my main component. However, their set of objects is comprehensive, including the ability to create additional “windows” in one application to provide an MDI type interface to the end user. Usually I have a login form that, when successfully applied, opens one HTML page with a menu at the top. Based on the selection from the menu, new windows open and close for displaying / managing information. These windows are within the same HTML page.

All objects have very good events associated with them, and I do quite a bit of checking on the front side using these events. However, I usually duplicate all data validation in the Rails model. This is extra work, but I'm just careful. There are also a number of abstract objects that help connect data between front-end visual objects, for example. network and back end server. Most data connections can be made using XML or JSON. I use XML on JSON simply because of my experience with this structure and the fact that Rails provides a decent XML constructor. Therefore, in my case, I rarely use any Rails-based views, since all my visual objects come from dHTMLX.

Another thing I like about dHTMLX is the speed of their objects. For example, a mesh object will easily process over 10,000 rows at very reasonable speeds.

BIG DOWNLOAD of the package is the documentation. The company is a developer in Eastern Europe, and therefore it is often difficult to understand what their documentation means. In addition, their documentation tends not to document everything completely, and therefore a lot of time is spent in the process of learning trial and error.

Hope this helps

+4
Jun 06 '13 at 12:53 on
source share



All Articles