This isn't a really important post, it's just something I think need's to be expressed and accepted; it must be accepted. MooTools, YUI, jQuery, Dojo etc. are great. They help a person with very tedious javascript techniques, speed up your applications, and make the UX much richer.
But they are not frameworks. I know this probably just seems like a semantics issue, but I want to make it clear that they are not frameworks, they are libraries. From http://dictionary.reference.com/browse/framework
frame-work (freym-wurk) / noun
- a skeletal structure designed to support or enclose something.
- a frame or structure composed of parts fitted and joined together.
- the construction or sale of frames.
- work done in, on, or with a frame.
A framework should be referenced only when your development is surrounded or incased by some structure. On the php side of things, this makes sense; an MVC based framework since every piece of code you write it part of the execution of the framework. On the client side though, it's not so clear cut.
While you can work inside of a client side library as if you were in a framework (eg. creating new, framework-specific, classes), most of the code you write is simply using the library to help it out. As an example, you attach event handlers, create and manage JSON, make ajax calls, etc. All of this you can do natively, or you can have the library help you out. But when you use one of the library's helpers, you're not tied to it. You're still writing native javascript, just short-cutting through the library's helper methods and naming conventions.
I'm not sure why this deserved a post, such a long post at that. I suppose as I learn more about true frameworks, I'm realizing that semantics like this really do matter. When I write in CI or Cake, I have to fall in line with their file, naming and folder conventions. I need to work inside of a controller, which is triggered by the framework. I need to define the interface in view/template/layout files, which are loaded and compiled by the framework. And I need to access the data set through their ORM, which is managed by the framework.
JavaScript isn't like that. Now while the specific cases I'm talking about (YUI, dojo, jQuery, Moo) are in my eyes libraries, that's not to say that there couldn't be/aren't client side frameworks. I imagine javascript/ajax driven applications (large ones like gmail or a few Ycombinator/startup's) have client side frameworks.
They have these systems in place where you have to work inside of them; the work is delineated among an MVC pattern, or some sort of separation of logic. I think that'd be really cool to check out, but because of the nature of javascript, I don't think it's as necessary as it is on the server side. Maybe I'm just saying that because I haven't really been exposed to one, but client side JS is more modular and sparse than server side development, and for that reason having a library to help you tap into short cuts makes tons of sense.
My last point though, is that while I'll always consider these javascript extensions libraries, I can definitely understand how some people would call them frameworks due to the way they use them. If you constantly are creating new framework-specific classes that follow standard programming practices (eg. hierarchy, casting, separation of logic), I think it'd be fair to see you're using the library AS a framework. I'm cool with that. Lets just be clear about how the extension is used by the general public.