Hacker News new | past | comments | ask | show | jobs | submit login
AMP for email is a terrible idea (techcrunch.com)
1151 points by coloneltcb on Feb 14, 2018 | hide | past | favorite | 465 comments

Nothing says “we’re listening to your concerns about AMP” like rolling it out further to interfere with a function that is even less suited for AMP.

Also, technology companies have a real problem assigning appropriate value to maintenance tasks that just keep things stable and usable. I’ve had infrastructure responsibilities over the years and the hardest thing about it was that nobody really knows or cares how much trouble you put into having things work flawlessly for months or years on end. It was important to find lots of visible tasks to go along with the invisible ones. I guess you end up with things like 40 Google chat clients and “hey let’s screw with E-mail” when there isn’t enough promotion-worthy work left to do in those areas.

Part of why I don't advocate for CDNs when you don't need them is because I want to build robust sites that work for years untouched. For timespans over a year, anything not on your server is brittle. Oops, CDN changed its URL/didn't update their ssl ciphers/went bust and shut down completely and now {js-framework}/{css-library} is missing and my site is broken. What an unforeseeable circumstance!

That's why I like to map one of my own subdomains to the cdn service.

So everything is at cdn.example.com and if I change providers, it's just a dns record change and everything is ready, even if I want to just host my own content.

Doesn't that kill the possibility that a visitor will already have common content cached when visiting your site for the first time? I know that's not the only reason to use a CDN, but it's a pretty big one.

In my experience, the variety of specific versions of libraries sites are locked to dilutes that performance benefit. Just look at a cross-sampling of sites calling jQuery or <insert your favorite library or framework here>.

In theory, the maximum benefit of a CDN only comes if everyone is on 1) the same version or, similar but different, 2) an evergreen version. And the latter is a big red neon sign screaming "DANGER".

And the parts that everyone is on, became standardized in the browser: document.querySelector, CSS animations, async stuff, etc.

Honestly with all the versions of js libraries and all the CDN hosts, the limitations of cache size and the insane bloat of webpages, I think you're going to have to be pretty lucky to get any beneficial cache hits from unrelated third party sites.

IF you have some stuff you think some visitors will have cached, well then you can use the standard google or jquery CDN or whatever (they're free anyway). For everything else you would run from your own CDN url.

I thought that too but even for the most common stuff like font awesome cdn cannot be trusted - just too many silent outages that were only discovered from user complaining because they impacted different geographical areas differently..

IIRC the argument was that JS bloat is okay "because we can cache common content through CDNs" ... or that's how it felt at the time :)

It sort of/kind of started with jQuery, and in those days including jQuery was considered somewhat bloaty. I think it was about 18kB minified back then? Today their site says it's 30kB.

Either way that's miniscule compared to having a few pictures on your webpage. Having much more JS than that, honestly seems like true bloat to me, which I don't think CDNs should facilitate anyway (so much untrusted unknown unchecked code doing very, very filthy things).

My point is, it wasn't a very good argument back then either, but it became normal because people did it for other reasons, too.

The main reason people did it, was that it was just so much easier. Just copypaste those 1.5 lines of code in your <HEAD> section to include the latest version of jQuery from Google's CDN, instead of downloading it and putting it somewhere in your source tree and now you've got to keep track that different parts of your codebase written months apart don't accidentally use slightly different versions (because it's ugly, not because it mattered a lot otherwise), etc.

Such convenience!

And if someone asked if it was really a good idea to blindly load 3rd party code and run it in the context of your own domain? Even I told people this sometimes: Well if you can't trust Google serving you secure code, then the web is basically fucked anyway, and we got much bigger problems. Which seemed like a reasonable threat model / security trade off at the time.

And now we're here.

About a week ago Google got caught hosting hostile ads that included cryptocoin miners inefficiently wasting users' electricity for a few bucks (profit insignificant compared to the cost of energy wasted). And apparently Google's offering to blindly host 3rd party JS to all users on the entire Internet everywhere (except the adblockerati), via their fucking ad network, has been expected behaviour for over a year at least and nobody gave a peep when that malfeature appeared.

I still don't know the exact date when or if there even was an announcement when they allowed advertisers "sure do whatever you like to their browsers, run some code, compute stuff, track them in all the ways we haven't dared to deploy publicly, or yet thought of, have at it, you need this, you do you".

So yeah, the web is fucked, we got bigger problems and hell no you can't trust Google any more.

> Either way that's miniscule compared to having a few pictures on your webpage.

A visitor can decide to not display images to improve performance and this will not break the website, blocking the (often not useful) js on the other hand...

> And if someone asked if it was really a good idea to blindly load 3rd party code and run it in the context of your own domain? Even I told people this sometimes: Well if you can't trust Google serving you secure code,

You overlooked the privacy and personal data issue here. It's a bad idea to rely on anything google because it means that you give away the privacy of your visitor to one of the worst offender no less.

> About a week ago Google got caught hosting hostile ads ...

Google has been delivering malware, spyware and that kind of things for years. It was even considered a major vector of infection (usually someone looked for flash on google and clicked on the first results which happened to be a google ad for an infected flash installer)

Wouldn't the paths change between providers?

Many providers simply map to your live site structure. So I keep everything on my own site and do the initial upload there. The CDN looks to my site to get the original copy when they receive a request for a file they don't have cached.

Dont't forget build tools.

Good luck updating a site that used the latest and greatest build tools that are now depricated.

Fun thing: a lot of times I download the Javascript from a CDN because then I don't need build tools because it was already built for me on the CDN...

People focus too much on ship fast.

They get in trouble when the product becomes a success.

Right, better to have your site fail today, then to risk it failing in the future. You couldn't make an archive of your site for emergency access.

Why would it fail today? If I can't serve an asset then my whole server is down.

If you are an e-commerce site serving hundreds of images worldwide then CDNs make a tonne of sense.

If you just have a simple site or SaaS getting decent traffic, why add a failure point by including your choosen JS with a CDN. No one batts an eyelid when you add ten images to the homepage but somehow a single, much smaller JS file is too much extra load. It doesn't stand up to reason.

Noting I couldn't quite figure out the tone of your comment to know if you were agreeing or disagreeing.

I'm waiting for AMP chat; I hear it's fast. /s

And you can run it on any platform, so long as it's Google's. The best user choice since the color of your Model T.

