Developing a JavaScript Library for Yahoo!

By Eric MiragliaFebruary 17th, 2006

When we set out about a year ago to build the Yahoo! User Interface Library, we had a specific set of challenges to address. First and foremost, we wanted to enable our front-end engineers to spend more time working on advanced, product-specific features and less time doing cross-browser tuning of generic interactions like drag and drop. We have a deep, talented, and creative pool of developers across the company, but we hadn’t done enough to develop shared libraries that normalize differences across relevant browsers. As a community, we agreed that we needed better toolkits for those rich interactions that can enhance users’ experiences of Yahoo! products.

Creating the library represented a significant undertaking, and we spent a lot of time talking among the larger front-end engineering community here about how to go about doing this. Having now made the library publicly available as an open-source, open-use resource, we wanted to share with you some of the thought processes driving our engineering agenda.


We talk a lot at Yahoo! about heterogeneity, a word that describes an essential part of our company’s challenge across numerous disciplines. With respect to improving our shared JavaScript libraries at Yahoo!, heterogeneity defines the problem in two important ways:

  1. Heterogeneity of the Yahoo! Product Family: Yahoo! products are diverse in terms of their size, the technologies we use, our development methodologies, and our locations geographically. More importantly, perhaps, our users and their needs vary significantly from product to product. As a result, some properties have been able to implement very rich feature sets, whereas others have proceeded more conservatively in defying the page-granular interaction paradigm that came to define the first decade of the mainstream web. Given this context, the library needed to facilitate application enhancement without dictating too much about how architecture, methodology, or coding style.
  2. Heterogeneity of client configurations: Yahoo! has, by some internal estimates, more than 10,000 different client configurations accessing its products on a regular basis. While we can distill that into more manageable groupings (like “IE 5,” “Safari 1.3,” “Netscape 8+,” “Mac FireFox 1.5+,” and so on), there remain dozens of viable browser/platform combinations in use by millions of people each. Writing JavaScript for dozens of run-time engines and accessing dozens of implementations of DOM methods can be a recipe for paralysis — it naturally leads to conservatism with respect to making commitments for advanced features. A library that serves the needs of developers facing this degree of client-side heterogeneity must first and foremost build upon a coherent philosophy of browser support. Nate Koechley has been working on this effort for several years at Yahoo!, and he shared our philosophy publicly for the first time in conjunction with the release of the library earlier this week. Growing out of that important work, our library had to provide normalized access to advanced functionality while supporting all of what we’re calling the “A-grade” browsers.

In these two important ways, the creation of a JavaScript library with maximum usefulness for Yahoo! developers involved being sensitive to the heterogeneity that’s at the core of the front-end engineering discipline. This led us in the direction of modular components and an à la carte implementation style, one that could be used in a lightweight, unobtrusive way as properties began to add specific rich interactions to existing pages. By the same token, the library in the aggregate should provide broad support for properties whose design ambitions were more transformative, who wanted to create extremely rich and fundamentally event-granular applications. And that support had to be relatively unconstrained in terms of development methodology and programming style. While we love Rails creator David Heinemeier Hansson’s description of how “constraints will set you free,” we couldn’t serve well our developer population if we didn’t acknowledge in the library’s design that their environments were already large, complex, and not susceptible to radical change. The library had to impose few constraints and live happily in a lot of different ecosystems.

The Browser as a GUI Platform

If heterogeneity drove our decisions about how to architect the library, it was an old picture of an upside-down triangle that influenced us most in creating a roadmap and an organizational structure for our work.

The browser environment today shares significant common ground with where the desktop GUI industry was ten or fifteen years ago: Toolkits are comparatively new, platforms are awkward, and it’s too hard to bridge the gap between a great interactive design and real-world, cross-platform engineering implementation. While part of the problem lies in the fundamental protocols of the web, which was never meant to be a platform for deploying desktop-like applications (at least, not without the help of a Java plugin), a significant part of it lies in the browser itself. Modern browsers are tantalizingly close to making rich application development realizable and robust, but the work is still too hard and the foundation too wobbly. Early Macintosh and Windows developers often felt just this way in the early days of the desktop.

In 1995, Alan Cooper (in About Face: The Essentials of Interaction Design) created a model for how to think about the GUI ecosystem, and that model — he wrote about the desktop, but it’s enormously relevant to today’s browser — provides a wonderful picture of how an in-browser toolkit serves the larger goal of creating exceptional user interfaces:

Cooper's GUI canon

For Cooper, the basic granules of interaction were called “primitives” — the mouse click is a primitive unit of input; combinations of primitives that took on more coherent units of interaction or intent were considered “compounds”; from compounds, application-specific “idioms” could be authored.

We took Cooper’s model and re-cast it in terms of the browser and specifically in terms of the challenge of creating a toolkit to enable effective GUI development for web applications. Components that dealt with Cooper’s “primitives,” the most granular elements of interaction, we called utilities. Among our utilities, some (like Connection Manager, encapsulating XMLHttpRequest transactions) don’t have any intrinsic visual characteristics and so would be, in Cooper’s model, perhaps something like a “sub-primitive.” But that’s how we thought of that bucket.

Having built five utility components targeting the rich interactions most in demand among Yahoo! user-experience teams, we’ve turned our attention more recently to the level Cooper calls “compounds,” to a class of components we call “controls.” We consider controls to be highly recognizable visual presentations that allow users to interact with information quickly and intuitively. Controls, like Calendar, Slider and TreeView in our initial library release, should be familiar to users from the desktop world, should require virtually no discovery or learning in terms of their basic interaction, and should be easily invoked on the web page with just a few lines of code. The desktop paradigm, of course, has dozens of widgets; we don’t aim to be that comprehensive, and yet it’s clear that a lot of work remains for us to more fully populate our collection.

