16 ms·

Why is the Google Cloud UI so slow?

• ape4 6y ago
  And of course, Google gives demerit points to websites that load slowly. (Or whatever they are called)
  • abdusco 6y ago
    This isn't really a public page, though. Their landing page loads really quickly. https://cloud.google.com/ https://cloud.google.com/
• api 6y ago
  Atlassian Jira is dog slow too. Drives me nuts.
  • blakesterz 6y ago
    Atlassian is one of those places that I just can't believe has gotten so widely used. Every single thing I've used that is an Atlassian product drives me nuts. I really don't understand how anyone at any point looked at Jira or Confluence or anything Atlassian puts out and said "yep, this is the best version of this thing I've seen, sign me up". I've been using JIRA for years now, and it never gets any easier or better. I can never find what I want, I can never remember how to do things. I have to assume it's just me since everyone uses these things though.
    • krupan 6y ago
      Because 10-years ago Atlassian products were a huge breathe of fresh air. Everything else was so much worse. Come to think of it, that's how Google became so popular too.
    • bamurphymac1 6y ago
      It is not just you. It’s shocking.
    • kevincox 6y ago
      I agree completely. Bitbucket is OK, but everything else is so painful, and the Bitbucket alternatives are better than it anyways.
    • sz4kerto 6y ago
      Because UI snappiness is not the only thing that matters. One example: Jira integrates with _everything_. It really matters that you can create tickets from Slack, send email to the management when epics progress, see Github pull requests linked to tickets, and so on.
    • st1x7 6y ago
      What's a better alternative to Jira? I've tried Trello and Asana. Trello is nice for personal stuff and small projects but it doesn't work well for bigger projects and teams. Asana has an infuriatingly unintuitive interface but that might just be my personal preference.
      • ianwalter 6y ago
        http://linear.app http://linear.app and https://clubhouse.io https://clubhouse.io -- I chose Clubhouse for our team a few years ago but Linear is new and is extremely well-made.
    • nicoburns 6y ago
      JIRA is used because it's been around a long time and until recently the competition was even worse. It's also gotten slower over time in my experience.
    • magicalhippo 6y ago
      We're using self-hosted Jira and it's fast enough. From what I gather the cloud version is what's dog slow? We'll likely find something else once the self-hosted version expires in a couple of years, unless the cloud version gets up to speed.
    • cnlwsu 6y ago
      I guess I am older but pre jira things were so much worse that yeah... best version of this thing I’ve seen. Not that I love it but it’s functional and not an Oracle form or some ugly crud tool cookie cut for a process different than my teams.
    • Aeolun 6y ago
      As far as I understand it, it's because Jira is not made for developers. It's made for SCRUM and Project Managers that need fancy graphs and lots and lots of fields and processes. It's their reason for existence, so they have every incentive to make it so that developers do not understand.
      • nobleach 6y ago
        That'd make complete sense. None of their products support Markdown really well. Each has its own weird way of handling code snippets. So many other tools support three backticks and boom, you're in a code-block.
      • api 6y ago
        Doing a small startup I forget about this nonsense sometimes. I could make more at a big company but when I read this I am glad to be doing what I am doing.
    • borplk 6y ago
      One reason is usually the person that decides for the company to use it never actually touches it.
    • hedora 6y ago
      You’re probably using it wrong. Click your mouse on a non-interactive UI component and press “.” Now you can find everything you want. You’re welcome. I agree jira is terrible. Other bug trackers I’ve used are somehow worse. Does anyone have anything they can recommend with a straight face? (Github issues are missing too many features for me. Jira’s sql-style language is just too useful.)
      • syncsynchalt 6y ago
        I'm a jira power-user and your answer highlights my two main problems with it. > Click your mouse on a non-interactive UI component 80% of the UI is interactive, but not marked as such. Have fun finding a 10px strip that won't turn into an edit workflow when clicked! > Click your mouse on a non-interactive UI component and press “.” Even using the keybindings (seriously everyone, hit "?" and look through them) events are lost. Want to create a subtask? It's not `.sub<enter>`, it's actually `.sub^H^Hsub^H^H^Hsub<enter><wait><tab><tab><give up and use mouse to focus a field, because it arbitrarily unfocuses fields>Title Of My Task<use mouse to find the submit button>` They've done so much work to make it a quick UX but it's all for nothing when it randomly eats keystrokes and defocuses constantly. Maybe some of our add-ons are at fault, I'm interested in hearing if there are jira installs that aren't like mine.
    • aloukissas 6y ago
      It's one of those products that is "sold" not "bought".
  • cyberpunk 6y ago
    If you're on a mac try the jira app from the appstore, it's much, much faster.
    • M4v3R 6y ago
      It is, but unfortunately it lacks features. Issues not showing their history is a killer for me.
• leesalminen 6y ago
  I spent a couple years on a 5/2 mbps connection and GCP console was always the slowest thing to load out. 15MB of JS is crazy.
