Home/ Questions/Q 532159
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T09:22:34+00:00

I am baffled by the difference in design between jQuery and Yahoo UI APIs.

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0