

What Really Makes One Framework Different From Another - qhoxie
http://clientside.cnet.com/best-practices/jquery-and-the-ajax-experience-programming-to-the-pattern-and-what-really-makes-one-framework-different-from-another/

======
halo
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>
has more info but is a bit ambiguous in places.

~~~
Retric
This is a great example of what I hate about java. There is a framework which
does x, y, and z but it's extremely generic. So you add a wrapper that works
for you and does x and y.

And then you call your wrapper 5 - 10 times.

IMO, the framework should also handle the simple case and let you overload
their logic when you want.

