32

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?

Tyler
  • 873
  • 8
  • 16
  • More discussion of this at the JavaScript reddit: http://www.reddit.com/r/javascript/comments/h21vr/what_does_douglas_crockford_mean_when_he_says/ – Tyler May 02 '11 at 08:35
  • 4
    It's curious that 3 of 4 answers start with some variation of "I haven't seen the video". How exactly can you clarify what Mr. Crockford meant without watching the video? – Corbin March May 03 '11 at 19:36
  • Well, he didn't say very much. As one of the answerers said, it was kind of an offhand remark in the Q&A section at the very end. But you do make a good point. – Tyler May 03 '11 at 22:37
  • Without watching whole video, I can say that using jQuery *by itself* doesn't scale well to single-page applications. The reason is that you don't get a model-view-something framework to organize your code around. Combine jQuery with structural frameworks such as [Backbone.js](http://documentcloud.github.com/backbone/), [Knockout.js](http://knockoutjs.com/) and/or [Sammy.js](http://sammyjs.org/), though, and it scales very well indeed. – user16764 May 02 '11 at 16:12
  • Haven't seen the talk, but my 2c here is that the plugin-centric nature of the beast combined with the lack of guidance and tools for loading dependencies leads to apps where you've got jQuery plugin soup as someone on the team needs some plugin for a specific task, said plugin gets included app-wide and eventually you end up loading 342 different jquery plugins across the whole app. It is kind of the nature of the beast -- it is designed to make the smaller-scale stuff easy at the cost of not having big upstream concepts to grok. – Wyatt Barnett May 02 '11 at 19:45

3 Answers3

41

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). .

jon
  • 411
  • 3
  • 3
3

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.

Peter Mortensen
  • 1,050
  • 2
  • 12
  • 14
Twipped
  • 187
  • 2
  • 1
    Hm. I'm pretty familiar with jQuery, but not very familiar at all with YUI or any of the other JS frameworks. So maybe I should have asked, what is it about YUI, Prototype, etc. that make them good for building large, scalable web apps? Instead of asking what jQuery *doesn't* have... – Tyler May 02 '11 at 08:32
  • 6
    "It's pretty uncommon to find any very JS heavy sites using jQuery"....while we're making stuff up, can you make something up about YUI requiring less than 10mb of files? – ken May 02 '11 at 16:29
  • @ken If you're loading the entire YUI library onto your page then you're doing it wrong. There's a reason Yahoo offers a dynamic loader. And if you disagree with my assessment, provide examples to the contrary. Show us a large scale application built on jQuery. – Twipped May 02 '11 at 17:45
  • 4
    Define "large scale" then. The SE stack uses jQuery. – ken May 02 '11 at 18:30
  • SE is not predominantly JS driven, it uses jQuery the way most everyone uses jQuery: Basic Event binding, simple AJAX requests, some DOM manipulation. Large-scale means whole applications built entirely on JS; non-page based sites. We're talking stuff like what I mentioned above (Mint.com & MobileMe), Cloud9 Editor, gMail, Mockingbird. Sites that are at or above 1MB of JS code written in-house. – Twipped May 03 '11 at 01:21
  • Ok, now that we're at the heart of the matter, I'd just like to point out that jQuery is a library, and not a framework, and thus if you treat it as a framework it's going to fail specularly. Perhaps I should admonish Crockford and not you, but it's the same misconception. I guess I should also point out that *ALL* of the other JS projects that you mentioned explicitly bill themselves as "frameworks", while jQuery only claims to be a library ('do one thing and do it well' vs 'kitchen sink'). Apples != oranges. – ken May 03 '11 at 21:54
  • Isn't SproutCore based on JQuery? To me that means that JQuery does scale well, it is just a smaller subset of what you need for a lager JavaScript application. – Pullets Forever May 07 '11 at 01:57
  • SproutCore includes code from jQuery and from Prototype, but is much larger than both. It's a full framework package. http://guides.sproutcore.com/getting_started.html – Twipped May 10 '11 at 21:47
2

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...

Peter Mortensen
  • 1,050
  • 2
  • 12
  • 14
Cohen
  • 161
  • 4