domingo, 22 de enero de 2012

Comparing YUI vs jQuery for simple tasks

Most of the people agree on the fact that using jQuery is not enough to build complex web apps.   When building one of those apps with jQuery you will probably end up including additional libraries and tools for logging, widgets, graphs, MVC infrastructure, history tracking, unit testing, minification... or moving to a different framework like dojo, YUI or ExtJS.

So, we can not create complex apps just with jQuery, but on the other side... Should we create simple apps with those bigger frameworks?  Are they really imposing a performance overhead and making much more complex to implement simple tasks?

To answer that question I tried to implement three typical use cases of simple apps with jQuery and YUI to compare the code produced.  Those typical use cases are 1) Attaching event handlers, 2) Modifying the DOM and 3) Making async HTTP requests.

1) Attaching event handlers (f.e. to catch a click event)
jQuery: $(selector).click(function() { });
YUI:'click', function() { });
Conclusion: YUI slightly more verbose (but could be aliased as $ and the syntax is the same with both libraries in case of using event delegation). Result: tie

2) Modifying DOM (f.e. to show a div)
jQuery: $(selector).show();
Conclusion: Identical (at least for this example).  Result: tie

3) Making async HTTP requests
jQuery: $.post(url, function() {} );
YUI:, { method: 'POST', { on: { success: function() { }} } )
Conclusion: YUI slightly more verbose.  I'm also missing deferreds support in YUI.  Result: jQuery wins

* Selectors are pretty similar and didn't find relevant differences in the support included in jQuery and YUI

Regarding the size of the library, some quick information without too much investigation (minified but without considering compression):
jQuery 1.7.1: 90KB
YUI min (limited but allows deferred loading of rest of yui components): 70KB
YUI min + dom + events + animations + io (equivalent to jquery?): 150KB
Disclaimer: I'm not an expert on YUI, comments and corrections are more welcomed

miércoles, 11 de enero de 2012

C++ MACRO Nightmare

This afternoon I was implementing a typical circular buffer including some lines like this to make the pointers go from the end of the buffer to the beginning again when needed.
_bufferReadPos = (_bufferReadPos + len) % BUFFER_SIZE;

When testing the code I started to see very weird values of the read and write pointers, in fact much bigger than expected.

After at least 10 minutes trying to debug the problem I realized that it was because of the expansion of the BUFFER_SIZE macro that was:
#define BUFFER_SIZE 32*1024

% Has precedence over * and my code was been interpreted as:
_bufferReadPos = ((_bufferReadPos + len) % 32) * 1024;
Very sad and not easy to catch.  My solution has been using parenthesis in the BUFFER_SIZE definition to avoid it being split again when being part of the previous line:
#define BUFFER_SIZE (32*1024)

Do you have similar nightmare stories with macros?!