[nostrademons]

Sometimes that's exactly what you want, though. If you're deriving a competitive advantage from a tool, it's often to your advantage for as few people to know about it as possible. That's why Google kept it secret and internal-only for the first 5 years of its existence, and only open-sourced it once the hype train had moved on to other technologies.

[reagency]

But in those 5 years industry passed it by and now Google is crippled by legacy technology. Compare to Guava Java, which also powers Google, is open source, and is still best in class today after many years

[nostrademons]

Well, the same thing happened to many of the more open, hype-laden technologies. JQuery and Angular are both also obsolete, and the new hotness is React, with Google trying to get in on the action again with Polymer but so far uptake seems limited. I also wouldn't say "crippled" - I worked with Closure on both Google Search and Google Plus, and while I certainly wouldn't use it for a startup, it's much better than all of JQuery/Angular/React for a 50+ person team.

Guava is in a much different position. As a fundamental class library, it's much more deeply embedded in your code than a front-end framework, and so switching costs are much higher. You could also argue that Java as a whole is "crippling legacy technology", with newer apps being written in Go, Node.js, Ruby, Python, and hopefully soon Rust.

[LocalPCGuy]

I would take you to task on the statement that jQuery and Angular are obsolete already. That is an in-the-bubble statement, and nothing to do with what people are really using across our industry.

[OmarIsmail]

Can you give some more information on why Closure is better than React for large teams and why Closure wouldn't be good for a startup?

[nostrademons]

Closure is much more tightly typed and namespaced, it has a larger library of pre-built components, it bans (via compiler warnings) practices that are hard to maintain, and it errs toward verboseness. All of these improve the readability of code at the expense of its writability. In a large established organization, you read code much more than you write it. In a startup, you write it much more frequently than you read it.

[hokkos]

The react world has flow that does the same type checking, for the bundling webpack is now superior, and warning is handled by eslint, and with babel for ES6, and PostCSS for css next I don't think there is a lot of reasons to use the closure tools apart for the components.

[pbowyer]

> flow that does the same type checking, for the bundling webpack is now superior, and warning is handled by eslint, and with babel for ES6, and PostCSS for css next > I don't think there is a lot of reasons to use the closure tools apart for the components.

The fact that your list is that long is a good reason. Using best-of-class libraries is brilliant (and I'd like to all the time), but using good-enough libraries that are well tested with each other and unlikely with new releases to change behaviour in ways that will create edge-cases or interop problems: that is pragmatic.

Plus the reduction in developer-rabbit-holes when every developer tries to include its own favourite (Webpack! Browserify!), the consistent documentation, and the ease of setup.

Not to say you're wrong, but I feel people overlook the benefit brought by well-developed monolithic frameworks.