I think this article uses flowery language that makes it difficult to understand what the author really means, but if I understand correctly (and that's a big i

I think this article uses flowery language that makes it difficult to understand what the author really means, but if I understand correctly (and that's a big if) I agree completely. I think the core difference is this: jQuery is seen to be a 'JavaScript framework' when in actuality it's a library to make DOM manipulation easier. Of course, there's a few helper functions thrown in to do common things that are otherwise difficult to do due to browser bugs or poor vendor support, but that's incidental to its true goal which is DOM manipulation. The thing is, it just so happens to be that the clunky DOM manipulation is probably the biggest single weakness of in-browser JavaScript and jQuery addresses this problem extremely well - which is what has caused jQuery to be a runaway success. That brings us to what jQuery is not - it's not designed to be an all-encompassing framework designed to hide particular problems of the JavaScript language away from you. It's not really about encouraging programming 'patterns' - even if you're writing all your DOM work in jQuery, you still need to write plain JavaScript. This is different from Prototype or Mootools who try and add features to the JavaScript language itself. Any criticism of jQuery should bear these goals in mind. Looking at the success of jQuery, perhaps a single all-encompassing JavaScript framework which tries to do everything is a bad idea. Perhaps the correct answer should be to have (at least) two distinct frameworks with distinct goals: one for extending JavaScript the language and one for manipulating the DOM. Too many of the frameworks attempt both yet perfect neither - perhaps if extending JavaScript is a worthy goal then perhaps library developers should accept that jQuery now dominates the DOM domain and let people use that and work on a new library that can work hand-in-hand with it. Disclaimer: I'm as biased as hell. I like jQuery, I don't know that much about Mootools, I know enough about JavaScript. Take what I say with a huge pinch of salt. N.B. I think, but not certain, that the author misunderstands the jQuery plugin architecture. I don't see why you'd write anything that was called anything via 'jQuery(domId).pluginName("methodName", [arg1, arg2]);' unless you explicitly chose to - it is a bit ugly and I wouldn't recommend it. You call a plugin just like a native object - jQuery(elem).pluginName(args). Writing a plugin for jQuery is the same as writing a function in native JavaScript - you can use jQuery.fn.pluginName = function(params) { } to write a plugin that doesn't access anything internally - jQuery.fn however is simply an alias for jQuery.prototype. I /think/ jQuery.extend is used to add an element to the object so it can also access privately accessible functions (I'm really not certain though). http://docs.jquery.com/Plugins/Authoring http://docs.jquery.com/Plugins/Authoring has more info but is a bit ambiguous in places.