• pabl0rg 6y ago
  Meanwhile AWS uses google’s GWT to great effect
  • revendell_elf 6y ago
    Any source of this info?
  • deleted 6y ago
    [deleted]
  • bitL 6y ago
    Isn't GWT maintained by JetBrains these days?
    • vmsp 6y ago
      Seems to be maintained by Google https://gwt.googlesource.com/gwt/ https://gwt.googlesource.com/gwt/
      • wg0 6y ago
        And I thought GWT would be dead.
  • hedora 6y ago
    AWS console is by far the slowest thing on my machine, web based or not. I don’t use GCP or many other Google products though. I’m kind of shocked google managed to ship a framework slower than GWT. I always assumed anyone that used it for a few seconds would say “well, that was a fundamentally bad idea”, and not double down on whatever the heck Google was thinking.
  • patch_cable 6y ago
    Some older services do. It isn’t the framework used by new services for their consoles.
• dsign 6y ago
  That's what happens when you employ over-enthusiastic developers obsessed with their Javascript-framework-legacy. Things worked fast when HTML was the UI, and the logic was in the server.
  • base698 6y ago
    I worked on a server rendered project in the 00s. There was a screen that took 7 minutes to render for about 100 list items. You can make anything slow if you really try.
    • delusional 6y ago
      Correction: you can many anything slow if you don't try.
    • deleted 6y ago
      [deleted]
  • Wintamute 6y ago
    Slow servers are a thing too you know.
    • inetknght 6y ago
      At least if the server is slow it's likely to be slow for everyone
      • edoceo 6y ago
        I find it's easier to collect metrics from my gear - than from the web-client - so, I can diagnose.
  • pikzel 6y ago
    For Google, it's better when it's my CPU doing the work, than theirs.
  • woah 6y ago
• johncena33 6y ago
  I haven't used GCP for a long time. I regularly use AWS though. I also find AWS UI to be very slow. It always surprises me why.
• hobbescotch 6y ago
  It’s a real pain how slow it is. I’ve resorted to adding quick links to my bookmark bar for GCP products that I use often to get around the slowness.
  • corrigible 6y ago
    I was happy with the old BigQuery UI and now they've finally moved it into the Cloud Console monstrosity :(
• _Microft 6y ago
  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 as super snappy. Summary: they maybe never experience their products as a normal user would.
  • christophilus 6y ago
    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.
    • bluedino 6y ago
      >> 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.
  • levosmetalo 6y ago
    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.
    • notretarded 6y ago
      Found the google interview reject.
• ProAm 6y ago
  Probably the same reason why the gmail web interface is so slow too.
• Fiveplus 6y ago
  Can a googler chime in to explain why Gmail is so slow at loading even on the most robust PCs with high speed internet?
  • dvh 6y ago
    Try this one: https://mail.google.com/mail/u/0/h/77z33rvyv1lz https://mail.google.com/mail/u/0/h/77z33rvyv1lz It's HTML version of gmail and it loads instantly.
    • perryizgr8 6y ago
      It's so fast! Blink and it's fully loaded! Also kind of looks better too. But that's subjective, I guess.
  • alisonkisk 6y ago
    Because you are supposed to load it once and keep it forever. Loading a web app is like installing a software program.
    • rhencke 6y ago
      What about web apps like https://sr.ht https://sr.ht which are fully loaded and usable from a cold visit in under half a second with only 2 network requests?
• cube00 6y ago
  The way my machine fan fires up when I use it I just assumed I was mining bitcoins to help offset my bill.
• dvh 6y ago
  In Google play developer console there is simple table with list of apps and installs count. The cells are 34 levels deep in the DOM. Insane.
• landerwust 6y ago
  Yikes, didn't realize they had the indecency to drink their own kool-aid. Angular, really? No wonder! Come to think of it, it's maybe been around a year since I last saw one of those tell-tale "page finishes loading to a blank page for 20 seconds before finally rendering" Angular sites
  • jeremycarter 6y ago
    This comment is ignorance at it's finest.
• option_greek 6y ago
  I guess stuff like amp is good only to preach others. This garbage has been slow for ages. Also they keep throwing links to new stuff in their side bar without any rhyme or rhythm making navigation as annoying as possible.
  • runawaybottle 6y ago
    That’s kind of the woah factor here. Talk about glass houses.
• GhostVII 6y ago
  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 anything not modern.
  • alisonkisk 6y ago
    It doesn't look nice. It looks a lot worse than 10-years ago. But it is more compatible with i18n/l10n and accessibility plugins and compatibile components across a dozen chat apps
  • influx 6y ago
    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?!
    • GordonS 6y ago
      Keep seems to have gotten slower and slower over the years too - the web version is practically unusable on mobile, not just because the UI design isn't responsive (!), but because it's so painfully slow. Boggles the mind how Google web apps have performance issues like this.
      • jeffbee 6y ago
        Wait, you think https://mail.google.com/mail/mu https://mail.google.com/mail/mu, the mobile web version aka "superpudu" is slow? Can you tell me your device? It paints itself in only 400ms on my iphone. I actually prefer it over the app because it's so fast.
        • GordonS 6y ago
          My comments were about Google Keep, not Gmail, though I do actually find the Gmail web app pretty slow too - it takes several seconds to send an email. I didn't know there was some kind of secret mobile Web version of Gmail - I get a blank white page when I open your link on mobile tho (using Brave)?
