At the day job, they are preparing to switch javascript frameworks. Which makes me sad, because I chose the current framework, Dojo, and I am still a fan. But, in fairness, they are stuck on Dojo 0.4.3, and the world has moved on, and I'm not on that project anymore. But... this has got me thinking about frameworks.
Framework or library or toolkit? Oh my!
There is a tedious, but regretably common argument about what to call these things, these named piles of javascript. The discussion is tiresome because there is obviously no consensus on how to define the terms and the bright lines that divide them. So I will freely use a number of similar terms as if they are all synonyms. Which, in my view, they are.
The bespoke option
If you are a good javascripter, it is really, really tempting to just start on your own library. And you should. But, you should build it on top of one of the existing libraries. Stand on the shoulders of giants, as Isaac Newton says.
Why? Try reading through the source code for Dojo. It is peppered with inline comments about code that was added or re-worked to allow for edge cases, browser differences, and security vulnerabilites. I submit that there is just no way that you or your crack team can keep up with the constant evolution of browsers, css tricks, and hackers. So don't try. Trust your friends at Dojo and Prototype and Jquery and Yui.
Major Powers
Javascript frameworks, like all open-source projects, benefit tremendously from network effects. More users equates to more message-board traffic, more documentation, more patches and enhancements. It is interesting, in the academic way, to study lesser-known frameworks. But you are crazy to put your shoulders behind anything other than one of the existing major powers:
- jquery
- prototype+scriptaculous
- dojo
- yui
If you have actual expertise in one of those systems, then you can also look into:
- mootols
- mochikit
These last are not thriving, but they are mature, and seem unlikely to be abandoned.
Big Ideas
The people who wrote the sytems listed above are smart, and surely they understand both the drawbacks of bespoke systems and advantages of network effects. So why did they bother? They each had a big idea:
- jquery
- css selector style queries, and chaining
- prototype+scriptaculous
- correct all the obvious ommisions by extending javascript, make gee-whiz visual effects easy
- dojo
- what if prototype didn't clobber the global namespace, and resembled java?
- yui
- what if dojo had good (or any) documentation?
- mootols
- what if prototype had good (or any) documentation?
- mochikit
- porting python idioms to javascript
Note that those are the ideas that launched the projects. Time marches on, of course. Good documentation is no longer a mark of distinction. Everyone has css selector queries. Chaining is supported to some extent in all the systems now. Dojo, in particular, has aggressively adopted all the other big ideas in their current release.
Is it worth knowing what the original guiding idea was for a library? I would say that jquery, mootools, and mochikit have stayed true to their original visions. So in those cases, yes. OTOH, prototype, dojo, and yui have evolved, drifting towards a shared understanding about what works best. For those three, it is important to forget what their original idea was. Reasoning about those libraries based on their origins will be foolish.
Axes of Comparison
Everyone loves checklists and rankings. But not surprisingly, there is more than one way to skin this cat. We can compare frameworks by choosing some axis, and plotting the competitors. What axes are available...?
Page weight
Size matters. You can do a lot with a framework that weighs in at over 100k. But... 100k? What if you just want to apply a yellow fade to all the elements with the class name "foo"? You can do that with less code, which will download faster, which is still quite important on many sites. OTOH, all the frameworks are sensitive to this concern. 130k seems to be the upper limit these days. With minification and gzip transmission, that translates to 30k over the wire. I wouldn't be a slave to this axis, but it is a contributing factor in most selections.
The major powers fall into two buckets: jquery and mootools are medium size. The rest are big. There are some micro-libraries out there, which get little attention because they don't do enough. But you should find and master one of those anyway. See High and Low below.
Language Extension
Javascript is a spare language. There are obvious ommissions, and nice-to-haves, and lots of other opportunities for extension and enhancement. Some frameworks take this farther than others. For some of us, extending the language is really important, because it enables us to easily develop the larger applications we aspire to. For others, they don't care to extend javascript, because they just want to apply a yellow fade effect to some elements.
- prototype
- dojo
- yui
- mootools
- mochikit
- jquery
I give prototype the nod here in a backhanded way. As Phil Windley noted recently, prototype changes javascript. Dojo and Yui push the language just as far, but inside the envelope of their namespaces.
API Surface Area
Some libraries try to be all things to all people. Some don't. Others try artfully to occupy a middle ground. This is an interesting axis of comparison. It rolls some of the other axes together.
- dojo
- yui
- prototype
- mootools
- mochikit
- jquery
Winning this axis is a good news/bad news situation. A vast API surface turns off a lot of less ambitious developers. Yui is slightly more popular than Dojo, probably because they do a good job of presenting their api in digestable chunks.
Expressiveness
This is an axis that javascripters are passionate about, but their bosses are not. An expressive language is, (as DHH says) beautiful, and brings happiness.
- jquery
- dojo
- mootools
- mochikit
- prototype
- yui
Jquery is the bees knees here. Dojo made a huge improvement starting in summer 2007 when they flattened their heirarchy, added queries and chaining, and paid some attention to syntactic sugar. Mootools two places ahead of prototype? I'm playing a hunch that mootoolers strive for clarity and pattern-based programming. Prototypers are more tactical. But then, you could tar all of javascripting with that brush. Yui, what are you thinking? Your api is vast and powerful, but the resulting code is ugly!
Decorator or Builder?
When you think about it, there are two likely uses for javascript:
- decorate and manipulate the elements on the page
- manage a browser-based application
There is a third use-case, I suppose. You might want to use and create widgets. Although this doesn't feel like a browser-based application, it turns out that your small apps (widgets) need all the same stuff as a full-page app. So I lump this into the second bucket.
- jquery
- prototype
- yui
- mootools
- mochikit
- dojo
No numbers this time, because I want to recognize that this axis is a continuum. If you want to decorate, you lean toward jquery, and if you want to build apps, you lean towards dojo. Yui is pushed to the middle because, again, that is how Yahoo presents it to the world. Of course, it can give dojo a run for the money, feature-wise.
This axis strikes close to home for me. When I chose dojo at the day job, I knew exactly what I was up to. I wanted to build apps, and having dojo handy would make that easier. But arguably, we are not an app-style site. Decoration is our bread and butter. So I acknowledge the argument for change, even as I mourn the loss of dojo.
High and Low
The smart javascripter will master one big framework, and one small one. When I say small, I mean look for somthing with a micro-payload of under 10k. No one can begrudge you using a 10k library on a page! You can even inline it if you have to. Use the small one when you can, use the big one for everything else. Messing around with the medium-size libraries seems like a bit of a waste at this point. BOCTOE.