YUI vs. jQuery – Developer Energy Distribution

Put it simply with the 80 / 20 rule:

  • jQuery: 80% on your application logic + 20% on studying the API documents
  • YUI3: 20% on your application logic + 80% on studying the API documents

I might sound too prejudiced against YUI3, but my experiences has remained awful:

  • I still need to go over the documents of fundamental elements, e.g., Node & Event, again and again after months with YUI3.
  • Shortcut methods like node.show() could not handle cases where the node is set hidden by default in CSS, that I have to use other methods like node.setStyle(“display”,”block”), that the shortcut is meaningless to me.
  • The MVC modules introduced in YUI 3.4 sounds so good at first look, then when I dig into the details, I have to give it up due to huge memory overhead when dealing with 1000s of simple objects.
  • Once I need to add a context menu, which was not included in YUI3. Some “experts” suggest I need to create a new class based on Overlay or Widget, initiate an instance upon right click, render the menu, then destroy it after user clicks an item or elsewhere … I just need ONE context menu, do I need to go over all the stupid stuff to get something simple done? Eventually I finished the job with just 10 lines of RAW JavaScript + CSS!

The context menu case reminds me of the different ways to build hello world with C vs. Java:

  • main() {
        printf ("Hello World!\n");
    }
  • class HelloWorldApp {
        public static void main(String[] args) {
            System.out.println("Hello World!");
        }
    }

See the difference? With Java, you need to first create a HelloWorldApp class, which includes a public static void main method , inside the method, you need to call System.out.println to get the string out! I wonder if anyone realize the pre-requisites of Java to write a simple app like this!

  • Class definition
  • Public vs. Private methods
  • Static vs. instance methods
  • Predefined classes / instances and their methods

OO thinking is not necessarily good and procedure thinking is not necessarily bad. The world is complicated enough, and I believe it’s everyone’s responsibility to keep it AS SIMPLE AS POSSIBLE!

Advertisements

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.