Not to mention that these frameworks undergo alot more extensive testing than an average developers code will ever go through. By using a framework you benefit from not having to go through the pain of dealing with all the different browser models and quirks that every version introduces or takes away.

For really advanced or incredibly high performance tasks you might be correct but to me that is the 1% of tasks, for everything else a framework should give you all the scaffolding you need allowing you to instead focus on tasks that add real value into the product/service you are working on.

This is particularly what I value in open source frameworks - the hundreds, thousands, tens of thousands, maybe even million of man-hours that have gone into debugging edge cases, cross-browserifying, and finding security holes, stuff I would never be able to replicate on my own in any reasonable time frame. Especially the latter, given the security situation on the internet these days.

My SOP is, stand on the shoulders of giants, unless there's a particular requirement that precludes doing so. Such requirements are rare, most client work actively benefits from use of a framework.

What I don't do is make intrusive assumptions about the entirety of your application's architecture simply because you include my one little focused tool.

That's exactly how everyone else develops (but using open-source libraries): use a module system and glue together things from previous successful projects (made by other people). Why your own private framework is better than what is out there is a whole different matter.

Picking up bits and pieces from old code isn't a framework. Its a specific tool. Think of Backbone or Ember or Angular as a mechanic shop. Things work a very certain way. The copy and paste code from other sites is a hammer, or wrench. You don't have to use them a certain way, but when you have them, you can use how they are intended.

What I don't use, nor do I try to force on others, is the best ways to glue these pieces together. I have my ideas of "best practices", but those ideas are highly adjustable per site/app, and also just my own opinions. No piece I bring into a project makes an intrusive assumption about how the rest of my code will work.

I love the assumptions that because I write any amount of glue code, the code I write must certainly be less tested and therefore less quality than that which shows up in a popular framework.

That is a very reasonable assumption: code that is used by a dozen projects, with a few variations for each of them, is certainly less tested than code shared by a thousand different projects and developers using a standard API. It's not inherently flawed or bad, but a matter of numbers.

Also have in mind that frameworks vary wildy. Angular and Ember might be absurdly prescriptive, you have to do things a certain way, while Backbone and others are extremely flexible, merely a collection of useful patterns and tools.

---

Why do frameworks exist? They allow you to speed-up development, offer battle-hardened code, a consistent API, good documentation and proven design patterns, plus developers can make use of their previous experience with it. It's a matter of choice, and of course there are trade-offs, namely flexibility.

It's not about being "the standard", just providing useful tools. I bet you end up using a lot of the same components over and over, right? Package them up and call it the 'Getify Framework' and you're in the same spot.

I don't get why you feel that someone is 'forcing' you to do anything? You say that you write your own code because

    I already understood that (architecture) domain pretty well.
    I’ve done similar “single-page apps” dozens of times. I’m
    getting a little better each time I do it. I learn new lessons 
    about easier ways to mix the pieces together with each project.

Everyone seems to think that packaging up a bunch of tools is a framework. I would contest that that is wrong.

A framework has certain policies and flows that must be followed to allow the program to work. If you bundle up a set of tools, then you have a toolbox.

A framework might have a set of tools, but it also has a methodology behind it. If you don't subscribe to that methodology, then that framework isn't for you.

I am saying this, coming from the background of not using frameworks because of the bloat and because most of my applications weren't that large. I have used backbone and several other backend frameworks (python and PHP type) and found that they are restricting.

For me, programming, coding, hacking, whatever you want to call it is about the freedom to be able to do whatever you want, how ever you want. Yes, I know there are best practices, and there are certain things you aren't supposed to do, but a framework forces you think in a certain pattern, to follow certain rules. Yes, you may be able to develop faster (if your application fits in the scope of the framework) but you have lost much of the freedom that code gives you.

I understand people using frameworks. I sit right next to someone who enjoys them very much. But for others (including myself), they are not the next greatest thing to sliced bread because maybe I don't want my bread sliced, but instead, I want it some other way.

Unless it solves a specific problem you have, not using any framework will almost always mean more bugs, brittle code, a less consistent API, lots of documentation effort (or lack of) and a much larger learning curve for people other than yourself.

And, btw, it's not private. Most of my code is on github. I just don't try to force it down others' throats.