Live data from Hacker News

Why is the Google Cloud UI so slow?

debugbear.com

351–360 of 405 posts

Re: Why is the Google Cloud UI so slow?

#351
Google Cloud wanted to "eat its own dogfood", so they originally built the console with Angular v1 and App Engine instead of using more scalable and mature frameworks that would typically be used for those kinds of products within Google.

App Engine didn't support chunked transfer encoding so progressive data loading becomes impossible, and Angular v1 is a pathological performance and maintenance nightmare to the point where AngularJS / Angular v2 ended up being an incompatible rewrite.

The problem is, if you have hundreds of people contributing to a tool with deadlines to meet and lots of UI components you need an incremental approach if there's going to be any hope of replacing the whole architecture. Without an incremental path forward, rearchitecting is dead in the water. Management isn't going to want hundreds of people stop working on new features for months while the whole UI gets written from scratch.

Re: Why is the Google Cloud UI so slow?

#352

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.

I prefer sites like this. Also give me plain links that I can middle click on to open new tabs.

Let my browser manage my workspace, please don't make a window manager inside my browser window.

Re: Why is the Google Cloud UI so slow?

#353
post #351

Google Cloud wanted to "eat its own dogfood", so they originally built the console with Angular v1 and App Engine instead of using more scalable and mature frameworks that would typically be used for those kinds of products within Google. App Engine didn't support chunked transfer encoding so progressive data loading becomes impossible, and Angular v1 is a pathological performance and maintenance nightmare to the poi…

If dogfooding is the main reason behind using Angular, it's a bit ironic that <10%? of teams at Google use Google Cloud over Borg.

Re: Why is the Google Cloud UI so slow?

#354
post #314

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…

I've come to the conclusion that you want to structure your org chart to deliver the structure of application / experience you ultimately want to provide.

Re: Why is the Google Cloud UI so slow?

#355
post #81

Google's UI's in general are shockingly slow. I don't understand why my Google Drive and Gmail have input lag and choppy animations on my 5 year old xps13, it's not that hard to make navigating a filesystem or list of emails fast. Actually I do understand, it's because they want everything they build to be made in a massive javascript framework with shared components, which looks nice but runs like garbage on anythin…

The original gmail design was so fast, beautiful and minimalistic. It had vi key bindings and was close to perfect. The new one had a bunch of useless white space and the app has a loading bar! Wtf?!

FWIW you can select a setting to enable keyboard shortcuts, which are the vi key bindings.

I enabled that a while back which makes navigating emails much more pleasant

Re: Why is the Google Cloud UI so slow?

#356
post #354
post #314

Earlier quoted context omitted.

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…

I've come to the conclusion that you want to structure your org chart to deliver the structure of application / experience you ultimately want to provide.

This reminds me of the famous comic about org structures of various companies. [1] Perhaps this is why Steve Jobs liked to get his fingers in everything, to make sure everything flowed smoothly according to his vision.

[1] https://bonkersworld.net/organizational-charts

Re: Why is the Google Cloud UI so slow?

#358

Earlier quoted context omitted.

Really? Criticizing Google's frontends but praising GitHub and Amazon? If I had to pick a large tech company with a bad frontend Amazon would be top of the list. GitHub is not great either. I guess this kind of thing is just subjective though.

Github's site is really fast. Many of the pages it displays are dense with information and I think it displays everything well, for example viewing diffs in Github is very good, it smartly wraps all the text so you can view everything on the screen and everything loads fast. Try comparing it to Bitbucket's diff view, which can't wrap text amongst other things. It's light years better in comparison. It looks good at a…

On the whole GitHub's UI is good, though I still find it unreasonably difficult/slow to do a review commit by commit compared to kiln.

I'd really like it if they added a way to thumb between commits in one click without page loads, kinda like flipping through pages of a book

Re: Why is the Google Cloud UI so slow?

#359
post #151

Earlier quoted context omitted.

The conspiracy theorist in me wants to believe that this is not incompetence, but sabotage. Everyone uses Google products; if they work fast in chrome and slow on firefox, people will blame Firefox, not Google. And therefore will eventually switch to Chrome. Good strategy to steal market share.

It's not intentional sabotage; it's positive feedback loops. Using Chrome, your tooling experience developing software at Google is, maybe, 1% faster. Some of that is core (TBH, FF's engine is old and creaky and webkit-derived browsers out-perform it on all kinds of metrics, though FF has significantly closed the gap). Some of it is that teams develop for Chrome first, because it's the first browser shortcut availabl…

> those have to be rewritten from scratch if someone wants them for FF also.

What? Why are they not standard WebExtensions?

Re: Why is the Google Cloud UI so slow?

#360
post #354
post #314

Earlier quoted context omitted.

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…

I've come to the conclusion that you want to structure your org chart to deliver the structure of application / experience you ultimately want to provide.

This is what's known as an "Inverse Conway Maneuver"
Post reply on HN