When we first began development of Review Board and its Django utility package Djblets almost two years ago, we needed to pick a JavaScript library to use. There were several good ones available at the time, and after evaluating several options we chose the Yahoo! UI Library (YUI) and YUI-Ext, an extension library to YUI. Both were excellent and have served us well over the past two years.
However, YUI-Ext itself is really no more, which means we needed to choose something new. We could have continued to bundle it and YUI with Review Board, but users of Djblets would have to hunt down a copy and load in all of YUI and YUI-Ext just to use such features as datagrids. This was, to say the least, inconvenient.
YUI-Ext and the Licensing Situation
Now I said YUI-Ext is no more, but really it’s still around, just in a new form. It had been renamed to ExtJS and became its own independent library. While compatible with YUI, most of the functionality we needed was really provided by ExtJS, meaning we didn’t really need both. Over time, YUI evolved as well, so we began looking into the differences and figuring out which to go with.
ExtJS, it turns out, was a non-starter for us. Unlike YUI-Ext before it, the ExtJS licensing terms were a bit restrictive and, frankly, confusing. Open source projects could use it under the GPL3, but commercial products required a special license per developer, which is $289 per developer. The GPL3 itself is unclear with regards to our situation. We’re an open source project, but we’re MIT-licensed. What if a company wants to modify something for their own use and not release it to the public? What if down the road someone wants to offer commercial extensions to Review Board? We’d have to choose the commercial license to be safe, but then contributors would also need to pay $289 for a license, wouldn’t they?
Looking Again at YUI
We didn’t want to step down a dangerous road with ExtJS, so we started to look again at YUI. It’s definitely come a long way and I must recommend it for developers looking for a strong toolkit with good UI support. They provide good documentation, many examples, and base functionality for nearly everything.
However, there’s a lot we’d have to rewrite to move to it, and if we had to rewrite the code anyway, I wanted to look around a bit at the current generation of JavaScript toolkits. Especially since our needs have changed over the years and we’re looking for something with a lighter footprint. We’re also moving away from the dialog-centered UI we have on some pages, which is where YUI shines.
jQuery
We ended up deciding to go with jQuery, partially because of the footprint and partially the clean way in which scripts can be written. As an experiment, I converted our Djblets datagrid code to jQuery. The result is a smaller, much more readable, reusable, cross-browser script. I was impressed by what jQuery let me do, and by the size.
I did some comparisons on the number of files downloaded and the size of the files, using the Review Board dashboard as a test.
With YUI and YUI-Ext, we were loading 7 JavaScript files, excluding our own scripts, at a total size of 376KB (when minified).
With jQuery, we loaded only 2 JavaScript files, at a total size of 128KB.
Our datagrid.js file also went down from 13KB to 9KB largely due to some of the niceties of jQuery’s API.
This is a pretty significant savings, a whole 252KB, which could be a couple of seconds on an average DSL line. And it’s not just the file size but the number of requests, which can make a big difference on a heavily accessed web server.
What This Means for Djblets
Developers using Djblets can now use datagrids without needing to do anything special. Djblets bundles jQuery, which it will use by default unless you choose to override which jQuery script is being used. This means all you need is an install of Djblets set up and you’re ready to use it!
Going Forward
We’re working on migrating the rest of Review Board to jQuery. This will take place over the next few weeks, and is one of the last major things we hope to do for our 1.0 release.
jQuery Rocks!!! That’s all.
Just a note: AFAIK stackoverflow.com uses jQuery as well, and as result some features on that site don’t work in Konqueror (I couldn’t quite gather where the bug is, but it is there). So extensive tests of your site in Konqueror (and browsers with similar JS engine) might be useful 🙂
Good to know, oliver. Though, Review Board didn’t work in Konqueror with YUI/YUI-Ext before anyway, so at least it’s not a regression 🙂
Actually, number of requests is pretty much the _only_ factor for speed when you’re in a different continent.
A roundtrip from Australia to the USA can frequently take 400ms. Javascript and CSS usually has to be downloaded before the browser will render a thing, and all browsers seem to serialize those requests, so assuming that you had 7 javascript files and 1 CSS file, that’d be 3.2 seconds before _anything_ would render, even if each of those files were a single byte in size. In contrast, assuming 1.5Mb ADSL, you could have a 500kB single javascript file and the page would still render faster than the one with 7 single byte files.
The discrepancy gets worse when you start talking about ADSL2 – I frequently wait for longer than it would take me to download an entire song for webpages to render their very first word simply because there’s way too many individual JS and CSS files
Have you used Prototype before? I’ve been using it for a few years, but I’ve never used jQuery, so I’d be curious to hear a comparison of them.
I think with the GPL you only need to publish the source if your going to to charge for it. You can use it internally just don’t sell it. Which makes things weird since you don’t sell websites, you make one and people use it.
Its more of a service.
Jer: I have. At the very beginning, Review Board ran on scriptaculous and Prototype, but as we began to do more advanced interaction, those libraries didn’t really help us much. However, it’s been a while since I’ve looked at either of those, but we basically was going to have to write a lot of the UI-level stuff ourselves, and it didn’t really give us the code quality that jQuery gives us.
One of the nice things about jQuery is that everything is plugin-based and everything chains. Unlike most toolkits where you end up creating some sort of an object and pass it an element, in jQuery the element is pretty much the context, and you do something interesting on it with a function that was registered by a plugin or the jQuery core. It’s something better explained in the tutorials and docs, but it means that everything looks consistent and reads well.
Al: ExtJS has its own special restrictions on top of the GPL. The broader licensing restrictions would force us to release under a commercial license if we wanted to allow people to modify code within their company or if people wanted to write commercial addons to Review Board.
In our case, Review Board isn’t just a website. It’s a distributable web application with an API and we know it’s being integrated with commercial, proprietary codebases. So the GPL3, and especially ExtJS’s licensing restrictions, makes it impossible for us to use it.