As you've said, every large project that I've worked on, Google, Morgan Stanley, UBS, etc has used some framework or framework-like interface and abstractions. Large teams cannot function without some time of norm/standardization.

When I was at Google, there was a widely used application framework. It enabled getting services up and running quickly and allowed quick integration into other services at Google. New team members can join and quickly be productive. Some teams decided to roll their own stack and many of them turned into a hairy ball of mess.

It was still organization-specific, probably embedded with a lot of the organizational know-how, and tailored for Google's use cases. Which is maybe not the case with the public generic "kitchen sink" frameworks out there.

In the case of Google's tailored, use case specific code, they release their frameworks publicly. Angular, Polymer, Guice, etc are all what you describe, and all freely available to businesses outside of Google.

If your argument is that developers should look beyond the obvious "kitchen sink" frameworks and choose tools that match their requirements criteria as well as possible without adding in unnecessary features then I agree with you completely, but that argument is significantly different to "don't use a framework".

I don't necessarily disagree, but the fact they release so many different (and incompatible) frameworks should tell us something...!

There's an important difference between a library and a framework. Code reuse is great, norms are great, but they need to be composable, and they need to follow the normal rules of the language.

E.g. Spray is my favourite way of doing REST APIs and saves a huge amount of time, but it's a library rather than a framework. I write my own main() (which admittedly may well just be a one-liner that calls into Spray), and it doesn't dictate what other pieces I use - I can do dependency injection my own way or not at all, I can do my own ORM or none, I can use my own unit testing framework or none. I can refactor my Spray code in the ordinary ways of refactoring in Scala because it is just ordinary Scala, and if I want to understand what the library is doing I can click through to the definitions of the library methods which are again just ordinary Scala. For a large project we might all agree on a particular stack - Spray/Hibernate/Guice/JUnit, say - and we might even write some helpers for e.g. constructing a Guice context with Hibernate configured and pulling out the Spray service from it as a one-liner. But I'd still want those pieces to be libraries rather than frameworks as far as possible - I'd want inlining and changing that helper to be a supported use case, partly because it just forces good design (loose coupling, lack of globals etc.) and partly because making it possible for small subteams to experimentally swap out one small component for their piece is the only way one can ever improve on the stack.

What framework are you talking about ? Symfony or Silex do exactly that : "respects the principles of abstraction that the programming language provides". Spring does that too. Any framework powered by dependency injection does that. Only frameworks that try to be to smart for their own good like Rails violate basic separation of concerns. Furthermore, just have a look at most Go or Node web apps out there : globals everywhere, tightly coupled code, no separation of concerns, no dependency injection,direct db calls in controllers... All because "you don't need a framework with Go" or "Dependency injection makes no sense in Javascript", good to luck to the people maintaining these messes 5 years down the road. Not using a framework doesn't make a automatically a codebase better. A framework however can mandate some discipline,especially when based on IoC : on one side : the framework's code , on the other side : the user code and the only glue is the manifest declaring dependencies between the two.

Speak for yourself. I am not guilty of any of these in my large node applications. And I use no frameworks, just npm libraries.

That's what you think. What actually happens in many cases is that the developers get too busy with other work that is important to the business (e.g. working on the business value directly). At that point the internally-written framework has known bugs and issues, or maybe lack of documentation, but nobody has time budget to seriously solve them and so they keep using the internally-written framework with all its quirks. Once in a while a person who worked on the framework leaves, taking knowledge with him. The remaining people sometimes think "uh... this part so strange, why was it like this again?" but the guy who wrote it already left. And then once in a while someone new joins, thinks "this framework is shit" and ends up reinventing his own internal framework, with its own quirks, while not completely understanding the problems that the original framework was meant to solve. After a while the internal framework gets abandoned in favor of a standardized framework.

I've seen this happening too many times during my days as a consultant. An internal framework is fine if your business case changes slowly, and your team changes slowly, and the framework has been very well-maintained. Miss any of those things and the framework eventually becomes a liability.

So if you're a one-man company and you intend on staying that way, and your business case doesn't evolve quickly, fine. In all other cases though...

I would agree that it's almost always best to use a library where possible, preferably one that's widely used and very mature.

The author's point seems to be informed by being burned by many bad frameworks (which is, to be fair, 90% of frameworks - if you pick based upon fashion driven development this is the hole you'll end up in).

A good framework is rare but immensely valuable. A bad framework is worse than no framework at all.

In some ways, once an organization has really settled into a set of linting rules, testing coverage requirements, shared components, and code review adhering to a style guide, you're freed from all of that pesky creativity. You can just write the thing you have a spec for by reasoning about the minimal data you need to represent the possible states of the app. You eschew choices, and your collaboration is easier, less egotistical, and more productive.*

*Written by an idealistic bleeding-edger.

The consistent base should be provided by the language itself. If your language isn't providing that, it's deficient. Powerful languages discourage frameworks and prefer small libraries. Deficient languages encourage frameworks and tons of repetition because they lack some key features of abstraction.