• graderjs 6y ago
  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, where you type in someone's name and see details about them. Engineers will probably scoff at these notions, because it seems to suggest that underlying their "real" engineering concerns, are implicit aesthetics they would neither say they agree with nor be aware of, but it's real. If you're deep in the medium, maybe you don't even see it as a medium anymore, and you don't realize its quirks.
  • bassman9000 6y ago
    Slow and clunky is also unreliable, it's did it go through?, did I click on that? Is it loading, or is my connection having troubles? Is the browser again? Some of the ugliest Gov and Gov adjacent pages (e.g. tax collectors, some DMVs) are fast and prompt zero second guessing. They just work.
    • graderjs 6y ago
      The slow and clunky I referenced don't have "loading semantics" issues, they all show loaders, action statuses, and many indicate connectivity and save progress for multipage sagas. But you are right that slow and clunky can be unreliable, but so can slick and snappy. Tho, neither of them have to be. In some domains, slick and snappy can feel insubstantial and off-key. It's interesting that the pages you reference are "consumer" products, not enterprise, so that's inline with how I think this goes. I think basically we're talking about orthogonal kinds of slow and clunky, yours is more the engineering focus of how it works, and mine is, like I said in the parent comment, about the aesthetics and the medium in a domain.
      • BadInformatics 6y ago
        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 feel when something is objectively slow.
• dijit 6y ago
  The gcloud command line is also abysmally slow. The memory usage of the webpage often exceeds 1GiB. But otherwise the platform is good. So I suffer through. But I agree it’s annoying.
• dochtman 6y ago
  My pet peeve is that a lot of the GCP console doesn't even seem to work in Firefox. For example: https://github.com/webcompat/web-bugs/issues/61522 https://github.com/webcompat/web-bugs/issues/61522
  • lol768 6y ago
    Cloud SSH has been broken for months https://github.com/webcompat/web-bugs/issues/57957 https://github.com/webcompat/web-bugs/issues/57957 - no movement despite reporting it via the official channels too. This is one of the first features a new GCE user is likely to use (if they're exploring the UI and haven't yet started using the CLI) - and it's broken out of the box. Amazing. It's amateur hour over there when it comes to frontend development - it's not a web app where cross-platform/cross-browser testing takes place, it's a Chrome app.
  • severak_cz 6y ago
    yes - it has bad UX and it's broken in Firefox
    • mraza007 6y ago
      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
      • solarkraft 6y ago
        The consequence of this is not that I think Firefox is bad, by the way. It's that I think Google are a bunch of idiots.
        • lol768 6y ago
          Yet another "oops" to add to the pile https://twitter.com/johnath/status/1116871246510264320 https://twitter.com/johnath/status/1116871246510264320
• prodtorok 6y ago
  I think its fine at enterprise scale... has anyone experienced AWS console at enterprise scale? in 2015-17 it was awful.
• deleted 6y ago
  [deleted]
• kordlessagain 6y ago
  In Firefox, https://console.cloud.google.com/compute/instances https://console.cloud.google.com/compute/instances never loads.
• picodguyo 6y ago
  Maybe they tapped the same developers who built the Google Ads web app, a UI so slow they have time to display tutorials while everything loads.
  • zaroth 6y ago
    Seriously? It’s like a game load screen?
    • monkeybutton 6y ago
      Yes.
• joeblau 6y ago
  Is there something Angular can do to help improve the performance before creating the page?
  • tashoecraft 6y ago
    Angular has tons of things you can do to have great performance. I'm guessing the Google Cloud team just aren't prioritizing performance over features.
  • The_rationalist 6y ago
    The reactivity detection mechanism of angular is not tree scoped like in Vue, it is global and therefore much more inefficient
• whalesalad 6y ago
  Every Google SPA is slow. It’s compounded by poor animations that are all a little too long, and Material UI.
• zomgwat 6y ago
  The slow UI is one (of many) reasons why I moved away from Google Cloud Monitoring.
• jbirer 6y ago
  Ah yes, Angular.
  • jeremycarter 6y ago
    Please explain? Or is this just a random useless ignorant comment?
    • jbirer 6y ago
      You know a framework is bad when you just mention it's name and people assume it's an insult.
• wg0 6y ago
  I use AWS and GCP regularly and Azure sometimes as well. GCP is too damn slow by comparison not that others too would win any industry awards for speed but they are usable. On GCP however, the GKE screens are damn slow with spinner spinning for so long that I started to doubt my internet connection. UI of a IaaS (or PaaS) certainly is a complex matter and I guess few iterations down the road, GCP might perform better. May be load lazy load the UI functionality (JS) on demand or something.
  • jmarcher 6y ago
    I was shocked the first time I tried Digital Ocean K8S. They are just serving the default K8s Web UI (or looks like it). It was just... so fast! At this point I mostly use Vimium omni search to use the history to get exactly where I want to go and a simple script that opens my browser in the same context and namespace that kubectl is using. (e.g.: show all deployments, show a specific deployment, pod, logs, etc.).
