geeky · non php code

Why I prefer jQuery over YUI

While at work, I was trying to find a way to easily do server side pagination without writing all the lovely logic myself. Due to some constraints, I am unable to use more high end framework such as JSF and struts. Which in a way I believe is a good thing. I would have more control over just writing servlets. However, having written pagination logic before, I really did not want to write that again. Somehow I thought of jQuery. Just for amusement, I looked for jQuery pagination plugin and guess what I found it! By using this plugin, I can pass in some simple parameters such as total records, records per page, number of pages shown etc. to have jQuery generate a paginator for me. That’s beyond cool so I put it into action.

Upload Report Mock uses the jQuery pagination plugin but handles the pagination on the server side via php.

Ultimately what I also want to handle is the following scenario:

  • I have a table of data, one of the column is editable.
  • If the user clicks on the column of a particular table row, a modal window will pop up asking for additional information.
  • The user fills out the information and submits.
  • The window updates the info for that table via AJAX and updates the results screen

While I was eager for figure out how to accomplish that in jQuery, I found out that it is not one of the previously used javascript framework at work so they asked if I could look into YUI.

Digging into YUI, first I tried to accomplish the same thing using the YUI paginator widget. I spent two hours but it really does not seem like I can generate some href tags with this component like I could with the jQuery plugin. With jQuery, I could produce:

<div id="pagination">
<a class="prev" href="/work/eAdjusterActivityReport/uploadReport.php?page=1">Prev</a>
<a href="/work/eAdjusterActivityReport/uploadReport.php?page=1">1</a>
<span class="current">2</span>
<a href="/work/eAdjusterActivityReport/uploadReport.php?page=3">3</a>
<a href="/work/eAdjusterActivityReport/uploadReport.php?page=4">4</a>
<a href="/work/eAdjusterActivityReport/uploadReport.php?page=5">5</a>
<a href="/work/eAdjusterActivityReport/uploadReport.php?page=6">6</a>
<a href="/work/eAdjusterActivityReport/uploadReport.php?page=7">7</a>
<a href="/work/eAdjusterActivityReport/uploadReport.php?page=8">8</a>
<span>...</span>
<a href="/work/eAdjusterActivityReport/uploadReport.php?page=10">10</a>
<a href="/work/eAdjusterActivityReport/uploadReport.php?page=11">11</a>
<a class="next" href="/work/eAdjusterActivityReport/uploadReport.php?page=3">Next</a>
</div>

With YUI, I have to hook up the paginator with another javascript or YUI widget. So to make things easier, I looked into YUI’s datatable component and found an example to use it with server side pagination and sorting. That seems to accomplish the overall need of pagination. Although that’s a bit of overkill but I thought it’s worth a shot. I spent 8 hours implementing it via server side JSON. Here’s what I produced:
Upload Report Mock with YUI

Instead of 10 lines of javascript code like the previous, this one has 68 lines. But it does provide AJAX pagination so I thought that’s mostly fair.

Next I looked for a simple date picker calendar in YUI like the jQuery date picker plugin. The date picker is a necessary functionality of the application. With jQuery, it’s extremely easy to use. You add the plugin js & css links, and then you give your input css class or unique IDs and with jQuery selector, just call the plugin via:

$("#startDate").datepicker()

Click on the start and end dates in Upload Report Mock to see it in action.

Using YUI, I looked into its calendar component. The closest thing I could find is this example.

Not only would it need all these extra js includes

<script type="text/javascript" src="http://yui.yahooapis.com/2.6.0/build/event/event-min.js"></script>
<script type="text/javascript" src="http://yui.yahooapis.com/2.6.0/build/dragdrop/dragdrop-min.js"></script>
<script type="text/javascript" src="http://yui.yahooapis.com/2.6.0/build/element/element-beta-min.js"></script>
<script type="text/javascript" src="http://yui.yahooapis.com/2.6.0/build/button/button-min.js"></script>
<script type="text/javascript" src="http://yui.yahooapis.com/2.6.0/build/container/container-min.js"></script>
<script type="text/javascript" src="http://yui.yahooapis.com/2.6.0/build/calendar/calendar-min.js"></script>

It also requires another 76 lines of javascript code for just adding one date picker.

Despite the complication, I tried to make it work with my Upload Report Mock with YUI but I failed pretty miserably. Sure if I put in enough hours, I will eventually make it work but WHY? Why would you stop yourself from using something else that takes 2 seconds?

At this point, I presented my findings to my co-workers. I really hope they will accept jQuery. Yea sure it’s yet another new javascript framework but it will save coding time.

Here’s another comparison. I found a very YUI datatable like jQuery plugin flexigrid. Take a look at example 3. Lines of code to use server side pagination and sorting: 33. In my Upload Report Mock with YUI, I used 68 lines. Also let’s do a comparison to see which one makes more sense and is less verbose.

jQuery:

