6 ms·

> it's as if Google can't find good frontend engineering talent, i don't get it :/ They can. Addy Osmani, Paul Irish, the PWA people, etc. They just don't seem

> it's as if Google can't find good frontend engineering talent, i don't get it :/ They can. Addy Osmani, Paul Irish, the PWA people, etc. They just don't seem to employ them to actually make user-facing products.

leeoniya 9y ago
> They just don't seem to employ them to actually make user-facing products. it's fine if the high-level public-speaking folks aren't doing this, but the problem is that no one seems to be doing it. anyone can open up the DevTools network panel during a Gmail load, then look at the timings, payloads and generated DOM to see that it's almost entirely absolute shit by Google's own standards, even in Chrome on a fast desktop; they still use MochiKit ffs. there are at least several hundred engineers here on HN that can rewrite the Gmail UI to be "blazing fast" without gutting features and would still work great even on old phones still running Android 4.4.4 (with latest Chrome). obviously Google knows all of this, they just don't care because there's no measurable ROI in a faster free Gmail compared to getting people to host their juicy AMP content on Google's servers. "It's what the users want" is a half-truth optimized for maximum PR value; a bit like "Don't be evil".
- DamonHD 9y ago
  Almost all the complaints on technical site performance I get from tools such as PageSpeed Insights and WebpageTest are indeed about Google's stuff, not mine, and as far as I can tell entirely unnecessarily. Eg leaving at least some of their own static site-furniture graphics not fully minimised and not cacheable? Likewise the CSS. I keep removing Google stuff from my properties because it outweighs my stuff by typically 10:1, again entirely unnecessarily AFAIK!
- roywiggins 9y ago
  And Inbox is even worse. It's fine on a modern beefy desktop but brings my slightly anemic ye olde Linux box to a standstill, whereas GMail is still basically fine.
nevir 9y ago
Addy, Dominic, Eric, the Pauls, etc are (mostly) dev outreach for the Chrome team, which is why they're so well known. There are a LOT of talented frontend devs in Google; you just don't see them much externally. That being said, there is also a toxic stance from many Google engineers (and management) that JS is a "lesser" language, and that feeling often translates to the devs that work in it.
- leeoniya 9y ago
  > There are a LOT of talented frontend devs in Google...many Google engineers (and management) that JS is a "lesser" language And exactly what language do these fine folks do their frontend development in, Go, C++? Google sure spends a lot of resources on this lesser language for how few engineers want to work with it.
  - nevir 9y ago
    > And exactly what language do these fine folks do their frontend development in, Go, C++? For a very long time, GWT (Java compiled to JS) was the preferred approach. Then development moved to the Closure compiler (JS following very Java-like patterns), and only very recently is ES6 style code taking off. Much of the code you see still carries the legacy of GWT/Closure (and there is so much there that porting would be an insane task). It's a slow process. But, for example, YouTube is switching over to Polymer (https://youtube.googleblog.com/2017/05/a-sneak-peek-at-youtubes-new-look-and.html https://youtube.googleblog.com/2017/05/a-sneak-peek-at-youtu...). > Google sure spends a lot of resources on this lesser language for how few engineers want to work with it. Google is a massive company, with many different (often conflicting) initiatives. Chrome spends a lot of effort on JavaScript; but Chrome engineers are (for the most part) not the ones that are writing Google's frontend code.
    - leeoniya 9y ago
      > For a very long time, GWT (Java compiled to JS) was the preferred approach. fine, but this is entirely irrelevant. the problem is that no one was optimizing for the deliverable (HTML, JS, CSS). the GWT folks could have easily written an excellent compiler so it didnt spew a bunch of unoptimized and bloated trash. > YouTube is switching over to Polymer which requires a massive slow polyfill in all but latest Chrome and results in a shit experience for all others (if i recall a related thread correctly [1]). [1] https://www.reddit.com/r/javascript/comments/68vehl/youtubes_new_ui_uses_polymer/ https://www.reddit.com/r/javascript/comments/68vehl/youtubes...

leeoniya 9y ago

> They just don't seem to employ them to actually make user-facing products. it's fine if the high-level public-speaking folks aren't doing this, but the problem is that no one seems to be doing it. anyone can open up the DevTools network panel during a Gmail load, then look at the timings, payloads and generated DOM to see that it's almost entirely absolute shit by Google's own standards, even in Chrome on a fast desktop; they still use MochiKit ffs. there are at least several hundred engineers here on HN that can rewrite the Gmail UI to be "blazing fast" without gutting features and would still work great even on old phones still running Android 4.4.4 (with latest Chrome). obviously Google knows all of this, they just don't care because there's no measurable ROI in a faster free Gmail compared to getting people to host their juicy AMP content on Google's servers. "It's what the users want" is a half-truth optimized for maximum PR value; a bit like "Don't be evil".

DamonHD 9y ago
Almost all the complaints on technical site performance I get from tools such as PageSpeed Insights and WebpageTest are indeed about Google's stuff, not mine, and as far as I can tell entirely unnecessarily. Eg leaving at least some of their own static site-furniture graphics not fully minimised and not cacheable? Likewise the CSS. I keep removing Google stuff from my properties because it outweighs my stuff by typically 10:1, again entirely unnecessarily AFAIK!
roywiggins 9y ago
And Inbox is even worse. It's fine on a modern beefy desktop but brings my slightly anemic ye olde Linux box to a standstill, whereas GMail is still basically fine.

nevir 9y ago

Addy, Dominic, Eric, the Pauls, etc are (mostly) dev outreach for the Chrome team, which is why they're so well known. There are a LOT of talented frontend devs in Google; you just don't see them much externally. That being said, there is also a toxic stance from many Google engineers (and management) that JS is a "lesser" language, and that feeling often translates to the devs that work in it.

leeoniya 9y ago
> There are a LOT of talented frontend devs in Google...many Google engineers (and management) that JS is a "lesser" language And exactly what language do these fine folks do their frontend development in, Go, C++? Google sure spends a lot of resources on this lesser language for how few engineers want to work with it.
- nevir 9y ago
  > And exactly what language do these fine folks do their frontend development in, Go, C++? For a very long time, GWT (Java compiled to JS) was the preferred approach. Then development moved to the Closure compiler (JS following very Java-like patterns), and only very recently is ES6 style code taking off. Much of the code you see still carries the legacy of GWT/Closure (and there is so much there that porting would be an insane task). It's a slow process. But, for example, YouTube is switching over to Polymer (https://youtube.googleblog.com/2017/05/a-sneak-peek-at-youtubes-new-look-and.html https://youtube.googleblog.com/2017/05/a-sneak-peek-at-youtu...). > Google sure spends a lot of resources on this lesser language for how few engineers want to work with it. Google is a massive company, with many different (often conflicting) initiatives. Chrome spends a lot of effort on JavaScript; but Chrome engineers are (for the most part) not the ones that are writing Google's frontend code.
  - leeoniya 9y ago
    > For a very long time, GWT (Java compiled to JS) was the preferred approach. fine, but this is entirely irrelevant. the problem is that no one was optimizing for the deliverable (HTML, JS, CSS). the GWT folks could have easily written an excellent compiler so it didnt spew a bunch of unoptimized and bloated trash. > YouTube is switching over to Polymer which requires a massive slow polyfill in all but latest Chrome and results in a shit experience for all others (if i recall a related thread correctly [1]). [1] https://www.reddit.com/r/javascript/comments/68vehl/youtubes_new_ui_uses_polymer/ https://www.reddit.com/r/javascript/comments/68vehl/youtubes...