4 ms·

Googler who doesn't work in front end here, so take my opinion with a grain of salt: 1) A "footsoldier" dev has no choice in frameworks, and heavy frameworks w

by pradn 6y ago

Googler who doesn't work in front end here, so take my opinion with a grain of salt: 1) A "footsoldier" dev has no choice in frameworks, and heavy frameworks with heavy reusable components are the norm. Frameworks are used to improve dev velocity and ensure consistency among the 100 teams that contribute to the web UI. 2) Devs care about performance but might not have time to do much about it given competing priorities. Cloud is a fast-moving area, so new features are being added all the time. Even if they want to improve performance, they're limited by the frameworks you have to use. 3) For folks that are saying Google controls the browser, framework, and component library, and so should be able to do better than this, you are right. But the different divisions don't talk to each other as much as you'd think. Why should they? Angular devs shouldn't get special access compared to React, no? Whether this is an organizational failure or an enforcement of separation of concerns is up to you. I imagine critics will complain if Chrome did something special for Google properties, and they'd be justified.

landerwust 6y ago
What happened to the Closure Compiler stack? It was infinitely ahead of its time, how the heck did they end up settling on Angular of all things
- skulk 6y ago
  > 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.
  - shadowgovt 6y ago
    > 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.
  - mattnewton 6y ago
    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 6y ago
      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 6y ago
        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.
- JeremyBanks 6y ago
  It was infinitely ahead of its time when it was new... and then it was abandoned until it was miles behind the competition. It's the Google Way. (But truly, the headcount on Google's internal web tooling compared with the size of the organization is laughable. I watched lots of devs burn out trying to improve internal tooling, then quit, because the organization doesn't value it.)
WorldMaker 6y ago
> But the different divisions don't talk to each other as much as you'd think. Why should they? Because they are a customer with real world usage? I don't think anyone is asking for "special access" or "special Google only APIs" or anything like that. However, if the Angular team isn't even looking at how parts of Google themselves are using their framework in out-of-the-box configurations and making the Framework look terrible on performance at scale, then is the Angular team looking at any customer's performance? Facebook and Microsoft here both make a huge deal of dogfooding one's own frameworks because when you are your own first customer you get a lot of direct, immediate feedback. There are performance characteristics of today's React that we know come from needing to work at Facebook scale. There are performance fixes to Typescript that we see get mentioned that Microsoft internal teams experienced pain points with and let the Typescript team know that a hand would be useful there. At least from external appearances, almost all of Google's largest scale usages of Angular perform poorly. I don't understand how anyone would want to use Angular knowing that even Google can't get it to perform at scale. That either the Angular team isn't prioritizing performance at scale or the Angular team has built it in such a way that even supposedly smart people "in the office next door" can't figure it out. In neither case does it look good for Angular. What's the point of even having the Google name behind the Angular brand if Angular isn't taking production performance feedback from Google? (Obviously, it's still good marketing because so many people outside Google are using Angular, sometimes against their own better judgment. But it feels like a bait and switch.)
- pradn 6y ago
  I think your criticism is totally valid. Angular should take a look around and see the real-world uses of their framework and see how they could get so slow. Ultimately, the onus is on the Google Cloud team to prioritize and deliver performance. Perhaps part of the problem is that very large customers use the automation APIs, so they don't make the complaints that get heard. ("Platinum" customers have a strong impact on the roadmap.)

by pradn 6y ago

landerwust 6y ago

What happened to the Closure Compiler stack? It was infinitely ahead of its time, how the heck did they end up settling on Angular of all things

skulk 6y ago
> 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.
- shadowgovt 6y ago
  > 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.
- mattnewton 6y ago
  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 6y ago
    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 6y ago
      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.
JeremyBanks 6y ago
It was infinitely ahead of its time when it was new... and then it was abandoned until it was miles behind the competition. It's the Google Way. (But truly, the headcount on Google's internal web tooling compared with the size of the organization is laughable. I watched lots of devs burn out trying to improve internal tooling, then quit, because the organization doesn't value it.)

WorldMaker 6y ago

> But the different divisions don't talk to each other as much as you'd think. Why should they? Because they are a customer with real world usage? I don't think anyone is asking for "special access" or "special Google only APIs" or anything like that. However, if the Angular team isn't even looking at how parts of Google themselves are using their framework in out-of-the-box configurations and making the Framework look terrible on performance at scale, then is the Angular team looking at any customer's performance? Facebook and Microsoft here both make a huge deal of dogfooding one's own frameworks because when you are your own first customer you get a lot of direct, immediate feedback. There are performance characteristics of today's React that we know come from needing to work at Facebook scale. There are performance fixes to Typescript that we see get mentioned that Microsoft internal teams experienced pain points with and let the Typescript team know that a hand would be useful there. At least from external appearances, almost all of Google's largest scale usages of Angular perform poorly. I don't understand how anyone would want to use Angular knowing that even Google can't get it to perform at scale. That either the Angular team isn't prioritizing performance at scale or the Angular team has built it in such a way that even supposedly smart people "in the office next door" can't figure it out. In neither case does it look good for Angular. What's the point of even having the Google name behind the Angular brand if Angular isn't taking production performance feedback from Google? (Obviously, it's still good marketing because so many people outside Google are using Angular, sometimes against their own better judgment. But it feels like a bait and switch.)

pradn 6y ago
I think your criticism is totally valid. Angular should take a look around and see the real-world uses of their framework and see how they could get so slow. Ultimately, the onus is on the Google Cloud team to prioritize and deliver performance. Perhaps part of the problem is that very large customers use the automation APIs, so they don't make the complaints that get heard. ("Platinum" customers have a strong impact on the roadmap.)