• gvfdabgea 6y ago
  As a recent convert to Google cloud from AWS; it is really slow!!
• rubyist5eva 6y ago
  One thing that I've started doing for my own personal projects is deliberately working on underpowered hardware. I got a Rasberry PI 400 and that seems to be the perfect dev environment for me. It also has the side effect of making me much more conscious of the technology and dependencies that I use to create a product with. I use my own beefy server for creating builds and have a decent dev-build-test setup for myself where the dev experience is still pretty fast despite the hardware I'm using as a client - but when it comes to actually testing out my work I love using it on the PI because I know that most users will have an experience very similar to what I get on the PI.
• dabeeeenster 6y ago
  When you start implementing a second loading spinner. That's the time to stop and think about what you're doing. Surely.
  • deleted 6y ago
    [deleted]
• pimlottc 6y ago
  The G Suite (now Google Workplace) admin console GUI is also pretty slow. What makes it worse is that you have no other choice - it's the only complete tool for administrating G Suite. There are APIs for some things, but quite a lot is only available in the GUI, and new features always show up there first (if they ever make it to the API at all). There isn't even a way to import/export settings, so you have to painstakingly document everything and reconfigure it manually if you need to create a new instance. It makes things pretty painful from a compliance point of view.
  • agentdrtran 6y ago
    The Workplace admin console is unbelievably bad, and search is a joke. Not being able to search for aliases causes issues nearly daily.
  • polytely 6y ago
    G Suite is the worst piece of shit I have to use in my work and I curse the developers every time I'm forced to use it. It's like they went out of their way to make the worst design choices at every point. It would be impressive if it wasn't so depressing.
    • r1ch 6y ago
      I can't even get through to G Suite support lately since the only way is through the admin console chat bot, which is bugged and freezes at "transfer me to Cloud Support". Absolutely one of the worst products I have to use on a day-to-day basis.
    • aitchnyu 6y ago
      Whats the BigCo alternative to MS and Google office suites?
• Traubenfuchs 6y ago
  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 and the owners of the way we access the internet. And yet, that's the best they can do. It's just that hard and impossible to get it right. Sorry guys!
  • solarkraft 6y ago
    It's not the best they can do. It's the best they will do. There are companies with higher (arguably actually acceptable) quality standards, but they're few and far between.
    • onion2k 6y ago
      It's not the best they can do. Without seeing them do better there's no way to actually know that. You're assuming they're capable, but you could be wrong.
      • tracker1 6y ago
        Considering as a company, they created the first very fast JavaScript engine, massively usable browser implementation and UX features along with other applications that are pretty complex with UIs that aren't excessively slow to load, evidence is contrary. I think it comes down to their best and most experienced developers and designers are focused on other areas with higher visibility, engagement or critical function.
  • FooBarWidget 6y ago
    I think 'building cloud solutions' is higher on their priority list than 'making the UI fast'. Whether they have access to the Chrome and Angular teams is irrelevant.
  • pfortuny 6y ago
• cpcallen 6y ago
  I think the big-picture answer is that they held a "Latency Code Yellow" back in ca. 2007, and apparently stopped inculcating the same latency-sensitivity in people hired since that finished a year or so later.
• xyst 6y ago
  just goes to show that working at google is overrated.
• jeffrallen 6y ago
  > The initial HTML request is very fast and only takes about 150ms. Umm, Houston, we have a problem. That's way way way too long for a first page load of HTML only. It should be 30 ms.
• samfisher83 6y ago
  Maybe its time to move from webapps back to desktop apps? Angular, React etc. all this JavaScript seems to slow everything down. Everything in tech is so cyclical.
  • franciscop 6y ago
    I usually work with React and you can make webapps fly. If you even try a bit you can double load speed fairly easily, and if you are willing to put effort you can reach an orders of magnitude of improvements in webpage load speeds.
• monkeybutton 6y ago
  I'm surprised no one has mentioned the new AdWords UI yet, the load times are agonizingly painful.
