We use YUI at Tagged because that’s what I chose. We lost a couple front end engineers at Tagged so I’m having to pick up the slack—this means actually having to learn the Yahoo User Interface (YUI) in earnest. So I whipped up this diagram of YUI 2.5:
“What?!” You say. “Someone set us up the bomb? How could you make a choice and not know everything about it.”
Yes, I made the architecture decision to use YUI without knowing it in detail. However, I believe that sometimes when examining architectures you miss the forest from the trees.
[The philosophy of architectural choices after the jump.]
I believe software is about making choices—when you pick up one end of the stick, you pick up the other.
Terry meet framework
But something bothered me about Dojo and JotSpot. It was fine, but it wasn’t me. This was further confirmed when I saw Renkoo beta in 2006.
Frameworks, my old nemesis, we meet again
Now you might this is just bias because I hate frameworks. Except my hatred for frameworks is rooted in practicality.
There have been almost as many frameworks as there have been programmers. And yet only a handful are successful. Rails? Hardly! J2EE, okay in enterprise, but when Rails has traction there that’s not saying much. STL? ATL? dotNet?
Heck, I made a slide mentioning some PHP frameworks in 2002 and it’s telling:
But look at the successful ones here—they’re self-contained applications or give real utility in building applications.
Now consider “the forest.” In the entire history of frameworks, what are most successful frameworks: tk, KDE, Gnome, Cocoa, Windows, etc. They’re all graphic user interface frameworks. It is the sad reality that UI soon amount to more than half your code base, and it’s too costly to build it yourself and train people in the new affordances it will demand.
So while I do dislike frameworks in general, I think that user interface frameworks are not just an exception—in the area of graphic user interfaces, they are a necessity!
Plaxo chooses Dojo
Let’s talk about a time I lost an architectural argument. Plaxo 3.0.
In the beginning of 2006, Plaxo was doing a rewrite dubbed “3.0” which was going to go whole hog into the remote scripting idea I introduced to the company in 2004. Since all of us wanted to use a framework, the poiunt of contention was which framework to use.
I wanted to use the lightest weight framework available that built out a GUI (the newly-released YUI) and string the minimal amount of window dressing on top of it, but after vetting all the frameworks out there, the other two senior programmers wanted to use Dojo Toolkit. Here was my argument:
“Most of our revenue and our most loyal users are Outlook users. Therefore the web application should place a priority on making the best possible experience for them. Look at Jotspot. Look at the Renkoo beta. They’re both ajaxian applications instead of ajaxified web pages. In other words, they’re bloated. I’m worried that if we build Plaxo 3.0, then it will be a full-blown application like they are in an area where there is no existing affordance showing people are willing to live in the application. Choosing Dojo is putting the cart before the horse.”
The reply was, “Dojo can be customized to be lightweight—lighter than any other framework. It has all the tools we need and YUI doesn’t.”
“Renkoo and Jotspot aren’t lightweight and these two applications are made by some of the best UI programmers I know who have a vested interest in seeing dojo succeed.”
But, I didn’t put in the hours looking at dojo, YUI, Prototype/script.aculo.us, Rico, Backbase, Mochikit, etc. However, my argument wasn’t good engineering. Since I hadn’t looked at all the trees, I apparently wasn’t qualified to judge the forest.
Victory can be ashes in your mouth
I was right though. Plaxo 3.0 was very late, and really nobody talks about it—they talk about Pulse. Plaxo 3.0 is bloated and slow, especially for something as simple as popping a web-directed dialog box from the Outlook client UI.
This is all fine if it were an e-mail application, but it’s just a contact manager and calendar.
My last act before leaving, I hacked something together for them. Of course, because it was a hack, I wrote it in YUI. 😉
The trees confuse the issue. There is no doubt that Dojo is theoretically smaller, especially with the latest releases. But in practical terms, it isn’t. And with the sorts of developers behind it and applications it is typically run on, there is no incentive for it to be.
Why I choose you, YUI!
So when I joined Tagged, one of the first things I did was implement my bias, and settle on YUI.
Because Tagged is a set of pages that the users will be loading and unloading. Having an “Ajaxian application” is a non starter for a social network.
Because Yahoo is consumer-focused company. I know they’ll put the consumer needs first and I won’t have to wait in line behind an enterprise customer.
I said when you pick up one end of the framework, you pick up the other. I never said YUI is perfect, nor do I think that it’s the best solution everywhere. But when I pick up a framework, I pick up the other ends. For some problems, some ends are the shit ends.
It’s the GUI, stupid!
I like to say, “YUI suits me. It’s how a PHP developer would write a UI framework.”
Look at the diagram again. Notice how few libraries depend on Connection Manager? And yet, without Connection Manager, it’s not even Ajax!
It’s library-oriented, highly-cohesive, loosely-coupled, ad hoc, and mostly about the GUI.
Happy Birthday YUI and thank you, the developers, contributers, users, and our host, Yahoo!
5 thoughts on “Why I YUI”
We use YUI here at CNET now. I need to digg deeper into it. Nice diagram.
When I first played with prototype I could figure out how to do things, but the docs were weak, and seemed to be trending behind development. I’ve seen the same thing in a bunch of other libraries, which is a bit sad :(.
there is a YUI uml diagrams and javadoc at project http://yui4java.sourceforge.net/yui3/javadoc/inde…
I found very interesting information in your blog and also checked sebastian's link, thanks.
My recent post Warehouse Inventory Software Products – Finding The Appropriate Software Solution