jQuery vs. Yahoo UI API design [closed]_问答_开发者

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended disc开发者_如何学JAVAussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

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?

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":

var someModule = $('#contain').someCoolModule();
someModule.trigger('initiate');

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 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.

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 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 is designed to work with the DOM (i.e. it's a language highly optimised around web pages).
you potentially have to hunt for stuff that jQuery plugins create automagically

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.

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.