• solarkraft 6y ago
  Many people here seem to think this is due to incompetence, I don't. It's due to a lack of focus on speed as an indicator of quality. I think Google devs are perfectly capable of building fast frontends, maybe they even want to, but if they're not rewarded for it (but are rewarded for "getting things done") they won't. It's management's fault.
  • polytely 6y ago
    But that is just managerial incompetence and the inability of the devs in question to push back against that managerial incompetence.
    • theptip 6y ago
      > that is just managerial incompetence Isn't this making a bit of a leap? Management could be correctly measuring that keeping load times below 1s will cost them $10m/year and yield them $1m/year in increased revenue (made up numbers for the sake of example, of course), i.e. making improvements would have negative ROI. I'd love for the console to be faster, but it's already way better than AWS (I haven't tried Azure so can't comment there) so I'm not sure I'd want to increase my cloud spend just to get better load times. There's a general cognitive bias on HN where performance is assumed to be a feature that your product _must_ have, because we bias heavily towards individuals that appreciate good craftsmanship in our tools. I like well-crafted tools too, but it's important to keep in mind that the ROI on polishing a tool isn't always there, and that's one of the realities of life in a world of scarcity with limited resources to be allocated. This is just speculation of course, it could well be that GCP's management is incompetent, and they haven't measured the dollar-per-unit-performance tradeoff; my point is that I don't think you've substantiated the claims of incompetence, rather you've assumed that the ROI on performance improvements must be positive. I know Google has done such experiments on the loading time for search results, I'd be interested to hear if anyone knows the details about whether this has been done in GCP.
  • pier25 6y ago
    Isn't that incompetence too?
• aequitas 6y ago
  I've come to the conclusion it's their way of telling me to use the API or the CLI. As in, why am I throwing all these meabytes of the line just to perform a single command that could be done with the API as well. If only their API wasn't as slow as well.
• msoad 6y ago
  I used to work on Google Cloud UI. Short answer is: Google Cloud org is very unlike Google. It's more like IBM or Oracle. A lot of managers and engineers are from those companies.
• asquabventured 6y ago
  youtube is the same slowwwwwwwwwwwwwwww loading experience, it really shows when you try to use it on an underpowered chromebook. It's strange to me that google devs don't dogfood their own google branded products! They just assume everyone is using the same dev workstation they are?
• pradn 6y ago
  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 priorities. Cloud is a fast-moving area, so new features are being added all the time. Even if they want to improve performance, they're limited by the frameworks you have to use. 3) For folks that are saying Google controls the browser, framework, and component library, and so should be able to do better than this, you are right. But the different divisions don't talk to each other as much as you'd think. Why should they? Angular devs shouldn't get special access compared to React, no? Whether this is an organizational failure or an enforcement of separation of concerns is up to you. I imagine critics will complain if Chrome did something special for Google properties, and they'd be justified.
  • landerwust 6y ago
    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
    • skulk 6y ago
      > 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 injection, component testing, screenshot diffing, etc. Standardization of the framework also has the benefit of making it easier to find someone to ask for help. It would be a truly herculean task to bring another framework up to the same level of support and integration of Angular inside Google.
      • shadowgovt 6y ago
        > It would be a truly herculean task to bring another framework up to the same level of support and integration of Angular inside Google. And in fact, Cloud already did this. Unfortunately, what they chose to bring up to the same level was... Angular, when they transitioned off AngularJS. They moved from a framework with known performance pitfalls to a framework with slightly fewer known performance pitfalls. It was the right move for them, but it only solved a handful of the problems they were having with the previous iteration of Angular.
• brundolf 6y ago
  Here's an anecdote: my partner used to work at PayPal, and they had a entire team dedicated to just the "wallet" portion of the web UI. There were reasons for this: that piece of the UI had to work in all nationalities, for all languages and currencies, in every browser on every device under the sun. But here's what I'm thinking: I wouldn't be surprised if every single tab in the Google Cloud UI had its own team, with their own practices, dependencies, resources that need to be loaded, etc. And I wouldn't be surprised if there's nobody in the organization whose job it is to consider the Google Cloud Dashboard as a whole product, in terms of making it a cohesive experience, eliminating redundancies between independent pieces, doing cross-cutting optimizations, getting everybody on the same page. Given how many different things are stuffed into the interface (just look at the navigation menu), that would certainly lead to some bloat.
  • shadowgovt 6y ago
    You're on the right track. A team does exist to consider the whole Dashboard, but they were late to ramp up and were initially extremely under-staffed. GCP's UI grew out of needing to unify features between Storage and the App Engine UIs, which were initially completely separate codebases. The solution started with "Just port the App Engine stuff into whatever Storage is using." But then they tried to extrapolate that model to every sub-component, and it went... Not great. And engineering management were late to realize how badly it was going.
• jameslk 6y ago
  There's something poetic about using Google's own tools to demonstrate why their own frontend code is slow. Maybe the author can suggest they use Lighthouse CI next to track which commits improve/degrade UX (but I'm guessing that's a competing product with their own).
• jeffbee 6y ago
  Perfect counterexample for the person who was telling me that single-threaded performance isn't visible to users any more. On the M1 mac mini the Google Cloud console is fully loaded in 5.1s (2.6s when cached), not 8.1s. As an enthusiast of software efficiency I don't think either of these is great, and there's obviously a lot they can do to make it faster, but it just shows how users still greatly benefit from throwing hardware at the problem.
• aloukissas 6y ago
  Hey, at least you can easily find what you want in GCP. In AWS, you're left with Googling anything you want to do.