And it will supplant Duo and Allo, that were/are supposed to supplant (or augment, or co-exist -- can't we all just get along?) Hangouts, that was supposed to integrate SMS and MMS, but bollocks.

Anyway, I prefer my email to remain immutable after initial transmission. I don't need another Snapbookthingie...

Which reminds me, Google: You already hosed search results with your first... or second, or third, buzzzzzz... big social, dynamic (comments) push, Plus.

And almost nobody liked Buzz, nor the way you tried to shove it down our throats.

Are you really going to take another stab at sabotaging one of your successful products -- this time, Gmail?

You HAD a successful social platform: Reader. And you nuked it.

You want "social" and "changing content"? Bring back Reader.

Buy a clue.

One of my coworkers to this day was so upset by the Google Reader fiasco that he has not used any google service in any form since then.

I was really upset by it too. I used to start my day with Google Reader the same way my dad used to start his day reading the newspaper. This was a crucial part of my morning ritual, and I trusted and relied on Google to maintain it for me. The sudden announcement that it would be taken away felt like a betrayal. It shattered my image of Google and made me completely rethink my dependence on them and seek out alternatives wherever I could.

I was too. For personal use I eschew new products by Google. iPhone is starting to have big issues but I'll never go back to a Google phone, computer, tablet etc.

AMP has gotten me to finally switch to Duck Duck Go. Gmail is too difficult to leave, but AMP for gmail may finally get me over the edge.

Still wish there was an rss reader as good as G. Reader.

I agree.

It was probably the single best social thing I’ve ever used. It was unique as it was actually social. Both my teams at work and family/friends used it as a way to comment on news and share stuff of interest. It was also a product of an earlier era where there was excitement over anything Google released.

Google+ tried to capture many of the good parts of reader... but it was too forced.

The social aspect was the one part of Reader I never got. I don't think anyone I know uses RSS feeds outside of podcast subscriptions. I just liked that it was the only RSS reader I had ever found that just worked, and it synced my state as a bonus.

I would love to move back to RSS for the sites I read regularly, but no one seems to offer RSS anymore...

You might try contacting the owners and requesting they add one.

AFAIK, Google Now, which is well baked into Android uses RSS feeds. It might not be that people subscribe to them manually, but I'm sure there are plenty of people who do consume content from RSS feeds through things like Google Now. I personally find it nifty to receive updates on blogs according to my search history.

Those people aren't using RSS feeds in a way that would make something like Google Reader social for me.

> You want "social" and "changing content"? Bring back Reader.

But we can't blast you with ads via Reader. What's the point of that?

uuh, they could've. they just didn't.

its pretty easy to parse the content of an rss/atom feed and show targeted ads.

AMP runs in any web browser. Bing serves AMP search results to Firefox.

And the offers the assistant delivers as ads will be extremely light-weight, signed off by Google-headed committee.

Slack needs that! haha

Google is bad at product.

" “modernize” email, allowing “engaging, interactive, and actionable email experiences.” "

Whenever a service or company purports to make something "engaging" and "interactive" you just know that useability and actual, tangible usefulness are going to go out the window in favour of marketer-driven choices.

We don't 'engage more' with your software/service because you changed everything to optimise for engagement and time spent, we engaged more because it took more time/steps to get the same thing done.

Arguably what we should be doing is optimising for less time spent on an app/service for the purposes of enabling a better/more efficient/more enjoyable experience by letting users get what they want to do done quickly and easily.

You are making a mistake in thinking you are the customer. You are the product.

When using gsuite, I am the customer.

Then hopefully I can turn it off in my GSuite administration account...

...doubt it.

I have always wondered - is there someone you can chat with or call for GSuite?

Yes. It was my first and only call with Google tech support. Noticeably outsourced, but competent after escalation.

> competent after escalation.

Was escalation as simple as "I would like to speak to a supervisor, please," or was there a more complicated incantation?

I believe the phrase you're looking for is "Klaatu barada nikto!"

I said "necktie" and now my computer has daemons.

Hail to the king, baby!

In the same way when you pay for cable TV you are the customer... not really.

If you live in a town where FIOS is active, you are magically a customer again.

Until they sell you off to Frontier. Frontier decided all the movies I bought from Verizon weren't mine anymore. No compensation, no apologies.

The whole idea of “selling” something that the customer don’t actually receive, and has no rights to, is insane. It’s tantamount to false advertising, and I think it should be made illegal.

As much as we all hate cable, telephone companies are more evil.

Verizon in particular is amazing in their priorities from an operational perspective are getting rid traditional phone business at all costs and spiting the CWA.

That's how the world used to be. Now you're either a customer or not. You will always be the product.

For totally unrelated tinfoil-hat reasons I started using fastmail yesterday. Now I feel very vindicated in my choice, but it makes me wonder; since Gmail is so pervasive, will this action by them end up f-ing up email for everyone, the same way that many sites claim to only work on Chrome?

AMP for email would be another reason to start using fastmail myself. I probably share the same "tinfoil-hat" reasons, but I never got around to it (shame).

Right, but I think it's fatalistic to just write off any attempt to come up with better solutions: nothing will change if we don't at least start thinking about, proposing and testing other ideas.

I think it's a reasonable assumption that most people here are devs or interested in software/programming/etc. Marketers aren't going to be the ones who are actually interested in making better products, they're practically premature-optimisation-in-user-hostile-directions personified, so someone else has to at least propose these ideas.

You are making a mistake in participating in Google garbage as a user. You are an item for sale.

FWIW it's already possible to build apps inside email. There are now full ecommerce stores that run inside gmail messages.

Please give some examples. This sounds horrible, but therefore also true.

At the Inbox Awesome conference this year there was a talk on this, not sure if it’s online.

And you couldn't have invested the time to write a second or third sentence summarizing it?

They run stores in the vendor's email, or the customer's email? bug difference

Real improvements would be ones that allow me to engage less.

Related reading: Against an increasingly user-hostile Web, https://www.neustadt.fr/essays/against-a-user-hostile-web/

>It all comes down a simple but very dangerous shift: the major websites of today's web are not built for the visitor, but as means of using her. Our visitor has become a data point, a customer profile, a potential lead -- a proverbial fly in the spider's web. In the guise of user-centered design, we're building an increasingly user-hostile web.

In this case page load times are being valued over everything (not just AMP but also the search rankings algorithm).

I'm not 100% sure if it's a vanity metric for Google or not.

...Google does have some of the greatest statistical minds in the world, just maybe not the best product/UX minds.

KPI's can be highly misleading when it's disconnected from raw UX. It's difficult to measure user emotional experience, especially when you have a monopoly on user attention with Google Search and total product lock-in with Gmail. When users don't have alternative options analytics stats can be deceiving.

And just because a user completes X task a hundred milliseconds faster it doesn't necessarily mean the UX was better. And just because the UX was made incrementally worse doesn't mean I'm going to use Google/Gmail any less. But enough of small cuts can build up into a serious wound.

I remember reading that article and thinking that the author either isn't old enough to remember the 90s web or has memory loss about how hostile it was to the user.

Ubiquitous banner ads, "free" 56k if you use our browser and click links, cookie bonanza, link hijacking etc... have been part of the web since day one.

> Ubiquitous banner ads, "free" 56k if you use our browser and click links, cookie bonanza, link hijacking etc... have been part of the web since day one.

No they haven't. I definitely remember the web before those were common, and it was great.

And while yes, the web was hostile back then, we also thought about it as hostile. There's been a definite shift in how the web is presented. Back then, we taught "Don't put anything personal online, it's all shady." But now, we want users to give us everything they can, and we've changed the language to allow it. "It's OK for you to give this data to us. We're Google/Facebook/Twitter/etc. There's no way we'd be irresponsible with that data"

It's not like we've come up with some new, super-secure way to store that data. The web is even more shady nowadays, but we're training users not to think about it that way.

  AMP is, to begin with, Google exerting its market power to extend its control over others’ content. Facebook is doing it, so Google has to.
As a consumer, I actually love AMP. Everytime I click a news link on mobile and am taken to AMP, I'm relieved to be free from the extremely distracting original websites.

Google has done a lot of exciting work on open standards like JSON-LD [0] and Microdata [1] to bring a better experience to both Google search results and Gmail. I love clicking the inline "Confirm subscription" button [2] instead of opening emails from Mailchimp and searching for a link. I'm not that scared of the future becoming locked into Google. I believe they'll improve upon and create better standards for emails. Most things aren't entirely altruistic, and that's OK. Gmail being an early adopter to these standards is a good enough reason for them.

[0]: https://developers.google.com/gmail/markup/reference/formats...

[1]: https://developers.google.com/gmail/markup/reference/formats...

[2]: https://developers.google.com/gmail/markup/reference/one-cli...

We have the exact opposite opinion then. I moved to DuckDuckGo on iOS because I thought the AMP formatted Google search results were so user-hostile.

Maybe they’ve fixed the bizarre scrolling and overly sensitive links by now, but I see no reason to find out, because I don’t feel like I’m missing anything.

Honestly if AMP is such a nice format, how hard can it be to just format the content in plain HTML+CSS and let the browser do the scrolling and UI bits?

Only if that doesn't work pleasantly, then you get to complain about the browser not doing its job properly. (this remark aimed at some other replies in this subthread)

It's probably not hard at all, it's just that Google's priorities are currently at "fuck you" especially if you try to avoid being tracked.

There are still UX problems on Android too. I tend to open links in a new window and then close the one I'm looking at when I'm done with it. This experience is totally broken with Amp pages in mobile Chrome. Uhg.

When AMP was announced, I was excited about it specifically for my phone - it's where I care most about loading speeds.

These days, I actively avoid AMP links on Android. It's such a hideously buggy, functionality-disabling system on my phone that it's not worth loading those pages at any speed.

For what it's worth, I only use my phone seriously when I'm out and about, and a lot of times, my internet connection isn't the best, e.g. while in metro

This is true for me too, but I still find that using AMP pages on Android is basically nonfunctional. They load fast, but scrolling is shoddy and every single linking function (back button, hyperlink, and new tab alike) is a mess.

If I want to load a single page with dense content, view it without scrolling much, and close the tab, AMP makes my mobile experience better. If I want to do anything else, AMP on Android starts to interfere with basic functionality.

Which is a pretty sad story for a Google CDN on a Google browser on a Google OS.

I know the scrolling issues we're bugs in webkit. Google (I believe) started to employ a webkit dev to fix the problems.

No, not really. Most UX issues with AMP on Safari rather stem from the approach Google has taken with the html. For instance, it’s not a WebKit bug that tapping the top of the screen on an AMP page does not scroll to top - something that works on virtually all other webpages.

The tapping top of screen hasn't been fixed, as it likely is hard to do.

As for other work on scrolling:

Person contracted to fix some webkit issues: http://frederic-wang.fr/amp-and-igalia-working-together-to-i...

HN discussion made some news about scrolling changes made due to AMP's bug reports: https://www.macrumors.com/2017/05/22/scrolling-changes-comin...

AMP scrolling is still broken. I don’t see why it needs to touch the scroll behavior at all. Plain html is both fast and scrolls naturally. It doesn’t break mobile safari. I don’t get why Google needed to render AMP on such a way that they need to try hard to emulate native scroll behavior (still getting it wrong, previously it was too fast and now it’s a smidge too slow) instead of just using the native behavior.

>The tapping top of screen hasn't been fixed, as it likely is hard to do.

Plain HTML+CSS is hard to do?

Google has gone to an exceptional effort to make things not work like they do by default. That it's even more effort to now get basic UX back shows just how misguided the entire team is.

I’ve heard that before. It’s still fair to blame Google for the whole fiasco. Especially since the non-AMP versions had always worked fine.

Why not blame Apple for building a buggy browser that you have no choice but to use? Stop buying buggy user-hostile phones. AMP pages work perfectly fine in Firefox for Android.

Let’s say you’re an engineer about to roll out a feature to (literally) a billion users. Through testing, you know your feature is busted for the ~14.5% of your users who use Safari. But it’s not your fault! Apple should fix it.

Quick quiz: do you release a feature that is broken for 145M users, which brokenness they might plausibly encounter multiple times a day?

In a typical organization, the answer would probably be an unambiguous “no”.

Without passing judgment, I find the fact that Google decided to ship anyway to be a useful indicator of their beliefs, culture, and priorities.

You could turn that around and ask why Apple didn't bother to fix something that was causing pain for some of their users and continued not to fix it after it was causing pain for most of their users. Google made a bad engineering decision, but I would place most of the blame on Apple.

It's the same for IE and web applications that didn't work in that browser. Luckily, people (for the most part) stopped using IE. We can only hope that iOS Safari will share that fate.

It doesn’t feel equivalent to me; I tend to think that there’s a meaningful distinction between a bug known before shipping and a bug discovered after.

That said, it’s fair to ask why Apple hasn’t placed priority on the scrolling bug, post-AMP. What the real dynamics are I can only guess; I’d love to hear from lurking AMP or WebKit engineers.

The three main issues are that scrolling behavior was busted, clicking on the top bar doesn't scroll to the top like it does in all other scroll views in the system, and the URL bar doesn't show the 'real site' so links shared via the built-in mechanism are links to google, not to the actual site content.

All three of these are Google not taking into account mobile browser design. None of these can really be classified as issues in Safari, rather they are consequences of the Safari design and the design choices Google made.

The first two are due to the content being embedded within an iframe.

The scrolling issue was partly because Safari implemented custom scroll behavior (supposedly due to a Steve Jobs request) for its main web view, but scrollable iframes did not override the scrolling behavior. The fix here (I believe it was rolled out in iOS 11) was to change system-wide behavior for Safari to use the system default scrolling behavior, so that everything behaved the same.

The title bar issue is due to the content not being a scroll view, but a view the size of the screen containing one or more scroll views (the iframes). Which of these should be scrolled to the top on a tap? Changing this behavior could change it for deployed sites, so rolling out any sort of new heuristic requires testing and probably wouldn't be done outside a new major version (e.g. iOS 12).

The third issue is across all browsers - Google is the one serving the content, not the third party that wrote the content. Because of this, any attempt to change where the browser 'thinks' a page is being served to another domain runs afoul of pretty fundamental web security principles. You might be able to design some sort of call (similar to CORS) to ask if google is representing your content in order to get permission to forge the address, but that would be a new web standard that hasn't been written yet.

Google should have just not used a scrolling iframe. MobileSafari has this beautiful quirk that iframes greater than 8 pixels tall automatically expand to the size of their content, solving all of the awkward coordination problems of sizing the iframe. It would have been just so damned simple for Google to fix this in MobileSafari :/.

The AMP viewer and the AMP cache page are served from different domains. Leaking the size of the cache page to the viewer page would be a security bug, which is worse than the scrolling bug that Apple actually had.

That's certainly an interesting quirk, I've never heard of it, nor seen it in another browser.

Definitely useful, though, why isn't that a feature in HTML5?

> I’d love to hear from lurking AMP or WebKit engineers.

A WebKit engineer explained the scrolling bug and how they fixed it here: https://news.ycombinator.com/item?id=14386292

> That said, it’s fair to ask why Apple hasn’t placed priority on the scrolling bug, post-AMP

Because Apple is incapable of fixing a browser bug without an OS update. You should be asking why Apple won't let you use a non-buggy browser on your phone to begin with.

I’m not going to switch my browser or my hardware platform over some trivial bug that only surfaces on one website. I’m just not going to visit that website.

It doesn't matter how you "feel", I know for a matter of fact, objectively and measurably, that my load times have gotten significantly faster, and that AMP has achieved what thousands of sites have failed to do.

So feel free to call it names and bring up feelings, but what I care about is the actual objective experience I'm getting.

That's being a bit obtuse. Of course it matters how it feels, however you look at it! Such as if a loading bar makes something feel better as it loads - then good!

That's not quite what I was talking about. I was responding specifically to:

> I see no reason to find out, because I don’t feel like I’m missing anything.

The person was basically saying "I don't feel like checking how good AMP is, I'm just going to blindly dismiss it"

While I agree with your opinion that AMP is fast, perceived performance is certainly a thing. Read into it :-)

