A few weeks back I had the awesome opportunity to speak at the jQuery Conference in Boston. A colleague, Boaz Sender, encouraged me to propose a topic, but I couldn’t help wondering, “What could a dojo enthusiast possibly speak about at a jQuery conference?”
Speak about dojo? Uh, no way. That wouldn’t fly.
CSS, jQuery, Non-programming, OOCSS
I’d love to dive right in and show you how it all works in cujo.js, but you’ve got to have a firm understanding of OOCSS for any of it to make sense. Let’s get started…
It’s no secret that one of the keys to a decent user experience is a responsive (fast) user interface. And the most critical component to a fast web app is minimizing the HTTP requests. So it’s no mystery that people are working on ways to solve this problem.
Firefox, of course, is one of the leaders in this area. Their proposal started out fine. Here’s a sample of what it would look like (if you didn’t read the article):
But for some reason, this concise, nearly-valid implementation was trashed in favor of a terse, unfamiliar, and nearly unusable alternative. Here’s what the spec looks like now:
<html packages='[pkg1.zip img1.png script.js styles/style.css]
In this bastardization, the packages are specified as an attribute on the document element (
<html> tag). Package definitions in the
packages attribute are delimited by square brackets, and the resources within them are delimited by spaces.
WTF? Not only is this ugly and non-standard, but it also has some serious drawbacks. Here’s why:
CSS, cujo.js, dojo, HTML / DHTML, In-browser MVC
The Cujo Project is finally underway.