YUI vs. jQuery – A personal experience summary

Just spent a week trying to build a prototype/demo with YUI3 as required by stakeholders, the process is more filled with misery than joy:

YUI3 is a good library with comprehensive design and features, e.g., the loader makes component loading a piece of cake, the object hierarchy makes it easy to build your own widgets and modules … However when I tried to make advanced use of the TabView control, things start to get messy. TabView doesn’t seem to support adding pre-initialized widget as content, instead you must provide HTML string with custom ID and then find that part of HTML via the ID and do initialization work later, which works but clumsily. YUI3 automatically assign class names and load styles for TabView control elements, which is great and the beginning, but when I tried to embed TabViews within TabViews with different look and feel, lots CSS hacks must be added to overwrite default settings. TabView control allows you to add and select new tabs at runtime, however the parameter used to select a tab is its index, which is a transient value when tabs are dynamically added and removed, which makes it hard to link a certain tab with a button, that you have to recalculate the index upon each click …

Seemingly I’m not that good at YUI3, and there are surely better solutions to the scenarios I mentioned above. But the point is, it is more complex to work with YUI3 than jQuery:

Learning Curve:

  • YUI3’s: steep, requires lots learning before getting things right
  • jQuery: smooth, learn new functions when you need

OO vs. Procedure (remind me of the early days I gave up mootools for jQuery):

  • YUI3: If you need custom widget, inherit/extend from an existing one… and the eventual object hierarchy can make debugging hard
  • jQuery: If you need custom widget, just switch to a different plugin, usually there are lots choices out there

Architectural Impact:

  • YUI3 based app requires more prior architectural design and decisions, refactoring can be hard
  • jQuery based app can start with casual code, then gradually group, organize and optimize (based personal journey to build JPolite II)

I think the last point is vital that architectural decisions are better put off as late as possible, since nobody can picture everything clearly at the beginning, and a decision based on immature thinking can lead to disasters.

Now I recall Tom Kelley’s idea on design principle from The Art of Innovation, “Make simple things simple and complex things possible.” Surely to me, jQuery is built on such principle, while YUI3 does make complex things possible, but at the cost of making simple things complex. There are always a million ways to make things complex, but it usually takes genius design to get things simple.