Live data from Hacker News

Why is the Google Cloud UI so slow?

debugbear.com

391–400 of 405 posts

Re: Why is the Google Cloud UI so slow?

#391

Earlier quoted context omitted.

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

I mean, I create SPA's where this just works for nearly every navigation element. With a proper "route-first" design, this is not that hard. Of course, it is a bit more work to perform url navigation even when merely opening a subview, but it's definitely worth it.

I share your annoyance at all websites who don't allow for this though.

Re: Why is the Google Cloud UI so slow?

#392
post #151

Earlier quoted context omitted.

I don't if this true but I have realized whenever I try to access google apps in firefox they are slow and sometimes breakdown but when I try to do it in chrome they just work fine. Like I was trying to submit some work using google classroom on firefox it wasn't letting me upload the work but when I did it in chrome it just worked well

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.

Former Mozilla exec: Google has sabotaged Firefox for years (zdnet.com)

https://news.ycombinator.com/item?id=19669586

Re: Why is the Google Cloud UI so slow?

#394

Earlier quoted context omitted.

I have never seen anyone in government or big corporate (including management and HR) put down a site for being too fast to load or react. I've seen plenty of instances where they've railed on one for being sluggish or unresponsive...certainly aesthetics are important for a subset of enterprise users (namely those who have to drink/act like they've drunk the kool-aid), but most folks aren't idiots and can definitely…

I get if you feel that aesthetics are a deliberate adoption only of those kool aid drinkers and "idiots", but that viewpoint probably just contributes to how you can't see that aesthetics and medium are a thing, that people expect but are unaware of. Because you wouldn't want to see yourself as a kool aid drinker or idiot, right. Meaning you're blind to it's effects, which I'm not saying makes you say idiot. This dyn…

I think my point emphasized aesthetics too much to the detriment of the main argument, so let me rephrase: aesthetics are also important if you want a of majority enterprise users to enjoy using your product (ask anyone who has had to deal with SAP). There will always be a few who love the brutalist or "power user" UI, but I think we're in agreement that visual appearance does matter.

With all that out of the way, the example I _wanted_ to raise above (but neglected to, apologies) with the "kool-aid" drinkers is that corporate users are absolutely aware of how fast and responsive something is _in addition_ to how it looks. I think many folks have been in a screen share or training session where the presenter has to awkwardly wait for an application they're "selling" to load or respond to input. Is the presenter oblivious to this latency? I'd say they are even more aware given the audience, if not flustered. That was the thrust of "people are not idiots".

WRT why people continue to use this software, I think you underestimate the impact of top-level purchasing/procurement and the captive enterprise audience. Those making purchasing decisions are less likely to use software after the sales demo and thus are not exposed to any UX or latency issues. Again. there is no idiocy or mal-intent here either, it's just an artifact of how bigcos operate.

Re: Why is the Google Cloud UI so slow?

#395

Earlier quoted context omitted.

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.

Totally true, just wanted to clarify that point of the OP

Re: Why is the Google Cloud UI so slow?

#396
post #151

Earlier quoted context omitted.

I don't if this true but I have realized whenever I try to access google apps in firefox they are slow and sometimes breakdown but when I try to do it in chrome they just work fine. Like I was trying to submit some work using google classroom on firefox it wasn't letting me upload the work but when I did it in chrome it just worked well

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.

Agreed but if they work fast in chrome just use chrome for that otherwise keep using firefox

I left using chrome 3 years ago and I haven’t really missed out and I honestly love firefox

Re: Why is the Google Cloud UI so slow?

#397
post #344

Earlier quoted context omitted.

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

But the screen flashes white, it looks non-native!

It does not flash white. See e.g. https://instant.page/

Re: Why is the Google Cloud UI so slow?

#398
post #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.

The Google Cloud team had more incentive than other teams would to be an early adopter in dogfooding their own products, in this case App Engine specifically.

Ending up on Angular was likely a consequence of using app engine: all of the standard google frameworks for writing UIs have a server-side component to help deliver data and scripts to the client, and most of those frameworks would have been difficult or impossible to port to app engine (either because of the chunked transfer encoding limitation, or just the general awkwardness and annoyance of porting a framework maintained by a completely different team from borg to app engine).

The codebase probably started with something that looked like an app engine example app, transferring data and code to the client in the simplest way possible, but not the most performant or scalable way.

Re: Why is the Google Cloud UI so slow?

#399

Earlier quoted context omitted.

I get if you feel that aesthetics are a deliberate adoption only of those kool aid drinkers and "idiots", but that viewpoint probably just contributes to how you can't see that aesthetics and medium are a thing, that people expect but are unaware of. Because you wouldn't want to see yourself as a kool aid drinker or idiot, right. Meaning you're blind to it's effects, which I'm not saying makes you say idiot. This dyn…

I think my point emphasized aesthetics too much to the detriment of the main argument, so let me rephrase: aesthetics are also important if you want a of majority enterprise users to enjoy using your product (ask anyone who has had to deal with SAP). There will always be a few who love the brutalist or "power user" UI, but I think we're in agreement that visual appearance does matter. With all that out of the way, th…

I think I get what you're saying. So kool-aiders are the ones who, true believers or not, need to sing praises of software foisted upon them as a captive enterprise audience by an inefficient top-level purchasing/procurement system. So, people are not idiots, means that most people, even some non-zealot kool-aiders see things don't work and could be better in such situations.

I totally agree. I think what happened with us is, as is the case in most of these things, we were talking about orthogonal or parallel things.

I'm not assuming your agreement with my belief that aesthetic, even "brutalist" or "slow and clunky", will connote quality to a certain subset of users, enterprise being one example. I think your might have took it to mean I was saying "haha, therefore I think enterprise users are idiots." Which is not what I meant, but I get how you could see that. I don't think an aesthetic preference, even one which may on the face of it seem maladaptive, means people are idiots. I don't think it's a maladaptive preference, it's a natural thing, and there's reasons for it that work. I suppose it's a form of stereotyping, that allows people to form quick judgments from limited information.

And I'm aware of the research that says that a "good UI" can hide other problems, and be easier to use. So on the face of it, that would seem to say software with "slick and snappy" UX will be more prevalent, or at least be completely wiping the floor with the "slow and clunky" competition. But it's not -- at least not at the high end of the market that I care about. So this is an idea I have about that.

Actually, my criticism, if it was with any group, was with the developers who want the new shiny above all else, and seem to fail to see the practical benefits of practices done by bigcos, even when the success of those products is right in front of them. I think such blindness is stupid. But the developers are not stupid.

My back story is I, even when I wasn't someone who valued new and shiny above all else, once thought, "all I need to do is consumer-productize" enterprise apps and everyone will love them. But that's not all that's required. So I don't underestimate the sales process, I'm just coming at it from the point of view that aesthetics are a component of that decision, albeit an implicit and probably by necessity unspoken one (otherwise: "This UI looks too fancy and the app is too fast. We can't trust these guys, but the old-reliable, clunky and 80s-looking app we've been buying for 20 years just works great for what it is." ~~ but, hey, maybe people really do say that!).

I think you can sell the unfamiliar (product, narrative) using the familiar vehicle (product, narrative, aesthetic). So if you want to do something new, the best way is to serve it to people in a package they already like and are familiar with. I believe that as a general principle. But in this more specific case we're talking about here, I just think I see the importance of aesthetics and many other people miss it.

I could be wrong...I was wrong about what's required to develop enterprise apps, but I guess I see it as something (one of my hypothesis) that should guide how I develop software. Because I figure if I do that, it will save me worrying about stuff that doesn't matter (the new shiny slick and snappy), and I can concentrate on what matters (building what they want), and maybe even hack their psychology a bit (make it look like the old style apps they are already familiar with). It's OK if you think differently about it. It's my idea after all, I was just hoping to convince you a bit about it, not to convince myself more through consensus...I don't need that, but because I like the idea that maybe you can benefit from something I figured out, and I can "invite you into the cool club" of people in the know about this secret thing, that nobody else really gets, and we can watch all the other people clamber around with their stupid ideas together and smugly go, "Heh, we know better." But yeah...It's an idea, I haven't tested it extensively (but a few of my current popular projects use slow and clunky, or identically copied from competitors UIs and they are very popular), but I'm comfortable with making my choices just based on my ideas and hypotheses. Maybe I just like the sense that I can see something in this space of developers, that many other people miss, because that lets me feel smarter than most everyone else in that way...maybe that's just compensating for a "lack of real success." But even if so, I need something to keep me going, right? Some sense of motivating self-belief. So those things, even if delusions, are useful. But I don't believe it's a delusion, and I do believe this to be true, and I'm comfortable with that.

I think that's how I think about things, so I hope that makes everything clear. But I appreciate you coming back and being nice about it, not being mean at least. That's a change from how it sometimes goes around here.

Re: Why is the Google Cloud UI so slow?

#400
post #366
post #365

Earlier quoted context omitted.

disclaimer: i work in google cloud, but on the apps side. One thing worth noting here is that google pretty famously has a monorepo and single-version policy. Meaning: while you may be right about the subteams/orgchart meta-issue, it's not actually shipping multiple versions of the same subcomponent. There's just one version.

and i should add that this constraint is one of the reasons why some products get discontinued. right now, I'm dealing with migrating a dependency that has some breaking changes in an old section of my codebase that nobody has touched in years. I have to change it, because the dependency is changing, and I cannot continue to depend on the earlier version. Happily, it is a simple enough update (and frequently these ch…

Aha, so my guess was right: https://news.ycombinator.com/item?id=24457476
Post reply on HN