As a consumer I like the speed of AMP but hate the usability of it (ever try sharing a link? ugh).

As a developer and a content creator? I absolutely hate it. Not only is my content hosted outside of my control but they give them a visual weighting in Google search results. So now, if I want my content to have the best chance to be seen, I have to use AMP.

I wish they would have just made AMP a framework or build system that out spit out optimized web pages. Instead they force us to use their CDN which also has multiple trust issues.

I don’t like how usual ios controls stop to work with amp, e.g. scroll to top by tapping on time; back button works[-ed] wrongly. Also there is annoying amp bar at the top that pops up constantly when I scroll. They can’t distinguish between swipe-and-stop and swipe-and-letitscroll in browser, so it doesn’t work as safari header bar.

Better they completely faked dns/cert in some wat and presented me copied content from their amp cache. I don’t check sources anyway.

Everybody had a computer that could run any program, but used only their web browser, so they made the web browser pretend to be any program, but then everybody had a web browser that could run any program, but used only webmail, so they made webmail pretend to be any program? Where does that end?

Or are these ”engaging, interactive, and actionable email experiences.” more limited than the current web applications? If so, what are their limitations?

Also, I guess all clicks in those experiences will go through Google’s servers.

> Also, I guess all clicks in those experiences will go through Google’s servers.

And therein lies the motivation. Why would all these Gmail users want to be clicking on web apps that aren't hosted on and monetized by Google, when they could be doing all these things inside Gmail?

At Google, we feel email security is a top priority. That is why the new AMP-enabled GMail runs on a Go interpreter, in a walled Java-based virtual machine, inside Chrome, installed the OS of your choice.

Meaning no Chrome, no AMP based emails? Sounds good to me!

> Also, I guess all clicks in those experiences will go through Google’s servers.

That's the main thing I mind.

Really, the UI of webmail clients suck. The point of computing is automatization; there's shit ton of things that could be better integrated with each other in search, e-mail, calendaring, etc. But for that to be good, you'd have to own that integration. When a third party owns it, you become slave to that third party.