• shadowgovt 6y ago
  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 logic is a direct consequence of this, as those components are ending up in the codebase as a side-effect of different segments of code, worked on by different teams, probably in different offices, "reusing" the same component---but not really, since they might be skewed on the version they're depending on. It's DLL hell in Javascript client form, basically. And the product as a whole is chasing feature parity, not speed of UI. The simplest way to not end up like Google Cloud UI is to not try to build a whole-product cloud solution. The second simplest way, if you're Amazon and you've already gone that road, is to have different sub-parts of your mega-architecture be different "apps" (really, different websites), each of which need pull in only the pieces it cares about, and be willing to take a whole-page refresh when the user transitions from one page to another.
  • dullgiulio 6y ago
    This comment makes little sense. AWS is even less uniform when it comes to tools, exactly because of its organic growth. This clearly has no impact on its success nor its features. Google does have a problem with management and the org-chart, but not the way you think.
    • shadowgovt 6y ago
      AWS has significant first-mover advantage, but in chasing that advantage, Google sees providing a UI as a distinguishing feature to the AWS exeprience. But their focus is on spanning the feature-set, not making the resulting UI fast. And the feature set is incredibly broad.
      • 0xy 6y ago
        GCP's interface is worse because it clearly prioritizes form over function. When I click a button in the AWS control panel, generally it works. When I click a button in the GCP control panel, there's a non-trivial chance it will result in an infinite loading screen or an ambiguous error. I see it all over Google's products (with the exception of search). Gmail loads 50mb of assets these days, and is extremely sluggish. It shows you the search bar but if you try to type in it too soon it'll skip characters and start to chop. It's embarrassing. And I'm on an i9 with a gigabit connection. Imagine how horrific it is to a user in the third world.
