What does Douglas Crockford mean when he says jQuery doesn't scale?

Question

In the Q&A section of this talk, Douglas Crockford says that jQuery doesn't scale as well as some other popular libraries. What does he mean by that, and what is it about the other libraries that makes them more scalable?

Answer 1

If you watch the video, he doesn't talk about jQuery formally. It is a quick response to a somewhat offtopic question from someone after the presentation....at the end of the presentation, about minute 1:29.

He says a lot of good things about jQuery. The part about it not scaling well, he says he doesn't think jQuery scales very well for very complicated applications (comparing it to other things like YUI). .

Answer 2

It's hard for me to say without watching the video, but my guess is that it's because jQuery doesn't offer all the features of most other libraries that make JavaScript programming easier. jQuery's purpose is to make DOM manipulation easier by simplifying addressing of elements via CSS selectors, and providing an easy framework for altering those elements. It offers some other feautes such as Ajax requests, basic event management, templating, and some other rudimentary functionality, but that's about it.

Other libraries such as Prototype, MooTools, Ext JS and Dojo provide loads of other functionality for creating objects, managing arrays & collections, manipulating strings, and doing all the other nitty gritty things that we as programmers expect to be able to do.

In short, jQuery lacks the tools that one would want for large scale JavaScript applications. It's pretty uncommon to find any very JavaScript heavy sites using jQuery, for this very reason. For example, Mint.com is built on YUI. Apple's MobileMe web service runs on SproutCore (Apple's main site uses Prototype).

At least, that's what I think he means.

Answer 3

jQuery doesn't allow you a lot of reuse like MooTools for instance.

It's a philosophy/design decision: jQuery is not a lot of code for fire-and-forget scenarios.

When you are building unobtrusive JavaScript experiences (usually only page enhancements) this works very well and requires very little code. When you build Google Docs... not so much. You will want more OOP concepts that other projects expose like inheritance, interface-like mechanisms, etc...