[bsimpson]

Speaking personally (I happen to work at Google, but not on mail):

The combinatorics of supporting multiple versions of a product get expensive very quickly. It's the same reason that web platform changes now affect evergreen browsers directly (even with the occasional breaking change), rather than introducing more modes like quirks and strict.

Every variant you introduce grows the surface area for bugs and security issues, and adds at least one more case to consider when implementing new functionality. Even if you froze the featureset in the old UI, you'd still need to maintain compatibility with it as the backend evolves. It's not as simple as just leaving the old codebase running on a server somewhere.

If Google wanted to invest in multiple mail products, it wouldn't have end-of-lifed Inbox.

[JoshuaAshton]

I mean... if it takes 23 seconds to load on my machine, and the old version took less than 3, maybe its not worth maintaining the new version to begin with. Just a thought.

[hoffs]

If it takes 23 seconds to load you definitely have an issue and not new Gmail.

[bad_user]

I disagree, if it took 3 seconds to load and now it takes 23, given mostly the same features, it means the software is broken, not the hardware it runs on.

[joshuamorton]

I think the point is moreso that 23 seconds is abnormal, not the experience of most users, and therefore likely either not consistent for you (maybe your WiFi connection dropped) or due to some wierd configuration on your end.

(Technically speaking, I work on Gmail, but unrelated to this)

[londons_explore]

Mine takes 21 seconds to fully load, including the tasks and calendar sidebar from a fresh browser start with no caches and cookies, but only timing from clicking the sign in button.

[joshuamorton]

I think that's misleading. I tested a few times this morning, and had clean-cache "load" times of 10-35 seconds, but I could use the app within 5 and chrome devtools showed ready in under 10.

So I'm curious what your metric is. Is it until the last resource is fully rendered in devtools, until the ready action fires, or until you can actually do things?

[exikyut]

I think Inbox was an interesting approach to "fixing Gmail", which I've long had un-cite-able suspicions of internally being horribly broken (in the sense of maintainability and elegant architecture, not visible bugs).

Amongst only 11 outages in 14 years of continuous operation and use by probably a billion people, in 2011 Gmail lost 0.02% of users' email due to "a storage bug" that nuked all copies of data, and they had to restore from tape: https://gmail.googleblog.com/2011/02/gmail-back-soon-for-eve...

This status quo and example, along with the fact that https://google.com/appsstatus lists Gmail at the top, is a clear demonstration that Gmail is probably locked down so tight _everything_ has to be demonstrably proven to be at near-aviation-grade reliability before it's rolled out. I wonder if the Gmail team retains the same people from 5-10 years ago to minimize the amount of onboarding churn and maximize the chances things will be broken from unfamiliarity.

The Inbox idea was pretty inspired: _start again_, make a separate property/"brand", keep it reasonably niche, and you can get away with an effectively-lower SLA. And then once you get past the teething problems and speedbumps you can pivot the functionality back into Gmail.

But yeah, doing the pivot/fold-in does nuke the identity that got created. That makes power users who liked it more sad. And obviously you can't tell everyone the project is temporary or it won't go viral.

These systemic issues are not at all unique to Google, of course.