The flip side of this is that you end up building your own that is tailored to the particular requirements, users, and resources available to your product. That can be a huge advantage, given that differentiation is the only thing that will make your product stand out in the marketplace.
Are you in a latency-critical domain, which Google Search is? Then optimize to minimize the number of bytes shipped to the user and startup time. Do you have 100+ screenfuls of information? Then optimize so that making new screens is easy. Do users load your app once, leave it open in the background, but then need to perform a number of interactions quickly? Then ship down the initial interface quickly and progressively lazy-load bundles of functionality that are just a JS function away on click, like GMail does.
Incidentally, one of the main reasons Google Search finally adopted Closure was because it had to integrate with Google+, which was all done using Closure. So again, the choice of a framework was driven by product concerns.
It's not a failure when a company builds a home-grown framework that is carefully tailored to the product needs that they've discovered over the last few years. Indeed, having the resources and domain knowledge to build your own framework is a far bigger success than building an app with the hot framework of the month and failing because you look just like every other app out there.
How many apps in the World require a specialised framework that GMail might require? 10? 100? 1000? Sure, everyone can invent their own framework to be very "specialised" and "tailored" to a given app needs but is it going to give a competitive advantage for a given app? Probably sometimes. Probably not most of the time.
Constructing your own framework has cost. Sure, you will acquire a lot of knowledge doing it, but is it going to help the bottom line? Maybe.
Once again, are you seriously advocating that _everyone_ should do "vanilla JS" without any frameworks?
I'm advocating that everyone start with vanilla JS without frameworks. See how far it will take you. Once you've built a simple prototype, put it in front of users, made a few changes, and have a sense of how the product will evolve to satisfy those users, then you can choose a framework. And you can choose it with a lot more knowledge about what your needs will be than if you tried to guess ahead of time, and you won't be steered away from particular customer desires because the framework makes them difficult and other stuff easy.
Rewriting your product is not failure, particularly when done at the very early stages where it only takes a week or so anyway.
As a nice side benefit, this also avoids all the holy wars about which framework is best, since you can put off the decision until you have hard data about which is best for you.
If you're going to rewrite it anyways, then why not just pick a random framework? "No framework" is still a set of trade-offs, and for better or for worse, most teams aren't made of super star devs. A lot of them appreciate the hand-holding through the where-to-put-what drudge at the beginning of a project and the presence of a community to ask questions.
1.) Just by choosing to use a framework, you incur costs: download time, initialization time, complexity & bug surface area, etc. You should make sure that you gain benefits commensurate with those costs. If you start by picking a random framework, then a.) how can you measure what the costs were? and b.) how do you know what sort of benefits would be most useful to you?
2.) Relatedly, starting from a baseline random framework can teach you lessons that are not true, and then you base your product decisions on that. For example, there's a common meme that you cannot have smooth 60fps animations on mobile websites. This is not true; however, getting smooth 60fps animations on the mobile web requires careful attention to which elements will render on the GPU and which won't, and no framework currently in existence will help you with that. Back in 2008 when I did my first startup, it was generally believed that Javascript was too slow for games; not true, JQuery was too slow for games. Doing things that others believe to be impossible is the essence of competitive advantage.
3.) Frameworks make certain tasks easy at the expense of making other tasks hard. If you start with a random framework, you will be incentivized to do things in the same way that everyone else who uses that framework is. That's why almost every web 2.0 startup started from around 2007-2010 looks like a frontend over a database. Looking like everyone else is a recipe for failure in business.
4.) The framework authors are all subject to the constraints of the browser; however, browser vendors (and people who program directly to web APIs) are not subject to the constraints of the framework. The set of programs that you can write efficiently without a framework is a strict superset of the set that you can write efficiently with one.
5.) It's easier to add code than to remove it. If you start with no framework and then decide that you need one, you've written only the code that you actually did need for your problem. If you start with a random framework and then decide it's not appropriate, you need to backtrack and identify what you were actually trying to accomplish before you shoehorned it into the framework.
I think almost everyone actually understands that. What I'm not sure about is whether most of the people who say that are clear on the fact that may not be a bad thing.
Frameworks can have their own complexity and developer overhead, they can demand you spend more time solving the problems they impose (cough AngularJS), they can be ill-suited to the requirements and/or problem domain you're working in.
Building your own isn't always the sensible choice, but it can be.
This. A large codebase without a framework almost always becomes a defacto framework; else it becomes too much technical debt and is rewritten in a framework. =)
Right. I was more after examples of apps in the wild done by "average" (whatever it means) group of developers in an "average" dev shop. A group of rock-star developers will do "right thing" most of the time, regardless of the technology. The question is: can we scale this experience for majority of web applications that most developers keep on coding?