> ”engaging, interactive, and actionable email experiences.”

'Click here to download Thunderbird' is what my mind inserts after reading that.

It's inner-platform effects all the way down!

> Also, I guess all clicks in those experiences will go through Google’s servers.

They already do, when I click a link in my GMail (Android) app, and it opens in Firefox (Android), I can sometimes quickly see a Google redirection URL flit by before loading the actual page. They basically did a similar shitty trick to what they did to the Search result pages, pretending to be direct links but inserting a tracking redirect at the onbeforeunclick event or such.

Hey, btw anyone know of a nice Firefox Add-on or something that rewrites/stops the Google Search result links from redirecting at the last moment? I've been meaning to code up something like that myself, but I bet it already exists (and I'm mostly using DDG these days any way).

Another thread here summarized it quite well. All these expensive engineers need to do something. If it ends that would mean most of the employees have no purpose anymore.

Because they didn't internalize the feedback from Wave well enough I guess. /s

I agree with the article, email is email. But it points out something which is fundamentally a problem for the industry. Some software is done as in doesn't need to change any more.

That is a scary place since all those Gmail engineers need to do something so if it isn't adding new things to Gmail what will they do?

Interesting parallel in open source, Linux especially, when you have a subsystem that works well and is well understood by lots of people. Nothing to fix right? Well that would be boring. So we get things like systemd replacing the init subsystem and we get the unholy love child of netware and windows 'net' command replacing networking infrastructure management. Did they need changing? No, the previous systems did just fine. But what else is there to do?

That's exactly what I thought about new Youtube web interface. It's slow to load and consumes more CPU. Previous design worked great everywhere. There was no need for the UI change.

But, people can't just do nothing and get paid. So, they will create the need. And now spend months to make it, fix it, get busy again.

Yes! This "over-engineering" is happening all over Google products. Chrome is another example. It is not all bad, however, some Google Apps really needed attention, like the new Calendar is a step up (IMO).

> This "over-engineering" is happening all over Google products

This is absolutely a thing at Google IMHO. Remember the last major version of Google Maps, ran silky smooth on low end hardware, searches went where you expected, in and out no problem.

Then someone decided to try for glory and improve on perfection by re-engineering the entire thing. Now it sets the fans off in my macbook within a few seconds of appearing and they run for the duration, searches zoom out and show results 5 miles away on the other side of the major city I live in when I just want to see restaurants or coffee shops near me, constant back and forth jank from result lists to items.

Went from an app that was a complete joy to use to something I dread to interact with.

The Google Maps app isn't even "capable" of remembering your recent search queries if you don't allow Google to track your Location History.

Says enough about their priorities, IMHO.

I remember one of the earliest software features that was widespread and called "intelligent" was basically the fact that a search form would remember your previous queries and present them incrementally as you were typing your new search.

That a company that prides itself on its AI efforts simply refuses to do this, again, says enough about their priorities.

The interface might be perfect but if it doesn't change users will eventually think it's "too old", some users like you and me will happily use the "too old" interface because it's fast and works well, but the normal people want something "fresh". Design is like fashion, some design patters stay, but the look is constantly changing.

While you're not wrong about trends in design / UI design, if you think about it for a moment, your argument is no more than a mere footnote (if any) in Google's reasons for pushing AMP to email.

It's mostly about tracking and a form of "embrace, extend, extinguish". We're at the last end of the second phase now. Make no mistake, Google has followed through on the "extinguish" part enough in the past. See: Google Reader, and what they did to Usenet and the Deja archives.

Which is why, in a way, consultancy is a better place to be.

90% of the industry isn't directly about software, rather other products that are helped by having some software around, and when it is done, it is done. Time to move along to other customer.

I don't consider email to be "done". It's pretty much my least favorite tool.

The underlying protocols (SMTP and IMAP) are decent, but the clients aren't. It still lacks usable end-to-end encryption found in many modern messaging protocols/apps. Outright spam is mostly solved, but marketing and other notification emails I accidentally or intentionally signed up for consume way too much mental bandwidth, even with supposedly intelligent email clients (at least the ones I've tried)

That said, AMP for email doesn't solve any of those problems either.

IMAP without NOTIFY which no major provider implements is terrible.

I have to disagree on the topic of systemd.

A lot of what it does definitely needed changing — although systemd implements that change suboptimally.

Take the logind concept:

In the past, Linux screensavers were simply a fullscreen window in front of everything else. They crashed? Your system unlocked.

With logind, you have one tiny separate daemon that spawns your original X session, and the screensaver. As long as the screensaver is active, that screensaver replaces the X sessions's display.

If the screensaver crashes, it gets restarted, or, if that fails, you get in a lovely TTY font "open a tty, login as your user, and type loginctl session-unlock".

And this is secure. If something fails, your session won't accidentally unlock.

Other features include an IPC protocol that allows per-message security — user A can send messsage type 1, but user B can only send message type 2 (although, did that verification language have to be JS? T_T)

This thread here is obviously the wrong place to roll out the systemd discussion again.

That's a good point, it's just sad to see people directly dismiss it.

Systemd is a lot of good intentions and ideas, turned into bad code.

AMP is one good idea (faster loading speeds) turned into not just bad code, but also lock-in and proprietary anticompetitive services.

There's no black, or white, only Greys on Greys.

Real happy with the "fold subthread" buttons on HN :)

(if only they would auto-fold after a fixed number of children, like Reddit, I might script that for myself one day)

> If the screensaver crashes, it gets restarted, or, if that fails, you get in a lovely TTY font "open a tty, login as your user, and type loginctl session-unlock".

This is really offtopic, but you seem to confuse KDE with systemd. There is a bit of KDE that tells you to use loginctl to tell KDE's display manager to unlock the session if KDE's screensaver doesn't work properly.

Sure, KDE implements that bit, but the important part is that logind makes it possible to implement that bit in the first place.

Before logind, the alternative was custom handling and detection of screensavers in your session, or simply it crashing back to the session.

I find both your comments confusing.

In your first comment you said that screensavers were just normal windows and would crash back to an unlocked screen - that never happened. Here you're conflating KDE (started ~1997) needing logind (started in what 2010?) which it didn't. Even your comment about a 'session' makes no sense since at the X runlevel X itself is the 'session'.

In my opinion a lot of the problem has been a lack of clarity of what the actual user benefit will be, and the crazy borg-like scope expanion. I'm going to avoid commenting on the implementation of logind and brethren.

I'm not conflating anything — lockscreens on X11 were always just normal windows. If they crash, they unlock.

I suggest you read JWZ's On Toolkits page: (archive link due to referer shenanigans): http://archive.is/BjMfp

Yes you are. The trick that KDE uses is that the screen locking is done by the KDE session manager, and because that is the main process in the X session if it crashes the session terminates so it's not possible to bypass the screen locker that way. None of that requires systemd; it makes use of something that's been true under X11 pretty much forever. The only thing that changed with logind is that instead of trying to restart the password prompt if it crashes, KDE now pops up a message asking you to drop to a console and use logind to disable the screen locker. (Annoyingly, it does this even on systems that don't use logind, in which case the instructions don't actually work.)

I was aware that KDE handled it that way, but as far as I know to handle it properly like this across X11, Wayland, and other sessions, logind is pretty much required.

Gräßlin wrote a bit about that in his blog.

But you might be right, I’ve not worked on either of these projects, so my knowledge is mostly from hearsay.

That’s just bad design to begin with, replaced by a ln inefficient kitchen sink of a solution. Why should the screensaver be part of this megalith?

Edit: to be clear, it’s not about the binary used to run the screensaver, it’s about the fact that it does not need to be a question of “all or nothing” and that a solution for this particular problem could have been adopted without replacing virtually every other component of the system services simultaneously.

As I wrote in the comment you replied to, the screensaver is NOT part of the init system, nor is logind part of the init system.

logind is developed by systemd, but a separate binary. In fact, every systemd project is a separate binary, just developed by the same project. Systemd is as much a monolith as KDE is.

Second, this tiny little logind binary is separate from the screensaver. It does not contain the screensaver, nor the lock screen, nor does it link to them.

This tiny process spawns the session and screensaver, and simply switches between them based on a signal. It's the tiniest possible concept for handling this task.