• StillBored 6y ago
  Actually, looking at this I'm surprised that the mainstream browsers are still caching javascript, but not some pre-parsed/compiled version of the code.
  • shadowgovt 6y ago
    It'd be glorious if there were a protocol to ship something closer to "machine code" from server directly to browser, but it doesn't exist. JS is the only language one can assume the browser can actually interpret.
    • markdog12 6y ago
      An interesting proposal: https://blog.cloudflare.com/binary-ast/ https://blog.cloudflare.com/binary-ast/ https://tc39.es/proposal-binary-ast/ https://tc39.es/proposal-binary-ast/
    • exikyut 6y ago
      I wonder how many real-world pieces need to fall into place for WASM to become a realistically viable option. Obviously browser support is one fairly big component. (I've long wondered how much of Chrome's ~65% is straight-from-dl.google.com evergreen, but I guess that's just commentary). Then there's tooling... heh. That'll be its own eternal September just like JS has been I guess.
  • markdog12 6y ago
    They do, well at least Chrome does: https://blog.chromium.org/2015/03/new-javascript-techniques-for-rapid.html https://blog.chromium.org/2015/03/new-javascript-techniques-... > Chrome 42 introduces an advanced technique of storing a local copy of the compiled code, so that when the user returns to the page the downloading, parsing, and compiling steps can all be skipped. Not sure what's going on in Google Cloud UI, though. It's a dumpster fire.
• SoSoRoCoCo 6y ago
  20% of OPs analysis could be solved by tree shaking, something we've had in webpack and its competitors for some time now.
• turtlebits 6y ago
  The AWS console isn't fast either (just shy of 1 MB of data transferred). I chalk it up to - 1. So many services all living in the same place with a variety of UI components 2. The complexity of turning all the knobs and dials of building infrastructure (or multiple pieces) into a UI. 3. Being an ancillary service (admin UI).
  • whoisjuan 6y ago
    Might not be great but AWS Console has been evolving and it's far superior than GCP Console. It baffles me when some people here in HN say that GCP's UX is better than AWS's? Like how? I use both extensively and have a way harder time to figure out what the heck is going on when using Google Cloud Console.
• neya 6y ago
  Blame the new hipster driven development with Javascript where it's ok to shove down a 100s of mb worth of assets into your user's browser whether they consent to it or not, all because you can load some fancy animations and write a blog post on your cool new JS stack. An average react JS app built using create react app actually costs you in megabytes, not kilobytes, which has somehow become the new normal. But hey, I'm not complaining. I make money turning these slow sites fast by bringing them down to a 50-100kb total. Not complaining!
• deleted 6y ago
  [deleted]
• beastman82 6y ago
  because it's the web, and thus loading everything every time, instead of a desktop application.
• divan 6y ago
  Why would anyone think that hypertext browser and typesetting tools would be a good platform for modern, fast and rich UI apps?
• endymi0n 6y ago
  Playing the devil’s advocate here, I think it‘s just very hard to build a dashboard for this scale of resources, services and users that‘s all of very (!) secure, flexible (as in terms of policies) as well as fast. Having had to use the Microsoft Admin dashboard for creating five new PowerBI users (which took me the better part of an hour), going back to Google‘s Cloud Console felt like a godsend of UX, Comfort, Sensibility and Speed.
• makecheck 6y ago
  I continue to advocate for hard download limits on the browser side that can only be overridden by scary user prompts. The defaults can be slightly larger for pages classified as “apps”, or certain file formats (e.g. when a link’s purpose is to download an entire app) but generally pages should be constrained to sizes on the order of kilobytes. As long as the floodgates can simply stay open and pages can download whatever they want, coders will remain lazy. This isn’t surprising at all.
• chubot 6y ago
  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 fast front ends. And front end devs are often using tools designed for back end devs, like the Bazel build system. (Compare that to FB having online / incremental compilers for Hack, as far as I understand.) So they either don't get the best people working on front ends, or the people they have aren't doing their best work because they're looking to move into a role that may be more respected or rewarded. Before 2005, Google built two of the most innovative AJAX apps ever: GMail and Maps. People may not remember how awesome they were. When GMail came out, it was faster than Microsoft Outlook on desktop, which I was using at the time. You would click and your message would appear instantly, which was not true of desktop apps. The app startup time was also better than desktop! (i.e. seeing all your messages from a cold start) When Maps came out, people didn't believe that the scrolling and zooming could be done without a Flash app. It also had incredibly low latency. But somewhere along the way the company lost its leadership and expertise in the web front end, which I find very sad. (I worked there for many years, but not on front ends.) The slow Google+ app circa 2011 was a great example of that, although I believe the structural problem had set in before that project. I don't think there's any question that FB and even MS are significantly more accomplished in these areas. They're the "thought leaders" (React, Reason, TypeScript, etc.) --- edit: Also, if you want to remember what Google UI looked like circa 2005, look at sourcehut: https://man.sr.ht/ https://man.sr.ht/ It was fast, simple, and had a minimalist style (though some people mistake that for no style). There is probably a generation of people who are scratching their heads at that claim, but yes that's pretty much what Google used to look like: the home page, which lacked JS; News; Groups; Webmaster Tools; Ads front end to some extent, etc.
  • kccqzy 6y ago
    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.
• markbnj 6y ago
  Is it slower than the AWS console? We use both and my subjective sense is that it isn't, but I regularly visit just a couple of specific sections in the AWS console whereas we use the Google console for a lot of things daily. I'm sure front end engineers could find a lot to complain about in the GCP console's design and implementation, but the tl;dr for me is that it works and it's fast enough for the things I need to do. In areas where the console is limiting I am probably working off the CLI anyway (daily operations within our k8s clusters for example). Probably worth noting as well that for both consoles the underlying APIs are broad, complex, and evolving at a dizzying pace. I can only imagine the technical and organizational challenges around keeping these consoles up to date and improving them where possible.
• phendrenad2 6y ago
  I keep waiting for some company to remember how fast desktop apps are and wake us all from our collective webapp delusion. I imagine native Swift on MacOS and C# on Windows desktop GUI frontends for Google Cloud wouldn't be hard to build or maintain. How often does Google Cloud change their webapp's UI?
• luord 6y ago
  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.
  • arcturus17 6y ago
    SSR wouldn't mean it'd be faster because it could have still been coded like spaghetti. You sound reasonable and I'm not directing this to you in particular, but there is a clear bias on HN that SPA sites are inherently slower or less performant, which is not true at all. Either can be fast or slow. The debate around SPA and SSR is so heated and centered on the front-end bit that people forget that UX performance depends a lot on the server. Websites are client-server systems regardless of the front-end architecture. I'd wager that the case of GCP is no different and that the perceived slow UIs are caused by problems all across the stack.
• secondcoming 6y ago
  GCP's UI controls for adding/removing instances from instance groups is appalling. It's unbelievably slow and can even lie to you (i.e. telling you an instance has been removed when it actually hasn't).
• pavelevst 6y ago
  Because more js and less html is always better. Also rendering html on server is very expensive for backend apps Also if your company has many js and backend libraries, you need to use them, at least on one place
• lukeman 6y ago
  I can only imagine how many battery cycles I've lost to the BigQuery web console, especially the jobs detail views. Safari tends to be pretty great with battery life, but it's no match for that thing.
• madrox 6y ago
  This is a hard problem for any sufficiently large application...web or otherwise. Solving it, in my experience, requires a strongly supported central body focused on managing code quality across teams. I know this is a relatively straightforward exercise with large React apps. I've never seen it done with Angular to know how difficult that is. Doing this all comes with a cost of maintaining that team and possibly slower development, of course. However, I assert that no cloud provider has won or lost significant cloud deals based on the speed of their UI, and most engineers who live in the cloud do so through CLI tools. While people may not like it, and perhaps it's caused some engineers to do something different for personal projects, this is rightly not a KPI for Google Cloud, hence the state of of the cloud console.
• rasz 6y ago
  >JavaScript 15.7 MB Some time ago Google moved away from rendering pages server side. Youtube right now downloads 1MB of mostly json packed data for client side rendering. Irony of this is old Youtube layout (pre Polymer, their client side YT rendering engine) downloaded ~30KB of pre rendered html. The difference to users is Youtube website visibly slowly appearing in front of your eyes (while one CPU core is pegged at 100%) instead of Old YT just loading instantly and working.
• lowdose 6y ago
  I can find my way easier in Google Cloud than in AWS. The services are also more polished and seem more mature compared to AWS. I'm about to give Google Colab Pro a try because the free version has been deteriorating.
• dub 6y ago
  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.
  • iooi 6y ago
    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.
    • dub 6y ago
      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.
• sleepy_keita 6y ago
  I originally didn't like AWS's console because it wasn't "consistent", but when I opened up GCP's console the first time, I immediately preferred AWS. Fast and usable is better than inconsistent.
• bjornsing 6y ago
  > We can see that each page loads over 15 MB of JavaScript code. It’s rumored that the compute Google sells is actually performed by that JavaScript code, running in customers browsers. :P
• geekster777 6y ago
  Former front-end dev of this UI here. This article makes the assumption that Google's primary goal is performance/page load. It's not. Feature parity and dev speed is. With a gigantic app like Cloud with hundreds of developers, there are massive technical hurdles surrounding things like independent releases, split bundles, and technical debt. Google's business model for Cloud is b2b. The bottom line for getting b2b contracts normally comes down to requested features (among other things). Page load time doesn't factor as much comparatively, so these priorities do make sense. Not to say performance isn't on everyone's roadmap, but Google has and will continue to make strategic decisions that sacrifice performance over things like dev speed.
  • freediver 6y ago
    Google seems to fail to realize that cloud b2b starts with b2developer. A one single developer. Create an environment that developers love, and these developers will find ways to make b2b happen. Sell bottom up. (and in case anyone from gcp is reading, not only the interface is atrociously slow - which makes me doubt the quality of engineering on the infrastructure side of things that I am supposed to be paying for - but the quota system is beyond terrible as well. Just the other day I wanted to experiment with youtube api to see what it can do, and it made me fill a quota increase form with at least two dozen questions almost asking what is my business plan with this - do you want users to use the api or not?)
    • themacguffinman 6y ago
      Even solo developers don't really choose a cloud platform based on the zippiness of the web UI. I've used Azure and briefly dabbled in AWS's web UIs, they're not better and are worse in some cases. Critical administration tasks are going to be wrapped and reused in CLI, the web UI is usually for ad-hoc stuff. This is a pretty core staple of the b2b market: customers, even small ones, respond mostly to price & features that save a significant amount of time & money; Sorry but a sluggish web UI while annoying won't move the needle much on the bottom line.
    • harpratap 6y ago
      Not sure which awesome company you work at, but in most organizations infra is a cost center, and thus the decisions related to it are mostly done by managers, not developers. And this is why AWS sells and not Heroku.
• Ono-Sendai 6y ago
  Reminds me of the MS azure page taking 17 seconds to load: http://forwardscattering.org/post/41 http://forwardscattering.org/post/41
• nojvek 6y ago
  Google controls the chrome browser, angularjs and google cloud UI. With the smartest engineers, we still see a shitty user experience. Just goes to say hiring engineers doesn’t solve problems. Focusing relentlessly on user experience, having performance and reliability as an org goal gets things done. As you add more people, each of them has less autonomy on the customer experience.
• ernsheong 6y ago
  Personally, the Google Cloud Console UI is an engineering marvel. The amount of complexity is, to my imagination, mind-boggling. That is just works most of the time is amazing. Complex workflows that other require you to visit 10 pages to complete a thing is seamlessly executed for you with sidebar UIs, etc. I'm sure the performance bit of it would catch up soon. But who is using it anyway, and surely these people have pretty good internet. Not vindicating, but I'm sure the optimization will come later.
• runawaybottle 6y ago
  I’ll just say as a meta comment that this thread is some of the most beginning-to-end Google frontend development ingenuity and organizational imperatives bashing I’ve ever read here. There’s not a single poster here that didn’t throw a rock. In defense of large orgs, faangs and non faangs, from my experience I can tell you that some talented developers on teams will notice exactly what is wrong with a product (frontend or backend). They might know parts of the UI need to be trimmed and made performant, api calls need to be restructured to be made performant, and so on, but don’t speak up. There’s a variety of reasons here and it mostly has to do with the old adage ‘no good deed goes unpunished’. On teams there are egos, and you will bring out unwanted peer pushback (who do you think you are with your fancy ideas all the time, you don’t think the rest of us thought of this too?) when you take up some of these mantles. This is a dynamic that is coupled with general management issues that come from the product/project management, where your great idea might not be seen as worthwhile. On a team, socially and professionally, it’s better to not rock the boat here because the reward is not fair, and if it were outsized, it could be taken bad by coworkers as grandstanding. Why bother? Which leads to the manifestation of the phenomenon: death-by-a-thousand-cuts. This is where professionally team members look like people with a self absorbed agenda. Now no one ever takes up reducing the bleeding, and finally, a world class company, with world class talent, builds laughably bad end results. The only solution to this is for the egos to restructure the direction of their energy into a monomaniacal focus on ‘the final product is all there is’, where a good idea is a good idea. The ego has to be abstracted into the final output, where everyone involved derives their self worth from how good the thing they shipped is, and nothing else matters.