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:

There are some errors, but it’s good enough for me to get started. Download the OmniGraffle document here. Corrections appreciated!

“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.

So maybe it’s best to explain an argument I lost. But first, my run-ins with javascript frameworks…

Terry meet framework

In 2005, Paul Hammant came up to me after my talk and mentioned that he was going to see Alex’s talk on DojoToolkit next. That was the first time I was exposed to a (complete) Javascript framework and I was impressed.

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:

These were some of the most active PHP frameworks in 2002. How many of these are actively used today? Which ones are they and why?

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

Since Javascript is about user interfaces, we see that my biases don’t carry water here. It is obvious how quickly I was impressed with Dojo, so what’s my problem?

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.

The reason it happened is simply because Dojo gives a huge gain for dropping code into the first load instead of the later loads via dojo.require. The framework being very top-down and XML-based encourages extensions via subclassing increasing the framework dependencies. Over time, this causes the programmer to bundle more and more parts into the initial load’s framework. This in turn bloats the javascript code but in real file size and execution time so that unloading it becomes undesirable so the application accretes into an “applike” state.

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.

Why?

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.

Example to the last. When I went to JavaOne, I went to every booth offering front end web ui frameworks or those built as mostly web ui and I asked them how big their javascript load was. Almost all of them said, “It’s pretty light. Less than 150 kilobytes.” Now when they said 150k, they almost always meant for the minimum page, the demonstrations I saw has extra script loads putting almost all of them above 150k in Javascript, some into the megabytes.

For reference, the entire upper half of the architectural diagram of YUI is in a single javascript load called “util” which is 23 kilobytes.

In enterprise, 150k for a javascript base is considered small. For a social network, it’s deal-killing.

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.

It’s been two years since YUI came out. And YUI has rewarded me with every release. I hazard to guess that in these two years it has grown the most of any javascript framework out there, I can even optimize it and not pay a penny, it is well-documented, it has great examples, it’s going to make it so I don’t have to bug Crowley for his code. 😀

Happy Birthday YUI and thank you, the developers, contributers, users, and our host, Yahoo!