In general, I'd prefer if you could be more specific about your criticism, e.g. how this separate tiny binary is a "kitchen sink" and the screensaver, which is entirely separate from logind and systemd, is "part of a megalith".

Presumably, it is part of a “megalith” because now my screensaver depends on some crazy login manager, which depends on a crazy authenticated ipc scheme that loginctl uses, and probably none of this works if I replace systemd with something else, so it all depends on running some busted dns client with a recent history of remote exploits.

So, instead of wrapping my screensaver in a small program that manages respawns on crash, you’ve arranged to force me to either have the screensaver unlock itself (since you ripped out the old simple wrapper), or have remotely exploitable network holes.

[edit: source: https://www.jwz.org/xscreensaver/versus-xlock.html ]

Also, due to systemd, the some of the ioctls you need for rootless X are needlessly declared “root only”, so to call them, you have to launder the call through some authentication daemon that has its own (not Unix) security model, and runs as root.

Finnally, I run this mess on a machine that is also an NFS client, and it frequently times out mid login / resume session, so you need to login like three times on a bad day because nfs takes a few seconds to stat something.

It was even worse with systemd aware desktop environments. There, instead of timing out quickly, it would sometimes hang for minutes, with per-user copies of what appeared to he the whole systemd stack running, and no logs anywhere.

To what DevOps platform is this a reference to? "and we get the unholy love child of netware and windows 'net' command replacing networking infrastructure management"

Poor frogs. The water temp just got upped a couple of degrees. Too late to jump out or not just yet?

Some relief for frogs that make it out of the pot:





I’m a fairly happy fastmail user, and have been intrigued by ProtonMail. Has anyone made a switch between them or run both for an extended period of time?

I do like he idea of encrypted-at-rest, and the desktop bridge seems like a decent solution for syncing locally, but not having search on mobile seems like it would be a major drawback for my use cases.

An app I have always wished for is something that would store an offline indexed archive of my email on mobile, protected by passphrase and independent of any provider.

As an aside, what’s the deal with Redbox? I’d never heard of them and $650/a for 25GB makes it seem like their pricing matrix hasn’t been updated since the 90s. The stock photography doesn’t help with that impression.

ProtonMail is quite nice. Just try it out. I would suggest you always keep it open in a tab and save your password in a password manager, otherwise you may "forget" to log to that email and may not use it often. Also make sure you set-up getting your emails into ProtonMail from day one.

"Also make sure you set-up getting your emails into ProtonMail from day one"

could you explain this a bit more? ive been routing my gmail to protonmail since i started using it but im slowly changing accounts from using gmail to protonmail as i go

Happy FastMail customer over here.

Fastmail is great. I'm going on nearly 10 years of service I think.

15 years here. It just works.

I'll hop on this train. 7 happy years for me!

Lol. Leave it to somebody on HN to reduce a problematic corporate decision to a play on existential dread.

Does not allow custom domains.

Also, https://mail.zoho.com.

They have a 5GB free-tier if you've got a custom domain. I've been a customer for years and very happy overall.

Seconded. I've used them for years to and i currently have paid accounts. I administer accounts for others to and i find the interface more intuitive than gsuite.

Happy user of mailinabox here. Switched to it after openmailbox.org decided to kill their userbase by bringing out some completely unfunctional "new" UI along with three days of unscheduled downtime, which still doesn't work months on.

Barely no maintenance and I can add a prefix to all of my email addresses to easily blacklist anywhere that sells my email or unsubscribe links don't work for.

Seconded. Glad to see this here. They have their foibles (current webmail interface is very old school, filters are a little limited etc) but I'm a paying customer for several years now (asking side zoho's mail offering) and am happy.

Frogs will jump out of slowly-heating pots. Unless they're lobotomized in a certain specific way, which was the experiment that created the popular myth.

I was curious what sort of lobotomy was employed:

> In 1869, while doing experiments searching for the location of the soul, German physiologist Friedrich Goltz demonstrated that a frog that has had its brain removed will remain in slowly heated water, but an intact frog attempted to escape the water when it reached 25 °C.[1][5]

Ah, the whole brain then.

Only on HN...

I also point this out whenever someone mentions the frog analogy on reddit. So, also on reddit.

In Poland, right-wingers / conservatives use "lemmings" as a derogatory term for political opponents and basically anyone who doesn't agree with them. It isn't because they're fans of the game from 90's. There was a Disney animal "documentary" which had a scene with lemmings jumping off a cliff. The thing is, lemmings don't do that (don't suicide). In the movie, they were pushed for dramatic effect.

Moral of the story: conservatives in Poland live in their own delusions.

Redneck Mythbusters: put the term in search engine. Youtube works well most of the time. If you can't find multiple videos or photos showing it happening, it's probably not real. If all you can find is reports like "a bloke told me", it's probably not real.

If you're not at work, try it with "fluffer". Some stories are too good to be true.

Maybe you should try to contribute to the discussion instead of trying to derail it with trivia? Especially if that's something you do repeatedly.

Maybe you should have selected a better analogy instead of a flawed one?

> “For example, imagine you could complete tasks directly in email.”

Pretty much the only task I ever want to complete from inside an email is “Unsubscribe”.

I wish clients would make it easier. Gmail does has an unsubscribe button for some emails. It would be cool if it recognized emails I consistently ignore and prompt me to unsubscribe from them.

The Inbox App for Android does this.

Thank goodness that a bunch of clever kids are going to replace boring old SMTP n MTAs n MUAs and stuff with this bollocks: https://www.ampproject.org/ 8)

email works and doesn't need fixing. It (nearly) transports more messages every day than is countable and just works. SNR - now that needs fixing and a good start would be enforcing plain text.

It's OK though, they replaced email and SMTP with Google Wave back in '09 or so, right?

Email “works” but it’s ass for consistently displaying anything more than text.

Marketers want to make money, and right now stuffing emails with images in favor of proper layout is the only easy way to do it.

Of course google also wants all of your email googling its way through their servers.

As a marketer my fear is Google sees what FB is doing to monetize the feed format and it is moving to turn email into the next algorithmically controlled feed it can turn into a dynamic auction.

There is already a Gmail placement for AdWords ok the GDN. However for the most part, if I as a marketer send emails to my customers, I can be more or less certain they will get delivered if my deliverability is high.

What I see Google doing here is gradually exerting control until they tell brands "hey, you know those messages you used to send to customers for basically free? Now you need to pay a dynamic price we control in order to get any "organic" reach."

And just like that they will have turned one of the most valuable, scalable and cost effective marketing channels into another large revenue stream for themselves that gives them even more leverage over marketers.

Kinds of genius when you think about it.

> algorithmically controlled feed it can turn into a dynamic auction.

