Html HTML5 UI 框架

HTML5 UI Frameworks

提问by jviotti

I found lots of HTML5 UI frameworks over there, such as:

我在那里找到了很多 HTML5 UI 框架，例如：

• Kendo
• Wijmo
• jqWidgets
• Zebra
• Sencha
• SproutCore
• YUI
• XUI
• Shield UI

• 剑道
• 威摩
• 小部件
• 斑马
• 煎茶
• 芽芯
• 唯
• 许
• 盾牌界面

I'm kinda overwhelmed with again so much resources out there. Looked some of them, but almost all seemed like too slow and heavyweight.

这么多资源让我有点不知所措。看了其中一些，但几乎所有的看起来都太慢太重了。

I'm getting a bit confused about which one will I learn. Each of their websites talk about their product as if they were the best on the market. (obvious marketing strategies).

我对我将学习哪一个感到有些困惑。他们的每个网站都在谈论他们的产品，就好像他们是市场上最好的一样。（明显的营销策略）。

As a beginner on web apps development and client-side JS UI frameworks; you guys, based on your experience which one do you recommend for rapid desktop web apps development considering speed, widget collections, complexity, look n' feel, support, etc?

作为 Web 应用程序开发和客户端 JS UI 框架的初学者；你们，根据您的经验，考虑到速度、小部件集合、复杂性、外观、支持等，您推荐哪一种用于快速桌面 Web 应用程序开发？

Which one do you recommend me to start learning?

你推荐我开始学习哪一个？

I know there could be lots of answers and each one could prefer different ones, but this could help to guide me a little and have some critics of some of the most popular frameworks.

我知道可能有很多答案，每个人都可能更喜欢不同的答案，但这可能有助于指导我，并对一些最流行的框架提出一些批评。

回答by Infeligo

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.

这里的主要问题不是特定框架的优缺点。主要问题是：你想要多少？您真的指的是 Gmail 或 Grooveshark 之类的应用程序吗？或者你的意思是像 Stackoverflow 这样的东西——一个动态的，一点也不简单，但仍然是一个网站。让我们考虑所有这些选项。

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 UIand jQuery Mobile.

也许，您只是想使用一些小部件来增强您的网站，例如选项卡、对话框、一些可拖放元素、文本编辑等，而您不愿意改变您的开发模型。我的意思是，您使用您最喜欢的 Java/PHP/Ruby，并且不希望用 JavaScript 编写大量应用程序的逻辑和行为。在这种情况下，基于 jQuery 的类似插件的解决方案将适合您，尤其是jQuery UI和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:

jQuery 小部件遵循其插件系统。这通常意味着它们非常易于使用。为了创建一个按钮，你写：

