jQuery 与 Yahoo UI API 设计
我对 jQuery 和 Yahoo UI API 之间的设计差异感到困惑。免责声明：我非常不喜欢 jQuery api，但我对 Web 编程和 javascript 也非常无知，所以我可能完全错了，然后回到这里乞求救赎。这么久了...
我的问题要点如下。两种设计不同。 jQuery 将 DOM 放在中心，并通过在其上执行“触发”增强器方法来装饰 DOM。 jQuery 的一个要求
$("#flexigrid").flexigrid()
是，在某些情况下，您必须事先遵循 html 的非常具体的常规结构。示例：
<div id="accordion">
<h3><a href="#">First header</a></h3>
<div>First content</div>
<h3><a href="#">Second header</a></h3>
<div>Second content</div>
</div>
然后
$("#accordion").accordion();
而且，返回的实体一般不提供任何通过方便的编程方法隐藏 DOM 的机制。要操作你的 jQuery 实体，你必须通过选择器访问 DOM，在某些情况下，访问并不能保证很容易知道，就像内部生成的 id 的情况一样。假设您想以编程方式交换手风琴，您所做的
$('#accordion').accordion('option', 'active', 2);
并不是更直观。
myAccordion.setActiveTab(2);
另一方面，yahoo ui 专注于 javascript 对象，您通过 DOM 节点选择器创建它们（例如 myDataTable = new YAHOO.widget .DataTable("container_id"))，然后通过对象方法执行所有操作。想要添加新行吗？调用 myDataTable.addRow()。 DOM 是隐藏的。您不关心幕后发生的事情。
现在，我使用 Trolltech QT 的体验很好地映射到了 Yahoo UI。清晰、定义的小部件对象 API，最终可以通过继承自由地重新实现其中的一部分，不透明渲染，除非您想打开盒子并亲自动手。 QT 是一个成功的 API，运行良好，易于使用，与 Yahoo UI 的设计风格有点相似。另一方面，jQuery 以一种违反直觉（对我来说）、非常开放的方式工作，其对象上的 API 减少了。
骂够了。关键是我认为我在这一点上可能是完全错误的，但我想知道为什么。拥有类似 jQuery 的界面有哪些设计优势（其中 DOM 清晰可见，您可能必须寻找 jQuery 插件自动创建的内容，因此您最终可以 $(select) 它们并附加事件或修改它们的内容）而不是像 YUI 那样将所有内容隐藏在对象和商品方法后面？
我不是在谈论速度、代码大小或输入量。我谈论的是封装、关注接口和易于访问等设计概念。什么设计更好，在什么情况下更好，为什么？
I am baffled by the difference in design between jQuery and Yahoo UI APIs. Disclaimer: I have a strong dislike of the jQuery api, but I am also a huge ignorant in web programming and javascript in general, so I could be dead wrong and come back here begging for redemption. so long...
The point of my question is the following. The two designs are different. jQuery puts the DOM at the center, and adorns the DOM by executing a "trigger" enhancer method on it. example
$("#flexigrid").flexigrid()
A requirement of jQuery is that you must, in some cases, follow a very specific conventional structure for your html beforehand. Example:
<div id="accordion">
<h3><a href="#">First header</a></h3>
<div>First content</div>
<h3><a href="#">Second header</a></h3>
<div>Second content</div>
</div>
and then
$("#accordion").accordion();
Moreover, the returned entity in general does not provide any mechanism to hide the DOM through a convenient programmatic method. To manipulate your jQuery entity you have to access the DOM via selectors, access that in some case is not guaranteed to be easy to know, like in the case of internally generated ids. Suppose that you want to swap the accordion programmatically, what you do is
$('#accordion').accordion('option', 'active', 2);
and not a more intuitive
myAccordion.setActiveTab(2);
On the other hand, yahoo ui focuses on javascript objects, you create them passing the DOM node selector (e.g. myDataTable = new YAHOO.widget.DataTable("container_id")) and then perform all manipulations through the object methods. Want to add a new row ? call myDataTable.addRow(). The DOM is hidden. You are not concerned with what's going on behind the scenes.
Now, my experience with Trolltech QT maps nicely to Yahoo UI. Clear, defined API of the widget objects, eventual freedom to reimplement part of them via inheritance, opaque rendering unless you want to open the box and get your hands dirty. QT is a winning API, works well, it's easy to use, and Yahoo UI is kind of similar in the design style. On the other hand, jQuery works in a counterintuitive (to me), very open box way, with reduced API on its objects.
Enough ranting. The point is that I assume I can be dead wrong on this, but I'd like to know why. What are the design advantages of having a jQuery-like interface (where the DOM is clearly exposed and you potentially have to hunt for stuff that jQuery plugins create automagically, so you can finally $(select) them and attach events or modify their content) instead of hiding everything behind an objects and commodity methods like YUI does ?
I'm not talking about speed, or code size, or amount of typing. I'm talking about design concepts like encapsulation, focus on interfaces, and ease of access. What design is better, in what situations, and why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我同意计算机语言学家的观点。 OOP 并不完美地适合所有可能出现的问题。
在 Web 开发的情况下，首先必须决定必须设计的解决方案类型。该解决方案本质上是一个网页，在增强交互性的地方嵌入了交互式小部件，还是一个成熟的 RIA。 JQuery，我相信适合第一种情况，它基本上是为了简化 DOM 的处理而设计的。
对于 RIA 应用程序，首选在更高抽象级别工作的工具包，因为在这种情况下，开发人员处理的是小部件和布局，而不是底层的 HTML 和 css。在这种情况下，使用 YUI、Dojo 或 ExtJS 等面向对象的工具包会更方便，因为它们将桌面应用程序开发方法（及其相关优势）引入到 Web 领域。
I agree with Computer Linguist. OOP is not a perfect fit for every possible for problem.
In case of web development one first has to decide upon the kind of solution that one has to design. Is the solution essentially a web page with interactive widgets embedded at places that enhance the interactivity or is it a full fledged RIA. JQuery,I believe is fit for the first case and it is basically targeted towards ease of handling of the DOM.
In case of RIA applications, toolkits working at a higher level of abstraction are prefered because the developer in this case is dealing with widgets and layouts rather than the HTML and css that lies underneath. In such case using Object Oriented Toolkits like YUI, Dojo or ExtJS are more convenient as they bring the desktop application development approach (with its associated advantages) to the web domain.
我不认为你的论点是针对 jQuery 的，而更多是针对插件作者提供的 API。
不幸的是，没有两个插件作者会创建具有相同 API 的插件。编程访问的级别不受 jQuery 本身的限制，而是受插件作者的限制。
另外，正如您所说，jQuery 是关于 DOM 的——我认为这是一个好处，因为这意味着 jQuery 不会完全混合在应用程序的“逻辑”（呃，“业务逻辑”）中......它本身的抽象级别相当不错——它处理 DOM，仅此而已！
您可以为您的应用程序创建无限数量的数据结构和附加 API。 jQuery 在这方面不会妨碍您。
您已经为您的问题添加了更多详细信息 - 此“编辑”是为了回应这些详细信息。
我认为当你使用 jQuery 达到一定阶段时，你所遇到的情况是很常见的...... API 变得不足。您不需要 DOM...您需要为您的模块提供一个干净的 API，无论它是手风琴还是数据网格。
就个人而言，我不认为某些东西应该捆绑到“jQuery 插件”中——这样做通常意味着牺牲 API——或者必须求助于 jQuery 的机制，例如伪事件触发通过“trigger”：
我明白你的意思，我想我同意，但我也认为将 jQuery 放在一个完全独立的级别上很重要 - 忘记它 - 仅当你需要攻击 DOM 时才使用它。
I don't think your argument is directed at jQuery, but more the APIs provided by plugin authors.
Unfortunately, no two plugin authors will create a plugin with the same API. The level of programmatic access is not limited by jQuery itself, but rather by the author/s of the plugin.
Also, as you said, jQuery is all about the DOM -- I see this as a benefit because it means jQuery doesn't get all mixed up in the "logic" (eh, "business logic") of the application... It's quite fine on it's own level of abstraction -- it deals with the DOM, and that's all!
You can create an unlimited amount of data structures and additional APIs for your application. jQuery doesn't hinder you in this respect.
You've added more details to your question -- this 'edit' is in response to those details.
I think what you're experiencing is common when you reach a certain stage with jQuery... The API becomes insufficient. You don't want the DOM... You want a nice clean API for your module, whether it's an accordion or a data-grid.
Personally, I don't think that some things should be bundled into a "jQuery plugin" -- doing so normally means sacrificing the API -- or having to resort to jQuery's mechanisms such as psuedo-event triggering through "trigger":
I get what you're saying, and I think I agree, but I also think it's important to have jQuery on an entirely separate level -- forget about it -- only utilise it when you need to attack the DOM.
jQuery 不需要任何类型的特殊标记 - 您可以为任何对象编写选择器。您还可以使用现有的 DOM 引用，并将其转换为 jQuery 对象，如下所示：$(domObject)。实际上比雅虎用户界面更简单、更强大。
如果您已经有 DOM 引用，则不需要知道您的 dom 选择器...这可能是您误解的根源。
在使用过 Yahoo UI 和 jQuery 后，我可以告诉您它们都是很棒的库。他们扮演不同的角色，但都有很好的方法。
jQuery 是一种包装器，简化了与 DOM、Ajax、选择对象、制作图形有关的所有事情。它有一个非常简洁且极其简单的 API，可以抽象出所有浏览器兼容性的废话。
jQuery 使用与大多数新手程序员习惯的完全不同的设计概念。它确实是 Javascript 应该如何使用的典型代表。几年前，人们对 Javascript 的强大功能还一无所知。主要是因为互联网上的大多数 JavaScript 都很糟糕。现在，我想大多数人已经意识到 Javascript 是最有能力的语言之一。它支持多种范式：函数式、命令式、面向对象（原型，而不是基于类）、数据文字……
jQuery 充分利用 Javascript 的能力，利用其设计的各个方面以最有效的方式解决每个问题。
我告诉所有学习 javascript 的人一遍又一遍地阅读 jQuery 源代码，直到他们理解它......这会很困难，但他们将成为更好的程序员，并在他们的工具箱中拥有更多种类的工具。
这有点垂直于Java/.NET的洗脑，即给每个开发人员一把螺丝刀（OOP），并告诉他们这是编程和生活中每个问题的完美解决方案。
事实并非如此。每个问题都需要不同的工具。 OOP 很好，但对于某些问题来说通常是个坏主意。
jQuery 的 mixin 风格的插件架构非常好。不同，但高效、快速且易于使用。
jQuery 排名第一是有原因的 - 它使用简单，而且非常强大。
Yahoo UI 是针对不同问题的不同方法。它是一个 UI 工具包，对 DOM 进行了大量抽象（相对于 jQuery 的轻量级方法）。
如果您打算做一些超出常规的事情，您会发现自己要花很多时间来修改它。 （这是重量级方法的缺点）。
它不是用于开发应用程序的框架。它是一堆 GUI 小部件。
我都一起用过。您没有理由不能在同一页面上同时使用 jQuery 和 Yahoo UI，它们是解决不同问题的两种不同工具。
我建议在站点/应用程序范围内包含 jQuery，然后根据需要包含 jQuery UI 插件。如果您需要重量级的东西，请添加 Yahoo UI。但请坚持使用 jQuery 来编写您的管道代码...
向 jQuery 学习。了解数组编程、回调、数据文字、将代码视为数据以及保持简洁的强大功能。对每个问题使用正确的工具意味着代码更短、更简单。
jQuery doesn't require any kind of special markup - you can write a selector for any object. You can also use an existing DOM reference, and turn it into a jQuery object like so: $(domObject). Actually simpler and more capable than Yahoo UIs.
It's not required to know your dom selectors if you already have a DOM reference... That might be the source of your misunderstanding.
Having worked with both Yahoo UI and jQuery, let me tell you they are both great libraries. They're for different roles, but both have great approaches.
jQuery is kind of a wrapper, simplifying everything that has to do with the DOM, Ajax, selecting objects, doing graphics. It has a very concise and brilliantly simple API that abstracts all the browser compat nonsense away.
jQuery uses radically different design concepts than most newbie programmers are used to. It is really the poster child for how Javascript should be used. A few years back, there was a lot of ignorance about the power of Javascript. Mostly, because most of the javascript on the internet was terrible. Now, I think most people have realized that Javascript is one of the most capabable languages. It supports several paradigms: functional, imperative, object-oriented (prototype, not class-based), data literals....
jQuery uses Javascript to its full ability, using each aspect of its design to solve each problem in the most effective way.
I tell all people learning javascript to read the jQuery source over and over until they understand it.... It will be hard, but they will finish by being much better programmers, with a much larger assortment of tools in their toolbox.
It's kind of perpendicular to the Java/.NET brainwashing, which is to give every developer a screwdriver (OOP), and tell them it is the perfect soltion to every problem in programming and life.
Which, it's not. Every problem needs a different tool. OOP is good, but often a bad idea for some problems.
jQuery's mixin-style plugin architecture is really good. Different, but highly effective, fast, and easy to use.
jQuery is #1 for a reason - it's simple to use, and incredibly powerful.
Yahoo UI is a different approach, for a different problem. It's a UI toolkit that has very heavy abstraction from the DOM (vs. jQuery's lightweight approach).
You'll find yourself speding a lot of time modifying it if you intend to something outside the norm. (That's the downside of the heavyweight approach).
It's not a framework for developing apps. It's a bunch of GUI widgets.
I've used both together. There's no reason you can't use both jQuery and Yahoo UI on the same page, they're two different tools for different problems.
I suggest including jQuery site/app-wide, then including jQuery UI plugins as needed. If you need heavyweight stuff, add Yahoo UI. But stick to jQuery for your plumbing code...
Learn from jQuery. Understand the power of array programming, callbacks, data literals, treating code as data, and keeping things concise. And that using the right tool for each problem means much shorter, simpler code.
在我看来，YUI 在 DOM 操作方面较弱，但在设计方面却遥遥领先。
JQuery 是为那些很少或没有 JavaScript（或一般编码）经验的人而设计的。启动并运行应用程序非常容易。
YUI 更具可读性，由于最佳实践方法的广泛使用，任何程序员都可以很快上手并使用它。
In my opinion, YUI is weaker in DOM manipulation, but is way ahead in design.
JQuery is designed for those with little or no JavaScript (or general coding) experience. Its very easy to get an application up and running.
YUI is more readable, and any programmer can pick it up and go very quickly because of the wide use of best-practice methodologies.
jQuery 是一个很棒的 DOM 操作库，它的 API 围绕选择器是它今天如此流行的原因之一。问题是，如果浏览器 DOM API 更加一致且更易于使用，则不需要 jQuery。我同意 Robert Harvey（上面评论过）的观点，即作为 DOM 之上的抽象层，jQuery 的工作非常出色。
但据我了解，您不喜欢 jQuery 插件系统和 jQuery UI，而不是核心库本身。就我个人而言，我更喜欢用于组件和小部件的 YUI 风格 API，因为在更高的抽象级别，DOM 元素变得不那么重要。我认为 jQuery UI 作者选择这种设计的原因是为了让 API 与他们的主要产品 jQuery 库更加一致。但我不认为这是一个好的决定。
jQuery is a great library for DOM manipulations, and centering it's API around selectors is one of the reasons why it's so popular today. The thing is, jQuery wouldn't be needed if the browsers DOM APIs were more consistent and easier to use. And I agree with Robert Harvey (commented above) that as an abstract layer over the DOM jQuery does a very capable job.
But as I understand, you dislike jQuery plugin system and the jQuery UI, not the core library itself. Personally, I prefer a YUI style API for components and widgets, because at the higher abstraction level DOM elements become less important. I think the reason why jQuery UI authors chose this design is to make API more consistent with their main product, jQuery library. But I don't agree that this was a good decision.
jQuery 被设计为与 DOM 一起工作（即，它是一种围绕网页高度优化的语言）。
你可能需要寻找 jQuery 插件自动创建的东西
大概，如果合适的话，插件会返回一个您可以操作的 jQuery 对象，除非它写得不好。在这种情况下，这显然是插件的错误。
如果您使用自动生成 ID 的方法，那么 jQuery 可能不适合您。然而，例如，我使用 jQuery 与 Google 地图 没有遇到太多麻烦。
如果您想自动向表中添加一行，我确信有一个插件。如果没有，则不会有很多东西要写。。
jQuery is designed to work with the DOM (i.e. it's a language highly optimised around web pages).
Presumably if it's appropriate, a plugin returns a jQuery object that you can manipulate, unless it's badly written. In which case that's obviously the plugin's fault.
If you're using a method that autogenerates IDs then jQuery may not be for you. However for example I've used jQuery with Google Maps without too much trouble.
If you wanted to add a row to a table automatically, I'm sure there's a plugin out there. If not, it wouldn't take much to write one.