That's already happened with GMail, hasn't it? The filters for Promotion, Social, and of course Spam already control what/where users see (and it'd be trivial for Google to charge a fee here based off visibility of Promotion-categorized messages).

It's still in a linear and usually legible way, of course, and I think it's arguably user-friendly if imperfect. Doing what facebook does with feed/status updates with email would be absolutely ludicrous, it would make GMail a ghost town overnight.

It has started with the tabs, you are right.

I don't think introducing ads into the feed is as ludicrous as you say from a business standpoint. If done properly, I could see Google avoiding a mass exodus while simultaneously opening up more inventory for them. In some ways, I see Inbox as a test towards this vision.

My broader concern is a fundamental shift in the ownership of a customer/user relationship and the cost of reaching them. In today's world, you pay a fixed price for your ESP, and then some CPM rate for volume typically. Your costs are known, often negligible, and entirely under your control. Likewise, as long as you follow best email practices and nurture healthy relationships with those on your email lists, you have an expectation that your email will land in their inbox if they want to receive it.

That is similar to what FB had back in the day when someone Liked your brand page. If you posted, they would see it assuming they scrolled through their feed enough.

My fear is that Google will change that dynamic such that you cannot be guarantee to reach your audience (even if you have great deliverability) without entering into an auction and paying a constantly changing price that presumably will always increase as they maintain control as the new gatekeeper of that customer communication.

"Email “works” but it’s ass for consistently displaying anything more than text."

That is by design. Email is not an image viewer nor is it an HTML browser. It is a plain text medium.

The "active email" demo on the original article is a great example. I want to ensure that my primary inbox is a place where others can never ever send something like that.

It's an exaggerated version of the image-heavy email newsletters - these are obviously nice for the marketer, but the messages that I want to receive are not like that, they don't need this feature, it's only useful for those who want to steal my attention.

If marketers really need it, perhaps it could be a useful way to automatically forward any messages using this technology to spam.

Oh now that's an idea!

Somehow I expect that GMail's search box will get a "usesAMP:yes" or "content:AMP" filter or something. It has a lot of filter keywords like this[0], undoubtedly they'll add it.

You can easily add a filter rule to automatically mark all messages matching a filter as "spam".

If enough people do that, they might get the message. (and probably just remove the search filter option, sigh)

[0] come to think of it, GMail's search is a delight exactly because almost still kind of works like how Google Web Search used to work back when it was still good, a mere decade ago ...

> Email “works” but it’s ass for consistently displaying anything more than text.

That's a feature, not a bug.

Seems over-engineered. Why not the following simple setup -

- user receives email with a link (text or image) that points to some AMP page

- user clicks on the link

Gmail: - renders the AMP page in-place, replacing email content

Non-gmail clients: - keep whatever "link click" behavior they currently have

This does not render interactive content in email automatically and requires a click, but that click is important because it

- signals the user's desire to interact with the content

- follows current email security expectations, e.g. does not load third party content (other than images) just by viewing the email

Indeed. I can definitely see a reason one might want a dynamic experience in an email. I'd love to interact with some notifications without leaving my inbox. But that'd be select apps I want to work with, not something my email client should assume I want. Every marketing email I get shouldn't be an interactive page by any means.

I direct a lot of things to email like social notifications just so everything comes to one place. I end up doing a lot of bounces off to various sites to "respond" with a Like, +1, Retweet, etc.

But like, an interactive email should be a whitelisted opt-in behavior. "Hey, I want my Twitter notifs to be interactive so I can reply and retweet without leaving my email, so let me enable the Twitter app in my email client."

This was exactly what occurred to me. I haven't read the spec, but I presume they want to display AMP content pre-click.

As you pointed out, that violates user's expectations about what security vulnerabilities they are initiating when they open an email. Indeed, even lay users may sense that it just feels "wrong" for an email to act dynamically without anything being clicked.

Good luck! I had the "pleasure" of working on HTML emails a few months back. It was unbelievably painful. Getting even a simple email to display consistently across a dozen different mail clients is a huge pain. This is why so many marketing emails use giant images for everything--it's the simples way to get consistent rendering.

I predict whatever Google launches will work in GMail, and GMail only.

Most of the pain of HTML email is Microsoft’s fault, because they have persisted in using the MSO (Word) HTML render/editor in Outlook and Windows Mail, and it’s worse than IE 5.0. (Outlook 2003 switched to the IE renderer, and everyone rejoiced; then the Outlook 2007 went back to the MSO renderer for rather crummy reasons and all web people boggled and despaired.)

Sure, other clients have their inconsistencies, but they’re nowhere near as bad as MSO, and they actually get fixed over time. Microsoft, on the other hand, persist in using a rather buggy engine from twenty years ago, unchanged (I don’t know that there haven’t been any functional changes or bug fixes since then, but if there have been they’re minor or obscure).

I'm fairly certain that Lotus Notes is deserving of at least as much scorn for its mail rendering as Outlook.

Considering I did ISP tech support, including mail client setup, for a few years in the late 90's and early 2000's and never once encountered Lotus Notes, I think it may be like in kind, but nowhere near like in quantity.

Notes was an interesting product until people started using it for email.

Notes is/was typically used in corporate setups. I'm not sure any non-business user would have ended up trying to use it.

I would have thought the same of Microsoft Outlook (not Outlook Express), but those calls were fairly common. Perhaps Microsoft Office was just more commonly encountered outside a corporate environment.

Outlook has always been fairly accessible to the home user, through home use programs or various versions of Office. It even comes with home editions these days.

Lucky you, I see it every single day.

I had to do client work once that required Lotus Notes support and I swear that program runs HTML through a blender before trying to render it. It makes Outlook look like Chromium.

Notes doesn't do HTML at all, at least not in the client. (The webmail client, running in the browser, does use HTML.) It uses a rich text format, and has to translate HTML to the nearest Notes rich text equivalent.

Sometimes I think e-mail should have just stayed plain text. No HTML renderers or other fancy stuff. Just type what you want to say and to whom and send. You know what does fancy marketing "e-mails" really well without all the horrid HTML hackery? It is RSS (or Atom).

If HTML e-mail hadn't been invented then the need would have been fulfilled by something else, particularly for corporate environments where formatting and marking-up e-mails is essential to communication.

For a while in the late 90s / early 2000s we had RTF e-mail.

attachment: winmail.dat

Markdown support would be nice, though. GitHub flavored.

On top of that, it will only work well in Gmail on Chrome. Gmail on Firefox is already kind of a shitty experience, it will only get worse.

Marketing emails use giant images to push the text content below the fold, because they want to entice the user to enable images. Images need to be enabled to track opens.

I further predict it will work in GMail and Inbox differently from each other. Which is just mind boggling. Why!?

Embrace, Extend, Extinguish -- then walled garden.

There's a recurring theme in the discussion of this (and actually any time there is a discussion about email), that self-hosting email is really hard. That hasn't been my experience. I've been self-hosting four mail accounts (with moderate to high usage) on one server since about 2007. I briefly tried gmail when it came out but never switched to it.

In 11 years of self-hosting my mail I've had one deliverability problem, which was when outlook.com users stopped receiving our mail. I wrote to outlook.com, and it was resolved within 24 hours. This is possibly because my server is located in a reputable, but relatively small, datacentre, and not on the likes of AWS.

I use the zen.spamhaus.org DNS blacklist to reject connections from spammers outright, and do SPF checks. These two methods alone (no Bayesian or similar filtering) mean I get about one spam message per two days on average, which I just delete.

I estimate that I spend about half an hour a month on keeping the server up-to-date etc.

I consider the downsides extremely small in comparison to the benefits of controlling your own email setup. I encourage anyone with even basic server administration skills to try it. Email is a fantastically decentralised system and we should take advantage of that.

Yep. When you setup your server with a project such as sovereign you get great, secure defaults and day-to-day maintenance is minimal. Mostly keeping debian packages updated and upgrading the distribution every couple of years.

Until gmail/outlook/yahoo start silently blocking a percentage of your emails for some obscure reason. It’s really hard to get self hosted email right - it is very user hostile.

For everyone who feels AMP makes the web usable: A few points for thought.

Web is quite usable with or without AMP as long as you use some ad blockers.

As far as I understand, on Android, Google predominantly shows AMP pages on Chrome and not on Firefox (have not used other browsers to comment on. Will be great if someone chimes in on this).

This results in a good user experience for users of Chrome on Android.

But Android Chrome was made unusable by Google in the first place by not allowing extensions. So NoScript, AdBlockPlus, Ublock Origin etc will not work. So all the junk loads and you have an awful experience.

AMP comes in and saves the day :)

On Android Firefox, no such drama. I can just install Ublock Origin and have a great browsing experience what ever the site it is. Reader Mode is a bonus. (Though I have rarely used it).

What does it all say?

Oh wow, I've been using Firefox Android (with uBlock) since ages. I never considered that. But yeah whenever some app renders a page in some embedded widget (probably Chrome) it's just .. .blegh.

So that is what AMP is for? No wonder I've never seen the use.

Honestly can't think of a time I wished one of my emails had more interactivity.

What exactly would "more interactivity" even mean in this context? Running Javascript inside an eMail? What could possibly go wrong with that?

The author has really limited understanding of the enterprise world I believe.

Email doesn't belong to a company? Nice one. It belongs to Google and Microsoft.

And this kind of change signifies three things immediately:

1. Being terrible means it's likely to happen and not really stoppable. They've already thought about how many people won't like it and still decided to go for it.