$("#flex1").flexigrid({
	url: 'post2.php',
	dataType: 'json',
	colModel : [
		{display: 'ISO', name : 'iso', width : 40, sortable : true, align: 'center'},
		{display: 'Name', name : 'name', width : 180, sortable : true, align: 'left'},
		{display: 'Printable Name', name : 'printable_name', width : 120, sortable : true, align: 'left'},
		{display: 'ISO3', name : 'iso3', width : 130, sortable : true, align: 'left', hide: true},
		{display: 'Number Code', name : 'numcode', width : 80, sortable : true, align: 'right'}
		],
	buttons : [
		{name: 'Add', bclass: 'add', onpress : test},
		{name: 'Delete', bclass: 'delete', onpress : test},
		{separator: true}
		],
	searchitems : [
		{display: 'ISO', name : 'iso'},
		{display: 'Name', name : 'name', isdefault: true}
		],
	sortname: "iso",
	sortorder: "asc",
	usepager: true,
	title: 'Countries',
	useRp: true,
	rp: 15,
	showTableToggleBtn: true,
	width: 700,
	height: 200
	}
);  

YUI: click for source.

11 thoughts on “Why I prefer jQuery over YUI

  1. With all due respect as to the including js files, you could cut it down to a very few for YUI by including utilities.js as it is an aggregate of many of the scripts you have to link in.

  2. Here comes someone missing the void.

    There are two main facts about jquery that I found deeply annoying:

    1) the fact that it uses paradigms that are totally the opposite of “common sense”. To me, g = selector.flexigrid() sounds totally absurd. Why should I call a method on a DOM node to create a flexigrid on it? flexigrid(selector) would be the usual strategy: create an object passing the point where to attach as a parameter, which is what YUI does. More to the point, jquery puts the DOM at the center, it uses the DOM and attach javascript stuff on it. The traditional programming approach, followed by YUI, is to use javascript objects to manipulate the representation (on the DOM), exactly the opposite. I don’t want to handle DOM nodes, I want to handle javascript objects. This also means it’s more complex in jquery to extend a javascript class to override behavior, something very intuitive in YUI from whoever comes for example from QT programming, like me.

    2) As for flexigrid, the access to internals is so poor that any personalization is utterly impossible, and the code design is awful. Datatable is much more powerful and extensible.

    Now, I don’t claim I’m right, I am a total and absolute novice of javascript, so it can be that in some weeks I come back here to say I’m utterly wrong, but as a first impression, this is my opinion, and I wanted to share it. I am currently in the process of ditching jquery for yahoo ui in particular due to jquery annoying (to me) reversed design, and the very limited flexigrid features.

    I think that having other opinions from fellow colleagues is important on this point.

    http://stackoverflow.com/questions/2000597/jquery-vs-yahoo-ui-design

    1. The replies you got on the post pretty much sum it up. You are complaining about a plugin rather than jQuery as a framework. g = selector.flexigrid() makes perfect sense to me and I absolutely love it.

      1. Well, I’m not complaining, I just personally don’t like it :). And yes, the posts on stackoverflow are right. I do like jQuery when you use the selector to perfom an action (e.g. pure jQuery). The interface makes sense, because you are using methods on the selected entities. It’s like DOM interface on steroids. Totally love it as well. jQuery widget plugins, no. That’s totally counterintuitive to me. When you move at the conceptual level of widgets, it should hide the DOM behind a semantically sound API. The fact is that most of the widget jquery plugins I’ve seen work with this very flat, low semantic interface.

        Opinions though…

        1. “When you move at the conceptual level of widgets, it should hide the DOM behind a semantically sound API.”

          No. The DOM is a pretty simple and because of this, a really powerful API. Hiding it is a mistake. If you do that, what you end up with is something like .NET or Qt or GTK+, a gazillion of classes, and huge amounts of accidental complexity. You need to embrace the DOM, not turn your back on it.

          I came from desktop GUI programming too (GTK+), and it takes some time to getting used to, but really – not having to deal with a huge class library to do simple things is a big win in the long run.

          1. I am sorry, I don’t agree. The DOM is pretty simple, powerful and flexible, exactly as ASM is simple, powerful and flexible. Yet, nobody would program today in ASM just because of these apparent advantages. DOM is a low level interface to a declarative language for browsers. Exclusively working with it implies a considerable risk of violating application constraints. Moreover, there’s a very high chance of a considerable code repetition when you program with DOM-level calls, redundancy which will most likely refactored into higher-level routines, hence you will end up reinventing a “widget set/utility library” again and again.

            A similar example would be Qt against X windows calls. Nobody codes Xwin-level to create a dialog. a QMessageBox::warning() does the trick.

            Of course, completely preventing a DOM level access would be wrong, but having to forcibly work at the DOM level is just plain painful.

  3. This comes at least a year late from the original post, but I’d suggest a close look at jqGrid as an alternative to Flexigrid.

    jqGrid here: http://www.trirand.com/blog/

    jqGrid is very open, more feature-rich, and has a strong community supporting it – including a very active and approachable principal developer.

  4. The sorting in the examples seems a bit odd. I try to sort by division by clicking the header and I see there is a high number 17 in there but it doesn’t go to the top and in fact disappears strangely. Ah maybe it’s setup for sorting by characters (left to right) rather that integers.

    Anyway, very good article as I’m starting off with jQuery but learned about YUI also. The mock report pagination is very cool and I’ll be needing to make something similar sometime soon.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s