For anyone who cares about the Web, this is just incredibly sad. "Progressive Enhancement" (the idea that the Web should work with basic things like HTML, and that CSS and JS should be "extensions...
For anyone who cares about the Web, this is just incredibly sad. "Progressive Enhancement" (the idea that the Web should work with basic things like HTML, and that CSS and JS should be "extensions that enhance the experience" rather than "things the Web won't work without") is something that Google itself has pushed through it's Developer Training and Relations programs, as well as its presence in standards bodies like the W3C (which it has effectively captured at this point).
HTML Gmail was perhaps the best example of Progressive Enhancement on the entire Web: something you could point out to the overexcited Junior devs and say "see: even Google does this" to overcome their bad instincts to make inaccessible products and features.
Now it's just more "do as we say, not as we do" from Google. My other least favorite example of this is google.com itself, which uses like 0 semantic elements: it's <div>s all the way down, despite them lecturing everyone to use navs and sections (so their crawlers can index it better).
It's not like we all didn't know that putting the fate of the greatest communication tool in human history in the hands of one company was a terrible idea the whole time. It's just that seeing it inexorably crumble, piece by fundamental piece, is horrific.
The problem with "progressive enhancement" is that people demand increasingly rich and functional applications delivered through the web, and the best ways to deliver those do not easily "fall...
The problem with "progressive enhancement" is that people demand increasingly rich and functional applications delivered through the web, and the best ways to deliver those do not easily "fall back" on simpler technologies. You end up having to build two completely different versions of your web app.
The web app I build for my work would be borderline impossible without JavaScript, and the amount of time and effort I would have to put in to building a plain HTML fallback for it would increase the time and money needed to build or enhance it five fold. My reliance on JavaScript frameworks allows me to do with two engineers what would otherwise take ten.
This isn't really meant to be a defense of Gmail, since email is something that is pretty easy to implement with basic HTML forms and some CSS to pretty it up. But I see this sentiment crop up for far more complex web apps made by relatively small teams, and it kind of drives me up a wall sometimes. Not every app makes sense as a web form.
Rough translation: "We can't track you as well," perhaps?
"The Gmail Basic HTML views are previous versions of Gmail that were replaced by their modern successors 10+ years ago and do not include full Gmail feature functionality." (emphasis added by me)
Rough translation: "We can't track you as well," perhaps?
I don't have specific knowledge here, but my prior is that maintaining a service on two different platforms at feature parity is very, very painful. At the same time, I imagine that the majority...
I don't have specific knowledge here, but my prior is that maintaining a service on two different platforms at feature parity is very, very painful.
At the same time, I imagine that the majority of user data they can harvest is also possible in the HTML version. All email contents and all operations you perform on the emails are still knowable, for instance.
Combined with the presumably-dwindling number of people using the HTML views, and Google's recent layoffs and budget cuts, I think their decision to deprecate Gmail Basic is fully explainable without reading too deeply into it.
I wonder how popular it is. The few times I've tested it, I found it loaded much faster initially, but then load times would start mounting the longer I used it. It needed to send a full page load...
I wonder how popular it is. The few times I've tested it, I found it loaded much faster initially, but then load times would start mounting the longer I used it. It needed to send a full page load on every click, so there was actually a lot more waiting as I navigated around.
The full Gmail is heavier on initial load, but smoother after that. I'm not sure why The Register is confused about it downloading more data since it's caching all of your messages in the background. That's actually quite nice because it allows you to still read and draft messages, even if your internet is down. Its offline support is a whole lot smoother than the old Google Gears interface, if anyone remembers that.
I think the basic HTML version is probably still useful if you need to quickly check in, do one task, and get out. I happen to live in my inbox, but a lot of people still rarely get or send email, so that quick check in might be a better experience for them.
I'd be curious to see the accessibility claims tested. The Gmail UI is a little div soupy, but that doesn't actually matter that much for screen readers. Big tech companies actually put a lot of effort into making websites accessible so I'd be surprised if Gmail wasn't. Especially since Robles v. Domino's, it's often the first consideration of a redesign.
Can someone enable my laziness and point me to a summary of Robles v. Domino's? I can't find a wikipedia article and I'm reluctant to wade through the links that google returned.
Can someone enable my laziness and point me to a summary of Robles v. Domino's? I can't find a wikipedia article and I'm reluctant to wade through the links that google returned.
Simon Sharwood Intriguingly, when we used Chrome's Inspect>Network tool to test the HTML page's load time, it came in at 1200 milliseconds. Full fat Gmail loaded in 700 milliseconds – but then...
Simon Sharwood
Google is infamous for discontinuing services that – for whatever reasons – don't meet its goals. Over the years it has killed off favorites like its RSS reader, flops like Wave, projects like Google Code that lost to rival offerings, and invasive ad tech that its peers rejected.
The Register asked Google when the decision to end Basic HTML was made, and why.
A spokesperson sent us the following statement:
"The Gmail Basic HTML views are previous versions of Gmail that were replaced by their modern successors 10+ years ago and do not include full Gmail feature functionality."
But the Big G has also kept some offerings alive after user uprisings. In 2022, for example, it persisted with the free G Suite legacy edition after fielding many complaints from users who felt they were promised the service would be available in perpetuity.
Google insists it is "committed to making accessibility a core consideration" and lists many accessibility features in Gmail – among them screen reader support and hands-free email.
Google suggests that not including "full Gmail feature functionality" is the point of the Basic HTML offering. When your correspondent loaded it, Google delivered a warning that it is "designed for slower connections and legacy browsers."
Intriguingly, when we used Chrome's Inspect>Network tool to test the HTML page's load time, it came in at 1200 milliseconds. Full fat Gmail loaded in 700 milliseconds – but then kept loading elements for almost a minute before settling down.
Google is also closing YouTube Premium Lite in Europe, and Google Podcasts, planning to migrate to YouTube Music and its native podcast functionality. We’ll see how that goes.
Google is also closing YouTube Premium Lite in Europe, and Google Podcasts, planning to migrate to YouTube Music and its native podcast functionality. We’ll see how that goes.
As sad as this is, I kind of understand why they're doing this. I myself work on a service that has both a legacy version and modern version and while we don't promise feature parity between the...
As sad as this is, I kind of understand why they're doing this. I myself work on a service that has both a legacy version and modern version and while we don't promise feature parity between the two, maintaining that legacy service is quite a lot of work. You have to consider the ratio between the amount of effort needed to keep it running and the number of users/amount of money it generates. There's a point where this ratio means it's simply not worth maintaining because it either requires too much effort or doesn't bring in enough money and I assume this HTML only version has reached that point.
For anyone who cares about the Web, this is just incredibly sad. "Progressive Enhancement" (the idea that the Web should work with basic things like HTML, and that CSS and JS should be "extensions that enhance the experience" rather than "things the Web won't work without") is something that Google itself has pushed through it's Developer Training and Relations programs, as well as its presence in standards bodies like the W3C (which it has effectively captured at this point).
HTML Gmail was perhaps the best example of Progressive Enhancement on the entire Web: something you could point out to the overexcited Junior devs and say "see: even Google does this" to overcome their bad instincts to make inaccessible products and features.
Now it's just more "do as we say, not as we do" from Google. My other least favorite example of this is google.com itself, which uses like 0 semantic elements: it's <div>s all the way down, despite them lecturing everyone to use navs and sections (so their crawlers can index it better).
It's not like we all didn't know that putting the fate of the greatest communication tool in human history in the hands of one company was a terrible idea the whole time. It's just that seeing it inexorably crumble, piece by fundamental piece, is horrific.
The problem with "progressive enhancement" is that people demand increasingly rich and functional applications delivered through the web, and the best ways to deliver those do not easily "fall back" on simpler technologies. You end up having to build two completely different versions of your web app.
The web app I build for my work would be borderline impossible without JavaScript, and the amount of time and effort I would have to put in to building a plain HTML fallback for it would increase the time and money needed to build or enhance it five fold. My reliance on JavaScript frameworks allows me to do with two engineers what would otherwise take ten.
This isn't really meant to be a defense of Gmail, since email is something that is pretty easy to implement with basic HTML forms and some CSS to pretty it up. But I see this sentiment crop up for far more complex web apps made by relatively small teams, and it kind of drives me up a wall sometimes. Not every app makes sense as a web form.
Rough translation: "We can't track you as well," perhaps?
True or not that's always the subtext I see when I read these kinds of things.
I don't have specific knowledge here, but my prior is that maintaining a service on two different platforms at feature parity is very, very painful.
At the same time, I imagine that the majority of user data they can harvest is also possible in the HTML version. All email contents and all operations you perform on the emails are still knowable, for instance.
Combined with the presumably-dwindling number of people using the HTML views, and Google's recent layoffs and budget cuts, I think their decision to deprecate Gmail Basic is fully explainable without reading too deeply into it.
I wonder how popular it is. The few times I've tested it, I found it loaded much faster initially, but then load times would start mounting the longer I used it. It needed to send a full page load on every click, so there was actually a lot more waiting as I navigated around.
The full Gmail is heavier on initial load, but smoother after that. I'm not sure why The Register is confused about it downloading more data since it's caching all of your messages in the background. That's actually quite nice because it allows you to still read and draft messages, even if your internet is down. Its offline support is a whole lot smoother than the old Google Gears interface, if anyone remembers that.
I think the basic HTML version is probably still useful if you need to quickly check in, do one task, and get out. I happen to live in my inbox, but a lot of people still rarely get or send email, so that quick check in might be a better experience for them.
I'd be curious to see the accessibility claims tested. The Gmail UI is a little div soupy, but that doesn't actually matter that much for screen readers. Big tech companies actually put a lot of effort into making websites accessible so I'd be surprised if Gmail wasn't. Especially since Robles v. Domino's, it's often the first consideration of a redesign.
Yeah, I was about to say. HTML-only-ness doesn't necessarily mean more accessible, nor does more JS necessarily mean less accessible.
Can someone enable my laziness and point me to a summary of Robles v. Domino's? I can't find a wikipedia article and I'm reluctant to wade through the links that google returned.
Simon Sharwood
I've used this a few times when all I had was very slow mobile internet -- farewell, old friend.
Google is also closing YouTube Premium Lite in Europe, and Google Podcasts, planning to migrate to YouTube Music and its native podcast functionality. We’ll see how that goes.
As sad as this is, I kind of understand why they're doing this. I myself work on a service that has both a legacy version and modern version and while we don't promise feature parity between the two, maintaining that legacy service is quite a lot of work. You have to consider the ratio between the amount of effort needed to keep it running and the number of users/amount of money it generates. There's a point where this ratio means it's simply not worth maintaining because it either requires too much effort or doesn't bring in enough money and I assume this HTML only version has reached that point.