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

281–290 of 405 posts

Re: Why is the Google Cloud UI so slow?

#281

Post by cmckn »

graderjs wrote: post #53

The medium is the message. In some domains, slow and clunky feels like gravitas and reliability. Enterprise software. Enterprise recruiting software. AWS has a pretty slow, and clunky dashboard. AdSense is clunky. A lot of the biggest companies' flagship apps have a very bland "bureaucratic" look and feel. You may find it hard to believe, but Zuck wanted facebook to look like a government database for a long time, wh…

I don’t know if I agree with you, but I think an example of what you’re describing is the TurboTax web UI. You’re shown multiple “loading screens” where things like “We’re looking everything over!” are said to the user. The user is given the impression that some kind of heavy lifting is happening, when that probably isn’t the case. For Intuit, it’s a marketing thing.

I don’t think that is GCP’s problem, though.

Re: Why is the Google Cloud UI so slow?

#282

Post by tracker1 »

sam0x17 wrote: post #215
Traubenfuchs wrote: post #115

I think the answer is: This is the best the richest and best companies in the world, with their best paid 100x rockstar developers can do. Google is literally both the creator of the browser (Chrome), the framework (Angular) and the web-app (GCP) we use and still, this mess is the best they can give us. They have direct access to the creators of Chrome and Angular, in some sense they are the owners of the internet an…

The speed of GCP's internal control panel isn't going to affect Google's bottom line like it would with their search offering or other massively user facing things. Google could redo this frontend from scratch and make it really lean and fast, but they clearly don't think they need to.

You might be surprised there... enough friction for the developer experience will open the door to opportunities for other tools/platforms to take root. If the AWS UI/UX was exceptional, there's no way Google or Azure could have gained the footholds they did.

Re: Why is the Google Cloud UI so slow?

#283

Post by azurezyq »

stingraycharles wrote: post #270
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 even then in the Google Cloud console I still feel that parts such as Stackdriver are, in fact, completely separate parts of the UI and not integrated into the bigger whole. Same for many other products. Which begs the question, what problem are they solving with this “unification but actually not” approach? Couldn’t they just bite the bullet and give up on the unification and be done with it? Phrased differently…

Stackdriver was acquired: https://techcrunch.com/2014/05/07/google-acquires-cloud-moni...

The problem is that single-entrance is very valuable for ease-of-discovery. But complete integration / unification is just too difficult for something already present since they may simply use a totally different tech stack. Re-writing may not be justified by ROI.

For those kind of "separate parts", I can easily mention a few: 1. Stackdriver (acquired). 2. Cloud Data fusion (acquired, formerly cask.io) 3. BigQuery (predate GCP) 4. DataPrep (partnership)

Re: Why is the Google Cloud UI so slow?

#284

Post by smueller1234 »

jon-wood wrote: post #28
_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 suspect there's something in that comment on above-average network connections - the people working on Google Cloud's UI are going to be doing so from Google networks, or over a Google VPN, which means they'll be seeing much lower latency to your average person who has to be bounced around their ISP network and then across a couple of peering providers before getting there.

Throughout 2020, this hasn't actually been true.

Re: Why is the Google Cloud UI so slow?

#285

Post by tracker1 »

Traubenfuchs wrote: post #191
woah wrote: post #152

Earlier quoted context omitted.

Is this some kind of dig against the web? I prefer native myself, but obviously there are huge numbers of faster websites out there. The answer is that Google’s frameworks suck, and have for many years. I can’t comment on whether things are equally a mess in their proprietary code, but I don’t see any reason to think they’re not. This is a problem with Google, and their slide into mediocrity.

I love the web from the bottom of my heart. I love Javascript, I love Typescript, I love Angular. Develop once, run everywhere, no client side updating required. I love rest(ful) APIs. I consider working with Angular a joy. I am serious here.

I do like JS much more than most and have warmed up a lot to TS. I would echo most of this statement... except I think Angular is a dumpster fire that I'm more than happy to never touch again in my career.

Re: Why is the Google Cloud UI so slow?

#286

Post by kccqzy »

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…

Just look at what library they are using. Google used to use their industry-leading Closure library that's far better than anything outside Google. Then they flirted with multiple iterations of Angular and Dart and probably something else, but the rest of the industry has caught up and surpassed what Google has to offer.

Re: Why is the Google Cloud UI so slow?

#287

Post by potamic »

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…

Hard to believe. FE devs will be evaluating and hiring other FE devs for all purposes, so this problem shouldn't exist. Besides they did the whole material design research. I agree that their UIs overall just suck though. Don't know what they do wrong, if anything I felt they take an overtly scientific approach to UX which sometimes needs something of an artistic bend.

Re: Why is the Google Cloud UI so slow?

#288

Post by onekorg »

skulk wrote: post #210
landerwust wrote: post #199

Earlier quoted context omitted.

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

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

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

Re: Why is the Google Cloud UI so slow?

#289

Post by blueblisters »

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.

Re: Why is the Google Cloud UI so slow?

#290

Post by shadowgovt »

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.

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.

Post reply on HN