Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is the Google Cloud UI so slow?

debugbear.com

Post reply on HN
Print view View original

321–330 of 405 posts

Re: Why is the Google Cloud UI so slow?

#321

Post by aprdm »

landerwust wrote: post #318
mattnewton wrote: post #239

Earlier quoted context omitted.

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 tradeoff…

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"…

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.

Re: Why is the Google Cloud UI so slow?

#324

Post by woah »

jeffbee wrote: post #258
woah wrote: post #156

Earlier quoted context omitted.

Facebook also makes heavy use of frontend frameworks but all their stuff is fast because they are competent at it.

I just measured an uncached page load of facebook.com and it takes 3.5s which isn't stellar.

It doesn't really matter how fast an uncached page load is for Facebook. Why would they optimize it? A user will only see that a few times a decade when they get a new computer. It would be like trying to shave seconds off of a native app install time.

Re: Why is the Google Cloud UI so slow?

#325

Post by Raymonf »

cstrahan wrote: post #197
simonw wrote: post #97

Earlier quoted context omitted.

What do you find lacking about GitHub's frontend?

For one, they're using some sort of link / browser history hijacking (something like https://github.com/turbolinks/turbolinks , IIRC) which is buggy, for example: * say you're on page A * navigate to page B * navigate to page C * click your browser's back button, hoping to be back at page B * the github UI screws up and keeps you on the same page while changing the URL in the address bar * so you click back again * n…

What browser are you on? The navigation issues don't happen for me on Chrome.

Re: Why is the Google Cloud UI so slow?

#326

Post by [deleted] »

chubot wrote: post #271

The real answer is that Google's promotion and hiring processes don't respect front end developers. Systems programming and distributed systems are considered "hard" and worthy of reward. This explains why Google's front ends are bad, and it also explains why there's a proliferation of non-composable distributed systems inside Google. As a second order effect, the design of those back ends also make it harder to make…

[deleted]

Re: Why is the Google Cloud UI so slow?

#327

Post by pradn »

WorldMaker wrote: post #298
pradn wrote: post #164

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 prioriti…

> 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 l…

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.)

Re: Why is the Google Cloud UI so slow?

#328

Post by pavlus »

deepsun wrote: post #291
chubot wrote: post #271

The real answer is that Google's promotion and hiring processes don't respect front end developers. Systems programming and distributed systems are considered "hard" and worthy of reward. This explains why Google's front ends are bad, and it also explains why there's a proliferation of non-composable distributed systems inside Google. As a second order effect, the design of those back ends also make it harder to make…

I remember there was pretty similar post from ex-Wave engineer about exactly that -- they put "best" engineers (if such thing exists) on backend, and neglected frontend. It might not be the main reason for its utter failure, but it did contrubute.

I had one-off experience recently: tried to add IPv6 CIDR for accessing k8s master, and FE validated it perfectly but somewhere on BE they validated it with regexp that accepted only IPv4 CIDRs, but at least up to 999.999.999.999/99, so not that bad. /s

Re: Why is the Google Cloud UI so slow?

#329

Post by [deleted] »

allenu wrote: post #314
shadowgovt wrote: post #211

There's a meta-answer, which is Google is shipping its org chart. Google Cloud UI is one giant Angular app with components written by sub-teams across wildly disparate timezones, much less offices. Their ability to consolidate resources is poor. They came late-to-the-game on tooling up an infrastructure team to provide both standardized libraries and rigor on how the architecture is used. The duplication of component…

This is what I was thinking as well. Once you recognize Conway's Law and Sinofsky's "don't ship the org chart" quote, you start to see it a lot in large companies. Want another great example? If you write iOS apps, you'll probably have worked with the App Store Connect website. That site is such a hodgepodge of slightly different UI paradigms that it could only have been written by multiple teams with differing goals…

[deleted]

Re: Why is the Google Cloud UI so slow?

#330

Post by landerwust »

aprdm wrote: post #321
landerwust wrote: post #318

Earlier quoted context omitted.

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"…

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.

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

Post reply on HN