No.

Frameworks are all the same in that they are great at getting you to about 80% of what you need REALLY fast. The next 10% takes some investigation but its doable.

But that last 10%. Its like pulling teeth. You're working for the framework rather than it working for you. In my experience, all of the time gains you realize from using a framework early on are lost (and then some) trying to get it to do that last 10% that you need.

Ultimately I've found that using vanilla Javascript offers everything I need to just "get things done" and complete a project successfully. Sure, I might not be able to get something out the door in a day. But at the end of the project I've delivered clean, maintainable code on time. And anyone who knows Javascript will be able to read it.

Now, lest you think I'm a complete framework hater; they have their place. They're great at prototyping, for example. But never again will I build an entire project on one. I have little interest in being a glorified glue stick, piecing framework code together. How boring.

I should add that I make heavy use of libraries like jQuery and Underscore. They're libraries, not frameworks. Take what you need with them yet still reasonably lightweight. Frameworks are bloated, tightly-coupled, poorly documented monstrosities in my opinion.

I do consider some frameworks to be exceptions though. Express is called a framework but it looks more like a library for HTTP handling to me. Most npm packages behave like libraries - maybe that's why I like using Node.js so much. Also CSS "frameworks" like Bootstrap aren't in the same league. They've never caused me the type of frustration I've had with frameworks like RoR or Angular. Bootstrap is actually a library of UI widgets. They can call it a "framework" but I don't consider it to be one.

I'm pretty good, but I'm apparently not good enough, because I find myself consistently learning things from frameworks. I certainly am familiar with the Last Ten Percent you're talking of. But I also know that for every 10% that I have to pull teeth to get, there are many many things that work well because the platform team did a great job and drew on a depth of experience and expertise that I just don't have yet.

DHH built a lot of Ruby apps before he built Rails, and by using Rails I can draw on his experience. As a solo founder that's worth a lot to me. And even now, when I've largely moved on from Rails I still draw on things I learned from studying that framework. And the frameworks I use now are equal distillations of very deep experience.

You're perhaps a more experienced developer than I am, or just better suited to the job.

A much better way to learn is to go write your own framework. Then you're forced to encounter the pitfalls and overcome them through research, trial-and-error, and interacting with the community.

But continuing to use a framework is just a crutch in my opinion. At some point not only are you not learning anything but, as I mentioned before, all you're really doing is gluing framework code/modules together. You're actively doing yourself a disservice and letting your skills atrophy by relying on such a crutch.

One thing about frameworks that I find interesting is; how many were used to develop Unix? None. Because there weren't any back then. And now its in billions of devices worldwide.

I did this myself. It was crap. Fun to write, and I learned a lot from it. But still, monolithic, poorly documented, tightly-coupled crap and even I don't use it anymore.

Angular is the first time I've written a web-app and been completely lost from second one without a fully stateful JavaScript debugger willing to break at any point and letting me inspect the call-stack, parameters and locals.

Everything which was simple about the web up until now, Angular transformed into horrible, black voodoo magic which either just worked or didn't at all.

If that's what "re-envisioned everything" is all about, consider me out.

That's what radical re-envisionings always look like. Anything that fits easily into your toolbelt is an incremental improvement. That's what the word "radical" means.

The promise is that after doing some hard work to learn new data structures you will be more powerful, but it's certainly your right to be skeptical of that.

Is Angular the best approach? Is there even such a thing as a best approach? Probably not. Look at the proliferation of server side frameworks. They each have their pros and cons.

I do like that Angular is a real framework, rather than a library that only gets called a framework. It handles all sorts of stuff for you in the same way serverside frameworks tend to do.

From reading the Ember discussion lists I get the strong sense that the core team is willing to make difficult breaks, but that they really try to only do it when it's absolutely necessary for the long-term robustness of the platform. A lot of thought seems to go into which problems are getting solved now, which are put off til later, and which interfaces get torn out and rewritten.

I just spent several weeks upgrading my app from the earlier Ember RCs to Ember 1.0 and the latest Ember-data, and while quite painful, I feel good about it because I don't think the core team made those changes lightly. My sense is they are looking out for us.

From what I understand, big Ember projects have turned out well for Ember devs - I can confidently say that I feel the same way about big Angular apps. I have built several big ones, including an online assessment platform (frontend by myself) and an online assessment platform/management system (with a team of ~10, 3 of us on frontend).

From my experience, the Angular team has thought things out on a high level, which I greatly appreciate. They are big consumers of their own product, as Angular is used quite a bit with Google's own sites - here is an example of an Angular app, with Angular being used to implement parallax scrolling (and probably more): http://www.google.com/nexus/7/

It claims to be adding MVC support in the next release.