Das Bloat

I just had a quick look at Yahoo’s UI library. In particular, the TreeView control. I’m on a broadband connection and the demo page took 12 seconds to load the necessary JavaScript. Here are the files it downloads and the associated file sizes:

File NameFile Size (bytes)

I realise that the demo page uses uncompressed files. But that is still a lot of code just to generate a tree view.

Comments (17)

Leave a comment

The JavaScript files all have extremely verbose comments in them, used to generate the API documentation. The deployment versions really are a heck of a lot smaller :

event-min.js: 8472
connection-min.js: 5875
animation-min.js: 9934
dom-min.js: 10175
dragdrop-min.js: 20291

In dragdrop’s case, that’s just 25% of the commented file.

More importantly though, that demo page is loading a bunch of code that isn’t needed – the animation and dragdrop libraries for example.

That said, I’m personally much more excited about the dragdrop/animation/event libraries than the treeview and menu components. They’re just the right level of abstraction for me.

There’s a downside to everything. Fortunately the technical skills brought to developers by Yahoo UI outweighs the negative design patterns. I think we’ll survive.

Note that the code is commented heavily. It’ll probably cut down by 60% once the commenting is removed. Compress the result.. <100k? Woo! Less than 100k of javascript!

  • Comment by: Rahul
  • Posted:

The part about the Treeview component that drives me nuts is not its size, but the DOM structures that it generates. C’mon, each node is a nested table using td’s to left-pad the expand/collapse button. What’s up 1994?

  • Comment by: Justin
  • Posted:

I’m on a broadband connection as well, and it took 3 seconds (tops) for the demo page to load. I think that is very acceptable once you factor in the caching abilities of modern browsers–the code will not be downloaded often.

Im here on Justins site. Using Treeview is nothing new and we used them a lot with ul listings.. but tables?

  • Comment by: Thomas Subera
  • Posted:

20 second with “italian trash broadband“.

  • Comment by: Davide
  • Posted:

It is quite exciting, what a man can do without libraries.:)Still, with clever use of Gzip, a reduction in size would be possible, and of course, removing the comments would greatly help like it is mentioned here.

@Emrah – Internet Explorer has problems with Gzip so we should probably avoid it.:-(

  • Comment by: -dean
  • Posted:

[…] epressingly this is the one other people seem to care about more. Code size, Dean Edwards noted this problem with respect to Yahoo’s library, a tree menu in 250kb (or maybe 100kb […]

Does anyone else pronounce Yahoo UI as Yahooey?

  • Comment by: Aaron Ullom
  • Posted:

I had the same idea before and wrote my own rant, very similar to yours, on some mailing list, so this time I’ve actually tested it.

I’ve only tested expand/contract all nodes, but that’s about all there is to test about it. There are only four files required for the treeview to work: yahoo.js, event.js, log.js, treeview.js. If you take them all and compress them with your JS packer, the bloat comes down to 15481 bytes. I don’t really know if it’s much or not, but I don’t think it’s overly bloated.

On the other hand, I was appaled that the example doesn’t work in Opera but I’ve only checked in a beta of Opera 9, perhaps it just doesn’t work due to some bug in that particular build.


A lot of the tree view components I have seen which have the dotted lines in the treeview margins use td elements, and rightfully so, it’s easier. You could use ul/li for the main structure sure, but when you want some precise horizontally formatted rectangles, basic ul/li most likely is going to be very difficult (I haven’t seen one that uses only ul/li elements and has the dotted lines). You wouldn’t think such a petty feature would complicate the markup so much, but it does. I’m all with you on semantic markup, but for complicated GUI widgets that require pixel perfection, combined with the limitations of browser implementations, semantics go out the window. I like the treeview components that can create themselves from a set of nested ul/li combinations, that’s pretty cool.

  • Comment by: Zac McCormick
  • Posted:

[…] Yet the growing list of components is very rich. For instance, the Calendar component supports several languages and multiple date selections, and the Container classes give you the power to implement all kinds of windowed interfaces. One downside of using these components is that they tend to be very heavily dependent on the other libraries; in discussing this, Dean Edwards highlights as an example the treeview control, which uses around 260K of JavaScript. […]

The layout of the .JS files is for developer benefit, not production purposes. It’s to make it easy for people to read through and learn from. Hence download performance is not a fair way to judge this demo version.

In a production environment you’d use a build script (like ANT) to compile the specific files your app needs together and run other useful build processes on them, for example; JSLint, JSDoc, and Dojo’s JS compressor. That way you get fewer Kb and one HTTP transaction instead of a dozen.

  • Comment by: Richard Marr
  • Posted:

Yahoo! User Interface Library Creo que mi búsqueda por la única y verdadera librería para JavaScript ha terminado. Después de haberle sido fiel Prototype durante casi más de un año (que utilicé para Zebda, Presentacular) y haber eval…

  • Trackback by: cavorite
  • Posted:

If the browsers gave developers more control over caching, I’d be a lot less worried about final JS size. On a side note, have you ever looked at a Google JS file? Talk about reduced! No comments, 2 letter variable names, everything on one line, etc.

  • Comment by: daniel
  • Posted:

Giving developers control over caching may turn it messy. JS final size is what should be controlled or limited, or you may find yourself facing oversized JS files.

  • Comment by: Jim
  • Posted:

Comments are closed.