[forkhammer]

Here's the brief answer, as I understand it: they're frameworks that provide model-view data binding, ease data/presentational decoupling, and (in some cases) provide single-page app (SPA) infrastructure in the mode of MV*. In short, they're designed to tackle some of the common complexities that arise when writing feature-rich multi-part SPAs.

You can do it all on your own, for sure, and I actually think that writing a complex front-end-heavy application without anything but jQuery is a really great way to show yourself the potential use of these libraries. It's not really super hard to write decent, well-structured and segregated code... but it does begin to feel, after a while, like you're spending your time hooking up wires you've hooked up before.

At that point, you either write your own abstraction, or you go looking for an abstraction that someone else (preferably smarter than you) will maintain.

[overgard]

That's just more buzzwords though. I mean, why do I even need model view data binding? I'm not saying it's not nice to have, but I've written some pretty complicated applications and I never really found data binding to be some sort of killer feature. It's generally struck me as a great demo feature that in reality I'll pretty much never use.

I guess I'd find these things more convincing if they showed me some sort of problem they're solving by showing how awful it would be without what they're doing -- because without seeing the actual problem they're solving, it kinda strikes me as the work of architecture astronauts. It all sounds great on paper, but when I go to use it I can't imagine even needing most of the features this article describes.

[forkhammer]

Well, they are buzzwords, yeah, but it's important to note that buzzwords become so because of their popularity and prevalence.

Why do you need model-view data binding? Emulating the responsiveness of desktop apps, for one, or having live-update capability. I wrote an app recently that let you add line items to an object, and the client wanted the cumulative fiscal information to auto-update without reload. I'd agree that the standard 'Hello, <your input content here>' example is overly contrived, but what about a field that calculates and updates tax owing as you type? That's not hard to write with just javascript, but when you do that about fifty different times in an application, having a convenient data binding mechanism is really convenient.

The other utility that I find quite convenient is DRYing up insertion logic--I hate that I often have duplication between server-side templates for existing objects, and some sort of client-side template for dynamically inserting new objects. Rendering it all client-side makes my life a lot easier when I want to add or change the surrounding template, and having the ability to do the initial render with a minimum amount of boilerplate is phenomenally helpful.

Those are two very real, very frustrating problems with which I feel any one of these frameworks helps a lot. I'm happy to go into greater depth if you'd find that helpful or revelatory.

[reedlaw]

It's like Rails vs. a custom web app. If you asked me to maintain an existing Rails app, I would feel pretty comfortable just knowing that it's Rails. If you asked me to maintain your web app that you build from scratch that doesn't necessary follow standard patterns like MVC, I'd have a much harder time.