$('#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.

如您所见，基于 jQuery 的解决方案没有模型。您的所有数据都保存在 DOM 中，并通过古怪的方法调用获得。如果您需要动态处理您的数据，例如进行一些复杂的验证、在后台加载某些内容、过滤或排序，那么您会发现这很快就会变得混乱。顺便说一下，这就是为什么 jQuery UI 团队还没有提供网格控件的问题——他们不能没有模型。在 jQuery Mobile 中，您可以通过简单的标记获得漂亮的移动 UI，但没有官方的方法在页面之间传递数据。

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.

总结一下：如果你有一个多页面的网站，如果你发布你的表单，那么使用 jQuery UI 或更轻的解决方案，比如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 Kendoor Wijmoor 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.

您可以使用许多 JavaScript 框架中的一种，这些框架为您提供模型、数据绑定和其他创建 Web 应用程序的方法，并将它们与 jQuery UI 集成。或者您可以使用更完整的框架，如Kendo或Wijmo或jqWidgets。这些框架依赖于 jQuery（Wijmo 依赖于 jQuery UI）并提供额外的数据操作手段。他们有一个数据模型。Kendo 实现了自己的解决方案（我认为），而 Wijmo 和 jqWidgets 与流行的 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?

因此，Kendo 和 Wijmo 属于提供小部件/控件和一些支持模型的框架组。还有其他类似的框架，它们不是基于 jQuery 的，例如Dojo Toolkit。添加一些动态数据加载，您将得到一个有点复杂的 Web 应用程序。你还能希望什么？

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 SproutCoreand Senchaappear. They provide a comprehensive solution for building web apps, where widgets are just a small part.

实际上，最重要的事情被遗忘了 - 您如何构建（组织）您的应用程序？如果您尝试构建一个以 RESTful 方式与服务器通信的单页应用程序，那么如果您的应用程序没有架构，您很快就会陷入混乱。为此通常需要的功能是一些关注点分离（MVC、MVVM）、模板、路由和模块管理。这就是SproutCore和Sencha出现的地方。它们为构建 Web 应用程序提供了全面的解决方案，其中小部件只是一小部分。

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.

看起来 SproutCore 和 Sencha 是这里的赢家，因为它们是最完整的解决方案，包括 UI 和业务逻辑以及构建您的应用程序。尽管有所有优点，但也有一些缺点。有人说他们太重了，或者需要坚持他们的开发模式，你可能不喜欢。例如，在 Sencha 中，您用 JavaScript 描述您的 GUI 并使用 Sencha 的类型系统。这增加了一种沉重的感觉，即存在抽象和包装器，而您真的很喜欢 HTML、CSS 和 vanilla JavaScript 的易用性。

But this is not the only way. The power of web is that there are many-many frameworks, libraries, tools out there, smallerand 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.

但这不是唯一的方法。网络的力量是有多对多的框架，库，工具，在那里，更小的和大的，这将有助于您打造的应用程序，你喜欢的方式。例如，考虑AngularJS。它本身不提供一组控件，但与 Twitter Bootstrap 结合成为 RIA 的完整解决方案。或者，例如，看看EmberJS，这是一个更轻量级的框架，来自创建重量级 SproutCore 的人。它也不为您提供一组小部件，但在我看来，它是应用程序的一个很好的基础。

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.

所以这是我的最终想法而不是结论。所有这些框架通常会向您展示他们的小部件集、漂亮的主题和其他视觉内容。但真正重要的是你将如何实际开发你的应用程序，你将如何构建它，你将在哪里实现你的逻辑。了解框架提供了什么，并考虑是否可以替代缺少的内容。

回答by nexar

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.

Infeligo 的回答是一流的。我的经历可能会引起一些人的兴趣。我使用 Ruby on Rails 作为我的大部分业务逻辑所在的服务器平台。

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.

在前端，我使用 dHTMLX，它是一个“对象”的 JS 库，其中最强大的是它们的网格对象。我的大多数应用程序都有业务/会计信息处理/显示要求，网格对象是我的支柱。然而，它们的对象集是全面的，包括能够在单个应用程序中创建额外的“窗口”以向最终用户提供 MDI 类型的界面。我通常有一个登录表单，成功应用后会打开一个 HTML 页面，顶部有一个菜单。根据菜单中的选择，打开和关闭新窗口以显示/操作信息。这些窗口在单个 HTML 页面的范围内。

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.

所有的对象都有与它们相关的非常好的事件，我在前端使用这些事件做了相当多的验证。但是，我通常也会在 Rails 模型中复制所有数据验证。这是额外的工作，但我只是格外小心。还有一些抽象对象有助于在前端可视对象（例如网格和后端服务器）之间连接数据。大多数数据连接都可以使用 XML 或 JSON 来完成。我使用 XML 而不是 JSON 仅仅是因为我对这种结构的经验以及 Rails 提供了一个不错的 XML 构建器的事实。所以就我而言，我很少使用任何基于 Rails 的视图，因为我所有的视觉对象都来自 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.

我喜欢 dHTMLX 的另一件事是它们对象的速度。例如，网格对象将很容易以非常可接受的速度处理 10,000 多行。

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

希望这可以帮助