[skulk]

> What happened to the Closure Compiler stack?

Nothing, I still use it daily at work, alongside Angular (though not together).

> how the heck did they end up settling on Angular of all things

At Google, It's convenient to use Angular because there are well-documented ways to do all of the normal things you have to do to have a production-quality front-end application, such as building reusable components, dependency injection, component testing, screenshot diffing, etc. Standardization of the framework also has the benefit of making it easier to find someone to ask for help.

It would be a truly herculean task to bring another framework up to the same level of support and integration of Angular inside Google.

[mattnewton]

As a former frontend dev, current google employee, I don't think it would be as technically herculean as it would be politically herculean. Plenty of production apps aren't on angular, but they are in much smaller orgs with less management, or they are in search where shaving ms of time is a job description.

It's really hard to wrangle the amount of feature growth cloud is experiencing and I expect they made tradeoffs to satisfy that first.

[landerwust]

Coming from the outside world and looking (back) in, I simply can't ever imagine being in the kind of environment where discussing the choice of web framework or tool language would last more than 10 minutes, before whoever spoke last basically wins. But then, I'm the kind of techie who has lost their love of and has actively grown to despise tech.

"Is it supported?" "Yep"

"Can we hire for it cheaply? "More or less"

"Does it support the weird InternalSuperWidget it must talk to?" "Essentially"

"Ship it!"

[aprdm]

It isn't this simple. You have millions of LoC already written, docs, onboarding, hundreds of teams with different opinions, training people in a different tech stack.

In green field development or smaller companies, sure, I however do not find it as exciting since there are not real people / technical challenges most of the time, once you compare with what you can build with 1000s of engineers.

[landerwust]

I do not miss Google's monorepo one iota. It had huge benefits, but after stepping back far enough the result also easily begins to look a little like Stockholm syndrome. Anything they want to open source they basically have to rewrite from scratch because of that godawful repo, never mind reasoning about what actually ended up in your binary on any particular day when depending on such a gargantuan tree, and of course not to mention what by now is likely 10s of FTEs dedicated simply to managing the tree.

Those millions of LOC mostly only existed to serve their own purpose, and possibly the intrigue of many a doe-eyed eng. If I came across a codebase like that today, I'd likely be quite vocal on reallocating the evidently outsized engineering budget to some more productive use

[aprdm]

Can you expand on "If I came across a codebase like that today, I'd likely be quite vocal on reallocating the evidently outsized engineering budget to some more productive use"

Like, Google (or other company) still has to deliver to production and they do so using their existing system. I believe not supporting the existing system means not having deliveries.

I am actually facing a similar issue in my current job and it isn't an easy thing to move away from.

[onekorg]

> It would be a truly herculean task to bring another framework up to the same level of support and integration of Angular inside Google.

I left on 2018, and I remember there were a lot of orgs and teams trying to migrate to a new framework. In my org we were discouraged to start new projects in Angular.

[skulk]

I completely forgot to mention that what I was saying was scoped to the Ads org, which has Angular embedded within it deeply.

[shadowgovt]

> It would be a truly herculean task to bring another framework up to the same level of support and integration of Angular inside Google.

And in fact, Cloud already did this.

Unfortunately, what they chose to bring up to the same level was... Angular, when they transitioned off AngularJS.

They moved from a framework with known performance pitfalls to a framework with slightly fewer known performance pitfalls. It was the right move for them, but it only solved a handful of the problems they were having with the previous iteration of Angular.