2. They try for a long time to have this more interactive messaging experience. Thinking Google Wave and Google Plus here. They have not understood that Slack/Wechat have solved that in a much more elegant way already. So they try again and again. This one will also fail to produce the vision they have. Google simply doesn't get that Web 3.0 interactivity. For us it's okay, it just means at some points other companies will take Google's place, and it will become that old, annoying giant like IBM and Microsoft before them.

3. Touching Email in this way also means that they are becoming desparate. Maybe not about profit yet, but certainly about the visionary aspects of the company. Email is one of their core components. You don't F* with those unless you really feel desperate.

It is not at all about users. It's about survival. Therefore the arguments presented in the article aren't even close to being good. A good article would figure out why they are so desparate and suggest things that they could do in favor of their users that still will increase their survivability.

Buying Slack and integrating it with their office suite might just solve their problem. It will be super expensive but might bring them onto the next level. Just a quick, stupid suggestion as example for what the article should've been about.

With the expansion of AMP, it's crazy to think of Google more likely to undermine the health of the internet than the ISPs in a post net neutrality world.

As a user AMP has never once improved my experience. This topic comes up on HN from time to time but I still don’t see any value in the AMP model as a user. If it went away my experience would improve. Adding this misguided direction to gmail will only reduce utility from a user perspective.

I don't know the technical details of what Google is planning, but if they build something that eases the pain of building cross platform HTML emails, that's a welcome innovation in my opinion. Building emails that "work" even just okay is a ridiculously hard task. Every company I've been at has made some attempt with mediocre results at best (oh, you're using _Outlook_?).

I'm not holding my breath for something good to come out of this, though. This could just as easily be a terribly executed product. But I'll try to be an optimist, because what we have now is outright trash.

"but if they build something that eases the pain of building cross platform HTML emails"

On the other hand, if HTML is excluded then the message gets through without scope for mischief.

HTML emails are here to stay, and the billions of dollars that companies pour into designing, building, and sending them are proof of that. Given the constraint that we're stuck writing and consuming them, I'd rather have a technology that does a good job than a technology that makes me want to boil my laptop.

If you're afraid of HTML, by all means please check your email from a sandboxed VM in the terminal. But some poor chump is still going to be toiling away to make the latest Pottery Barn newsletter look great on a Blackberry, so we'd might as well build better tools.

Seriously. Would be great if somebody could just declare a new mime-type such as "text/html5" that could be used to activate modern html rendering in email clients and would be shipped alongside the existing "text/html" and "text/plain" components. Eventually when enough email clients support this, we could stop generating the legacy html emails and only include text/html5 and text/plain mime types in emails.

Devil's advocate: there's more to keeping email safe than just not allowing JavaScript. Most browsers let you have up to 255 drop shadows on a single element, which can really heat up your laptop. CSS animations can also cause havoc. Imagine loading a GIF from a server that just streams frames forever. You also don't want to immediately load images (for privacy reasons), and you probably also want to ban audio and video while you're at it. In a web email client, you don't want the styles of the email to affect the chrome of the app. <iframe>, <object>, and <embed> lead to a world of bad ideas. <base> and <dialog> could potentially cause unusual issues. I can't think of anything off the top of my head, but I'm sure data URIs could be abused somehow (data URI-encoded SVGs something something loading content dynamically?).

CSS can cause problems, too. @import could cause privacy issues, as could @font-face. If images are not pre-downloaded, @media and @page could reveal when you print a message and @supports could leak details about your mail client. `position: fixed` would need to be banned outright I'd think, if the message isn't sandboxed in an iframe.

HTML5 as a whole is designed for building applications, not for making pretty messages. You want to have a subset of HTML5, but not too strict of a subset. Some APIs (e.g., @font-face) probably can't be used as-is and need a replacement. And of course, it all needs to be somehow backwards-compatible.

If one is reading mail, a good quality MUA will not be "loading a GIF from a server" in the first place. The content to show should be all right there in the message to start with, included using multipart/, or it does not get shown.

* http://jdebp.eu./Proposals/gnksoa-mua.html#NoAutoFetchExtern...

How to get promoted at Google:

1. Build a product everybody hates and shove it down their throats.

2. Find an existing product people love and fuck it up or kill it.

How not to get promoted at Google (or anywhere else):

1. Build a product people hate and quietly let it die.

2. Do absolutely nothing to an existing product that works well that people love.

Ugh. Hopefully unlike the serp results, nobody feels like they have to cave in here due to the carrot/stick Google wields in search.

If they do wield a similar influence because of the market share of Gmail, hopefully somebody challenges that under antitrust or some other consumer protection basis. Email doesn't need walled gardens. That's back to the AOL days. "You've got AMP mail!"

Didn't Outlook Express have this option about a decade ago? yeah it was with ActiveX plug-ins and Flash. Microsoft removed it because it was giving advertisers and the wrong kind of hackers tracking information and access to user's machines. Those were nasty security bugs.

While I don't see the security issue at a machine level being an issue since this will be done through canvas. I do see an issue with privacy. Its still JavaScript powering that fancy display. Which means JavaScript can write and read cookies and session values. JS can possibly do other bad things on your machine.

I wish my email would just stay email. Let the social networks do the fancy stuff. That's what they're for. Google could always go back a retool Google Plus. Let publishers do AMP mini-sites there.

>What Google wants to do is bridge that moat, essentially to allow applications to run inside emails, limited ones to be sure, but by definition the kind of thing that belongs on the other side of the moat.

How is this bad?

I do not understand the hate?

If you do not like the product then move on.

I can see this working well on a mobile devices, not sure how it will work on other platforms, but I'm definitely open to giving it a shot.

The best part about this is if I don't like it I can always switch.

The problem is that in this scenario someone else (i.e. the sender) is choosing the product/application they want to run on my device in my app. Unlike a web page, where I (hopefully) intend to use it and "pull" the app, this is designing a system where arbitrary apps and interfaces can be pushed to me by others, often not with my best interests in mind.

I don't want my email client to be part of such a system. If I want to follow the advice of "if you do not like the product then move on", then it's not sufficient for me to simply not use this feature in messages I send, this requires that messages I receive don't/can't use this feature.

> I do not understand the hate?

Oh, the hate is just the new version of the ASCII ribbon against HTML email...

Besides the ideological issues, is the HTML tag for AMP emails seriously going to be <html 4email> (html lightning-emoji4email)?

I wish they implemented this as a separate MIME type so emails could specify multi-part messages with text/plain, text/html and a text/amp (just for gmail).

it is a separate mime type

You're right - it looks like it's available as the text-x-amphtml MIME part. I missed that on the initial read-through.

A few months ago I set out to move to fastmail and then got lazy and didn't follow through. This is the kick in the butt I needed.

AMP is terrible for the Web too.

There are a number of threads here which seem to have been downvoted because of the perceived quality of the ideas they contain. However, I always thought that downvoting was meant to be reserved for low quality discussion, rather than disagreement. Has this changed, or was I always wrong?

People always have and always will downvoted for disagreement, whether they're supposed to or not.

Google is on a mission to own every corner of everything related to the Internet. Email sucks, but I'll keep my boring old email in lieu of Google shoving more targeted advertising in my face, thank you very much.

While I don't like the idea of AMP cause, let's face it, it's change, it really is the next step of evolution for email. Email stopped being this sacred thing when you could create an HTML email.

i think that AMP is a way to make up for the fact that Chrome will be blocking ads tomorrow. Google has to do something to give publishers a way to reach people and make money otherwise publishers will begin to start charging Google in some way or take their business else where.

When you open an email, a publisher has your direct attention and being able to interact with you in a two way direction is HUGE.

Personal communications are gone from email. They now happen in Whatsapp. Gradually some one-on-one business communications are also moving to Whatsapp. If Whatsapp ever figures out business communications at large, email is practically dead. Excluding viagra spam, this means that nearly 99% of legit communications that are today received in personal email accounts are automated emails (transactional or bulk email). No wonder why Google wants to reinvent email into some kind of personal engaging spot before it completely dies for personal use.

Living in the US I literally know 0 people who use or have ever used Whatsapp. That's not a judgement on their app, just a reality that in this country it's not something people use.

US is definitely the exception. I've visited South/Central America, Europe and at home in the UK and WhatsApp penetration is extremely high.

Not only US, barely anyone uses whatsapp in russia, for example.

