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

311–320 of 405 posts

Re: Why is the Google Cloud UI so slow?

#311

Post by mtgx »

blueblisters wrote: post #289
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…

> And the product as a whole is chasing feature parity, not speed of UI. I find it hard to believe GCP is not chasing the UX experience since they have actively focused on building arguably non-priority features like a fully functional terminal within the cloud UI.

Maybe they should apply their own Core Web Vitals penalizations and drop in Google Search because of it.

https://www.searchenginejournal.com/google-core-web-vitals-r...

Re: Why is the Google Cloud UI so slow?

#312

Post by petters »

hamandcheese wrote: post #300
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…

> and be willing to take a whole-page refresh when the user transitions from one page to another. This should be the default! What a world we live in.

Yes! We're building a fairly complex web app and page refreshes are < 100ms. With prefetching on hover this becomes virtually instantaneous.

Re: Why is the Google Cloud UI so slow?

#313

Post by luord »

Knowing that the target audience for this is developers (for the most part), the decision to make it a javascript application in the first place instead of rendering from the server seems like overkill, at least IMO.

Maybe it's just me, but I don't really care about fewer page reloads or having multiple animations and interactivity. I understand why those can have an impact on end users and so I do think that SPAs have their place, but I'd much rather the interface was rendered from the server and worked through links if it means it'll work faster. In fact, half the time I'm not even using the web interface; I'm using the SDKs.

Re: Why is the Google Cloud UI so slow?

#314

Post by allenu »

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 and timelines.

Re: Why is the Google Cloud UI so slow?

#315

Post by secondcoming »

shadowgovt wrote: post #290
blueblisters wrote: post #289

Earlier quoted context omitted.

> And the product as a whole is chasing feature parity, not speed of UI. I find it hard to believe GCP is not chasing the UX experience since they have actively focused on building arguably non-priority features like a fully functional terminal within the cloud UI.

They care more than zero, but about feature completeness more than speed. Keeping in mind that their leading competitor (AWS) leaned heavily on CLI, providing web frontends is seen as a competitive advantage. But they're far more focused on spanning feature set than the speed of the result.

Having used both, I prefer AWS's UI over GCP's

Re: Why is the Google Cloud UI so slow?

#317

Post by tehlike »

pjmlp wrote: post #167
levosmetalo wrote: post #23

Earlier quoted context omitted.

Why is everyone assuming that just because someone works for Google has to be competent? Solving algorithmic puzzles is not an indicator or actual technical skills. To me, it looks like a work of incompetent developers led by incompetent technical managers upon requirements of clueless and ignorant product managers.

Coding for Android has taught me that is definitely not the case. They managed to make a mess worse than JEE, the native layer took 10 years to finally use Android Modules, they keep fixing the header files, still don't have proper C++ bindings and force everyone to write JNI boilerplate by hand.

Android is really the worst platform for developers. Context? Let's make a god object, and also create application context and activity context, and screw liskov substitution principle. Also create a library to fix all our bugs in all versions of the platform, but also have a shit ton of bugs.

Microsoft did nail windows phone apis, 10 freaking years ago, too bad it didn't survive.

Re: Why is the Google Cloud UI so slow?

#318

Post by landerwust »

mattnewton wrote: post #239
skulk wrote: post #210

Earlier quoted context omitted.

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

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"

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

"Ship it!"

Re: Why is the Google Cloud UI so slow?

#319

Post by Whinner »

robertlagrant wrote: post #220
EGreg wrote: post #185

Earlier quoted context omitted.

I must say after using Microsoft Teams... M$ is back, baby. I would invest in them if I invested in huge-market-cap companies. After IBM, Microsoft became the company selling Windows and Office for businesses. Huge cash cow. They lost that for a while due to the iPhone and Google and stuff moving to the Web and mobile. Now they’re back. The fonts and aesthetics remind me of using Windows apps 20 years ago. This ain’t…

> Compared to Slack, this is way better Try scrolling up in Teams. I'll wait. Now do it in Slack - 10 times quicker, and thus usable.

Try doing a screenshare in Slack. You can't, you have to connect a voicecall before you can share your screen.

Now do it in Teams. You can share your screen without completing a voicecall.

Re: Why is the Google Cloud UI so slow?

#320

Post by bluedino »

christophilus wrote: post #19
_Microft wrote: post #15

User to Dev: the memory usage is excessive. Dev with 256 GB RAM to User: WFM I would not be surprised if a lot of these problems could be traced back to developers having above-average network connections and super beefy computers. Combine that with fresh or minimal installs while testing the software, without lots of data that accumulated over month or years of use and in consequence they experience their products a…

I agree. I have a second, crummy old laptop for just this reason. I can't quite bring myself to develop on an underpowered machine, but it is useful to have one as a reference. Also, my phone is old because I'm a cheapskate, so that helps tremendously with assessing mobile performance.

>> I agree. I have a second, crummy old laptop for just this reason.

Learned this the hard way. Made an editor, everyone loved it. Added features, people loved it. Kept adding features...then it was called slow, bloated etc.

Everything seemed fine on my new-at-the-time iMac.

Went into a conference room where we had one of the first Intel MacBook Pros...there were portions of the editor where you could literally see things being redrawn. A night of optimizations later, performance was restored.

Post reply on HN