From YUI to jQuery UI

Last year I started a large project and chose YUI 2.7 as the main JavaScript library for creating a rich UI. I primarily used the Dialog, TabView, TreeView and DataTable UI widgets for CRUD admin. The Event utility was used for creating a custom event bus and Connection Manager was used for core Ajax communication. Later during the project's lifespan I discovered the beauty of jQuery and slowly started to use some of the core features for elegant cross-browser DOM manipulation. This eventually lead to my desire to completely phase out YUI in favor of pure jQuery.

But why abandon something that already works? YUI did a fine job, but the API structure and markup just feels like too much work to get simple things done. I abandoned the YUI DataTable very early on in the project as it was taking way too many lines of code to get simple grids up. The TabView, TreeView and Dialogs were working fine, but the default sam-skin stylesheets were not playing nice with a set of external template styles and required a lot of hacking, which lead to cross-browser inconsistencies.

With jQuery UI on the other hand, the online Themeroller was fantastic! I was able to customize my own theme matching the template color pallet and simply drop-it-in. The jUI widgets worked correctly with my external style definitions with minimal hacking required.

Another great thing about jQuery is that the whole package is made up of 2 .js files (core & ui), 1 css file and a few images. The YUI package on the other hand was over 400 files. These can be minified and combined to some extent using their online package builder, but the whole framework just feels a lot heavier.

Refactoring the project took about a week but the end result was worth it. The application is now noticeably snappier and the UI components are consistent across all browsers. Listed below are some jQuery tips and tricks I learnt along the way.

POST Form via Ajax
I've seen a lot of examples on the internet where people use jQuery selectors to manually pick out the values from every form input element by name and build the query string. This is totally unnecessary! Posting a form via Ajax using jQuery 1.4+ is as easy as:

data: $("#my-form-id").serialize(),
url: 'localhost/process.php',
error: function() {
alert('ajax call failed');
success: function(data, status, XMLHttpReq) {
alert('ajax call returned ' + XMLHttpReq.responseText);

This is a generic function that'll work with any form. Just wrap this in a utility method passing in the form id, the error callback and the success callback and you're done. No need for instance specific code picking out input element values, etc.

jQuery UI TreeView Equivalent
The current jQuery UI (1.8) does not have a native Tree widget (although one is in the works). Fortunately though, jsTree is an easy to use plugin that gives you the same functionality and more.

PHP Array to JavaScript Array
This one isn't jQuery specific, but I've seen a lot of crazy methods for converting a PHP array for consumption in JavaScript. The following is a one-liner way of doing it:

<script type="text/javascript">
var jsArray = <?=json_encode($phpArray)?>;

Don't ignore this. Use it whenever you're doing any DOM manipulation whatsoever. This is especially true if you want IE6/7 to work correctly. Not using $(document).ready() can lead to race conditions that will only manifest on some browsers (usually the client's) leading to whole-page crashes or other random behavior.

jQuery Custom Events
Using custom events in jQuery is very easy. The most basic form of this is:

//to subscribe to some randomly named event
$('body').unbind('myEvent').bind('myEvent',function(){/*do stuff*/});

//to fire an event
The above code first unbinds (unsubscribs) any descendant of body who was previously registered to a custom event labeled 'myEvent', and then subscribes an anonymous function to this event. The second line is usually executed at some later point, perhaps after an ajax form post, that triggers the event. The unbind is not strictly necessary, it very much depends on your application architecture. It's possible to have multiple listeners for the same event by design. Just be aware of this and make sure your events are being consumed the way you think they are. If you only ever want one listener, it should be safe to unbind first just in case.


Popular posts from this blog

Wkhtmltopdf font and sizing issues

Import Google Contacts to Nokia PC Suite

Can't delete last blank page from Word