It seems like there's a really good opportunity for someone to do something very helpful and make a site that compares and tracks JS frameworks. As far as I can tell, though, no one has, so maybe I can be excused for my ignorance if what I'm looking for already exists. What I'm looking for is a framework that deals with webpages as webpages, and deals with elements within an application as elements.
I kind of go back and forth on my feelings about MVC, but they average out right around apathetic skepticism, or ::rolleyes:: if you want. It's because there are a shit-ton of them and MVC is pretty easy to write code for, cause things have these very clean relationships. That's great for your data, it's great for your backend, yada yada yada. But it's pretty much shit for complicated interfaces. Views and models don't always line up. Views without models exist and still have state. Some states are important to the application, some are important to a given object, some are important only to a widget. You can shove all the shit on your page into the MVC idiom - and people do - in order to use an MVC framework, but I don't think that solves the real problem.
If you know of a framework that's primary concern is with organizing DOM elements and DOM interactions, please stop right now and go down to the bottom and leave a comment telling me about it. As far as I know, such a thing doesn't exist. jQuery's great for working with the DOM, of course, but doesn't make any attempts at organizing things or offering a hierarchy of objects. We now consider DOM interaction a bad thing, so more "serious" frameworks tend to shove the DOM stuff under the rug, deigning to interact with the page only when necessary.
I don't want to say a bunch of shit I've said before here, but that's just fucking silly. Structuring your code around abstract objects instead of the mechanisms by which things are actually made available and manipulated - DOM elements - is like having a perfectly organized closet while the rest of your house looks like something from the TV show Hoarders. It's low-hanging fruit, and it skirts the issue that's the most difficult to deal with and the most inseparable from the idea of a web application.
I've looked at a bunch of these frameworks. I'm not going to lie, I've only attempted to write apps using a few, and quickly got frustrated by the tradeoffs between limitations and simplifications they were offering. You don't have to agree, but I'm just saying: I'm a computer science major, one of not very many I know, and I find their approaches way too computer science-y. Writing an interface programmatically is one of the most painful things I've ever had to do (repeatedly, in VB), and that's what the frameworks I've worked with all devolve to once you're beyond the tidy CRUD model where MVC can give you genuine shortcuts. But, again, I'd love to know if I'm missing something.
I read a blog post about how fashion designers should learn to code recently and was kind of horrified by it. To me, it's a perfectly example of why not everyone should learn to code. Not because the solution was bad - I think polaroids are about as elegant as you're gonna get, personally - but because part of how a programmer has to train himself or herself to think is this kind of obsessive, examine the problem from every angle, think of every possible optimization pattern. We do need people who can think that way within certain contexts. It's useful when you're building an application. Or, say, a JavaScript framework. But it can and does bite us. We know what happens when we're wandering around unchecked with a hammer looking for things to use it on. (We use it inappropriately.) I feel like it's time to stop letting classical CS patterns inform the way we build JS frameworks and embrace the way the DOM actually works and is used and has been used, and build around that. When someone truly does that well, I think JavaScript will take another big leap forward, and we'll all wonder why it took so long for us to address the right problem.