An interpretation of that canon, applied to web application design

As this foundation of utilities and widgets grows in depth and breadth, we hope that application designers will be more free to create what Cooper calls the “idiom” of the application — that set of interactions, workflows, shortcuts, and visual treatments that allow a user to get into a highly productive sense of oneness with her underlying data. Great idioms, not great libraries, toolkits or frameworks, are the essence of great applications.

Going Forward

We are early in the process of building the Yahoo! User Interface Library. Fundamentally, we see this as a body of components that maps to Cooper’s inverted pyramid — utilities that normalize and add power to basic interactions in the browser and controls that provide a rich, familiar set of interactions within the interface. There is no magic pixie dust here: Good application idioms emerge only from diligent research, inspired design, and a committed engineering process that draws on all available tools at hand. This library is just one of those tools, and ultimately a small (though, we hope, useful) part of the much larger process.

Going forward, our goal is to improve the existing utilities and add new ones where we see good opportunities. At the same time, we’ll work hard to diversify and improve the family of controls from which designers and developers can draw. We won’t be publishing a detailed roadmap for the library, although we’ll try to provide clear guidance when new work is imminent; we’ll try to strike a rational balance, giving you a sense of what you can expect only when we’re on really solid ground from which to do so. Stay tuned to the blog for ongoing progress updates, and if you’re a developer interested in using the library please consider joining the Yahoo! Group on which we’re discussing the components and their use.


  1. Your experiences, insights, and especially the context of such a huge pool of users faced by the Yahoo! team is of enormous benefit to Web developers working on a smaller scale. Thanks for sharing, the code of course, but more importantly for the documentation and the process!

  2. What most of us developers would like to see is a collaboration between Google, Yahoo, Mozilla, MS and others to provide a single library that can be cached between sites (or dare I say preinstalled). The problem is that with small sites the current JS libraries and AJAX aren’t really practical since they require a huge download upfront. Yes they will be cached but thats only relevant if you have a large site.

  3. [...] The Yahoo! User Interface Blog has written a fantastic explanation (and very technical, too) of how browsers as a GUI platform resemble early desktop development. Creating rich desktop-like applications through a browser is facing similar challenges that desktop applications faced over a decade ago. They’ve taken a concept written by Alan Cooper called the the ‘GUI ecosystem’ for desktops and applied it to JavaScript development for browsers. The concept structures various levels of user interface into a hierarchical pyramid based on complexity. The benefit of this is by modeling code into ‘tool-kits’ keeping the ‘GUI ecosystem’ in mind as Yahoo! has done with its User Interface Library you can develop exceptional user-interface widgets for your web page. [...]

  4. Yahoo Gets It…

    Eric Miraglia at the Yahoo! User Interface blog talks about creating their JavaScript library. One point  he touches on is the hetrogeneity of client configurations, and how that underscored the need for a robust cross-browser toolkit:Writing Java…

  5. Yahoo! User Interface Blog, helps a lots for web developer like me to have a deep understanding of web usability and lots of very interesting yahoo developers views… thank you guys for sharing such a valuable information with us… thank you…YaHoO!! :)

    Balakumar Muthu

  6. Yahoo! Makes User Interface Pattern Libraries Public…

    Yahoo! is making portions of their Design Pattern Library and user interface code available to the public under an open-source license (via O’Reilly Radar). They’ve also launched a User Interface……

  7. Krishan Patel said:
    February 22, 2006 at 3:03 am

    This looks good, but I think you should keep accessibility in mind and also how a page functions when JavaScript is disabled. Sounds silly for a JavaScript library, but this is part of overall good web design, and your examples should therefore show JavaScript used sensibly.

    For example, some of the calendar control examples should show how to use your libraries sensibly. The travel site seemed good as there are alternative inputs. (I didn’t check if that little calendar icon itself was created using JavaScript). However, some of the other examples like multiple selection etc, while I appreciate they are demonstrating the technology, should also use that opportunity to show, or at least discuss what you should bear in mind for accessibility (where JavaScript can still be used), and where JavaScript is disabled (to show developers how to allow users to still access the underlying functionality.)

    Else, this is good stuff!!

  8. James McKinney said:
    February 23, 2006 at 3:46 pm

    On, the first 4 links under “What Does Yahoo! Offer?” incorrectly point to travel and shopping, which are the next 2 links.

    Also, where is the Feedback/Contact link on There is none, anywhere. It’d be nice to have one under the “FAQ” link in the left sidebar.

    Feel free to contact me at my email address if you need to. (Does any blogging platform support reply notification? That’d be a nice feature. And, personally, the intermixing of pingbacks with comments breaks the thread of the discussion.)

  9. James McKinney said:
    February 23, 2006 at 3:52 pm

    P.S. I should receive some notification that my previous comment is going to be reviewed before it is published. My immediate reaction was to think that it wasn’t sent (maybe it wasn’t?). Also, like Yahoo!’s own guidelines suggest for writing reviews, people like having a “Preview” button. I think it’s true for blog comments, too.

  10. Yahoo! Design Patterns and User Interface Library…

  11. [...] we opened up the YUI Library in February, we talked about some of our motivations for creating an entirely new JavaScript toolkit. One of those motivations, [...]

  12. Feel free to contact me at my email address if you need to. (Does any blogging platform support reply notification? That’d be a nice feature. And, personally, the intermixing of pingbacks with comments breaks the thread of the discussion.)