Whatsapp usage varies wildly depending on region. A fragmented walled garden ecosystem populated by other apps like Messenger, Line, Kakao Talk, WeChat, etc will not kill email.

"A fragmented walled garden ecosystem" has also been a fair description of Internet electronic mail for quite a while, however. It was Balkanized years ago.

> AMP is, to begin with, Google exerting its market power to extend its control over others’ content. Facebook is doing it, so Google has to

The last thing Google needs to do these days is copy Facebook. Almost everything Facebook has done in the past few years has pushed users away from the platform.

Also, if Google's goal with AMP really was to "make the web faster" how exactly will integrating AMP web pages into email make email faster? Seems to me like it would make email slower...? (at least if we discount marketing spam).

And here I thought there was no way to make HTML email worse. Guess I was wrong.

I can't believe I read through this article and most all of the comments here with no mention of what the hell AMP actually is, so I did a bit of Googling so that someone somewhere won't have to.

Accelerated Mobile Pages (AMP) ( https://en.wikipedia.org/wiki/Accelerated_Mobile_Pages ): They are a competing technology with Facebook's Instant Articles that restricts the page from doing practically anything that isn't performance-minded up-front. That means very little loading, and all data calls are async. That means no document.write or other blocking calls that would prevent the page from loading. As culled from the wiki article and the amp project site, pages in AMP load in a second or less and consume very little data, making them optimal for mobile devices.

You left out the very important detail that practically speaking, your content also needs to be hosted on Google's CDN if you want to get any of the benefits that content creators are likely to care about (being boosted in SERPs).

I don't know how I missed that, I must have skimmed around that point, yes that is very important. Looking through the wiki page I found it quite easily, but it doesn't stick out as much on the ampproject official page.

Hosting on Google’s CDN is not a requirement. There are third party AMP-caches, for example Cloudflare runs one.

It would help if the anti-AMP hysteria stays to the facts.

Wow...pages that do less crap. We've really come a long ways from our webcrawler, Netscape roots...such progress. And to be clear, not pointing fingers, I'm honestly just astounded that a glorified, fundamentally unchanged monkey patched version of what we started with is where we are at...

This article just reminded me how much I miss Google Reader... still to this day can’t figure out why they canned it.

Can anyone explain what this would look like? Just an HTML email but with parts of it hosted on AMP’s CDN? Or the whole email is hosted on AMP, and non-AMP email clients just have a link (and cannot view their email without clicking on a link, and leaking the fact they viewed the email?)

Would it be possible to make a filter in FastMail that automatically deletes these emails? I can imagine spammers would love to send “You need an AMP client to view this email, click here”. Plus the point about privacy above.

Edit: I’d want it to send a reply, as I can imagine anyone with a Gmail account might be blocked from sending me an email. Possibly any companies on the AMP bandwagon.

This might be the push I need to get round to writing an IMAP gateway that strips HTML and only serves text/plain to my email client. I don’t need more HTML and tracking bullshit in my emails.

Almost certainly possible to make a regex matching filter to discard or file such emails into a folder :)

>See, email belongs to a special class. Nobody really likes it

Well, I like email. It does exactly what I need it to do. It doesn't have the pressures of chat or phone calls, and has the versatility to do all kinds of useful things. Best of all, it can't be broken by a single company and a stupid decision.

Did you continue reading after that sentence?

I also like forks, but I'm usually not telling people how great forks are. That's what the article says.

*AMP is a terrible idea

"Were people complaining that clicking “yes” on an RSVP email took them to the invitation site? Were they asking to have a video chat window open inside the email with the link? No. No one cares."

I don't want this new feature and am glad I moved away from gmail, but I think the author is mistaken if they think people don't want this. Some people don't want to leave their gmail app to click one box on a now slowly loading web page full of content/ads they don't care about. I procrastinate on some mail because I don't immediately feel like dealing with the context switch. Then the mail gets buried by others and I forget. I'm ok with that mode of operation and I can also see a lot of people not being ok with and being delighted by AMP in gmail.

When I read a phrase like:

>> allowing “engaging, interactive, and actionable email experiences.”

I immediately think advertisements.

The problem we have here, is that a VERY large percentage of 'normal' users, use gmail. As such, whatever Google do to 'enhance' the gmail experience, then the other email providers feel they have catch up by adding the same functionality.

If AMP ends up being natively supported inside your gmail inbox, then Microsoft will have no choice to support it also, lest people jump ship from Outlook.com to gmail. Once Microsoft add AMP support to Outlook.com, then they'll turn their attention to the Outlook client, and enable AMP there too.

Once that happens, AMP-Email will be a standard, and there will be no stopping it.

For me, if that happens, I'll be turning back on the 'plain text email only' option in my mail client.

I am currently a big fan of Google Inbox. I am loosing my fandom spirit more and more.

> I'll be turning back on the 'plain text email only' option > in my mail client.

I am with you on that. I would even go one step further. I would enable this option to only show pure text content. And to autorespond to emails without pure text with a message:

"In the spirit of the web. And in the spirit of AMP power emails (Google telling you, that these are faster) I only accept pure text emails. These are the fastest ones to send, deliver and consume.

Please, in the future refrain from sending me bloated code. And if you feel the need to include images - use the age old attachment function."

Is this only for gmail customers, or is Google sticking AMP links in outgoing emails?

That's legally risky for Google. They're not protected by an EULA if their outgoing email has hostile code and hits a non-Google customer.

Amp is a terrible idea.

Is this truly as terrible as the comments section here is acting like it is? More engaging email sounds somewhat interesting to me. Should it stay as stale as it is now? Maybe a few improvements for email development. A few standards here and there, maybe the ability to make use of css properly for once. I wouldn't mind some better looking emails that didn't require a bunch of images loading to be view-able or some improvements made to how emails are developed for those that do. Not that AMP solves that, but I'm happy to see the discussion on improving emails coming to light.

People who are unable to create a product and get someone to pay for it, take an existing product, reduce its utility and charge for the rest. Its like the airline baggage policy. This is stereotypical-MBA thinking.

In my job, I get a lot of automated emails from Github, our bug tracking system, our wiki system...

(Sometimes the idiots start replying to the automated emails!)

I really wish there was a better way to bridge that gap. I usually turn on conversation view (we use Outlook), to group all of the emails via ticket, pull request, ect. But, what I really want is my email client to just tell me what changed, and use an anchor hyperlink to take me there in the ticket, pull request, ect.

I think it's worth experimenting with viewing these tickets inside of an email client, but I'm not sure if I'd like that or not.

I like AMP. Brave browser seems to block most of the ads by default, and I get the speed benefits for free.

I really dislike ads or using my CPU cycles to mine bitcoins for unrelated entities (cough cough Salon).

Am I stealing the information these entities provide for free on open Internet connections? Maybe. I don't really care though. I also benefit similarly by gut bacteria processing my food, and also don't want them taking their "fair" share of my life by ending up in places they don't belong. This particular analogy is, of course, open for expansion.

> The moat is the one between communications and applications. Communications say things, and applications interact with things. There are crossover areas, but something like email is designed and overwhelmingly used to say things, while websites and apps are overwhelmingly designed and used to interact with things.

I agree with the distinction, but I believe that websites & email belong on the same side of the moat. Websites are meant to say things and applications are meant to interact with things.

I'm not actually against AMP being put in emails, but adding unnecessary functionality to emails under the banner of "AMP for email" definitely seems like a step too far.

I've left Gmail for Tutanota a long time ago. I prefer having a niche service that focuses on privacy and is committed to open source. They'll even release the app on F-Droid soon, couldn't be more psyched: https://tutanota.com/blog/posts/secure-mail-open-source

Why Tutanota? Which were the services you compared?

I didn't compare much, but to me Tutanota is exactly the opposite to Gmail and that's what I love. It's ad-free, no tracking, no scanning of data. Once it has the app on F-Droid it's the only email service (to my knowledge) that enables you to use it without any attachment to Google.

Hey man, email existed before google :) You can use whichever email service you want that's not google and use an open source email client like K-9 Mail or AOSP's Email client :)

Only non-standard emails won't work with POP3 or IMAP protocols. In those cases you need to use their specific program/protocols, yes. It seems Tutanota falls in this category, as does ProtonMail.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact