Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Standardizing lessons learned from AMP

amphtml.wordpress.com

Post reply on HN
Print view View original

41–50 of 95 posts

Re: Standardizing lessons learned from AMP

#41

Post by ocdtrekkie »

pathseeker wrote: post #40
Ajedi32 wrote: post #31

Earlier quoted context omitted.

> AMP is not a "well-lit" project. How so? As the blog post points out, the whole thing is open-source with almost all discussion surrounding the project happening out in the open on their GitHub repo. You might not agree with the direction the project is going, but I'd say it's about as well-lit as any open source project can be.

Posting some discussions in the open doesn't make it well-lit. There are many projects following this path where the real decisions are made in private meetings by people in the controlling companies. Open washing is not open source.

Indeed, while discussing AMP4Email, it seemed that, despite being a proposal in the AMP Project, all decisions for it's implementation were already made (and committed to) by the Gmail team, it had already been "reviewed" by a security team (although any such security protections are limited to Gmail's own internal protections, other implementers are on their own), and there seemed to be no opportunity for the greater email community to comment before these things were decided.

Having it up on GitHub after that doesn't really mean much. This is the same for Android and Chrome, of course.

Re: Standardizing lessons learned from AMP

#42

Post by x0x0 »

dfabulich wrote: post #34
wmf wrote: post #28

Earlier quoted context omitted.

telling AMP's story, humbly and honestly What would that look like? "We have a gun to your head"? There are some very uncomfortable truths here about Google's near-monopoly on Web traffic.

If you want the details, I did write a blog post about this. https://redfin.engineering/how-to-fix-googles-amp-without-sl... tl;dr: iframes cause all of AMP's problems, but they provide unbeatable performance, thanks to prerendering. Prerendering is faster than http://motherfuckingwebsite.com . The Web Packaging standard will allow Google to prerender sites in search results without AMP, and without violating users'…

Why should we trust a monopolist that -- and this is totes a coincidence! -- is pushing a standard that breaks all urls to point to them? This is the next attempt after google plus or whatever their stupid social network is/was. They're basically terrified of facebook and, instead of supporting the internet, they're trying to become fb. But in your browser.

Pretending google didn't want to steal all urls requires actively ignoring the last 10 years of google's corporate decisions.

Re: Standardizing lessons learned from AMP

#43

Post by dfabulich »

x0x0 wrote: post #42
dfabulich wrote: post #34

Earlier quoted context omitted.

If you want the details, I did write a blog post about this. https://redfin.engineering/how-to-fix-googles-amp-without-sl... tl;dr: iframes cause all of AMP's problems, but they provide unbeatable performance, thanks to prerendering. Prerendering is faster than http://motherfuckingwebsite.com . The Web Packaging standard will allow Google to prerender sites in search results without AMP, and without violating users'…

Why should we trust a monopolist that -- and this is totes a coincidence! -- is pushing a standard that breaks all urls to point to them? This is the next attempt after google plus or whatever their stupid social network is/was. They're basically terrified of facebook and, instead of supporting the internet, they're trying to become fb. But in your browser. Pretending google didn't want to steal all urls requires act…

I'm not telling you to trust them. I'm certainly not telling you to use AMP.

I'm just saying, they've done a lot of work on this Web Packaging thing, and it's a pretty good replacement for AMP. You should check it out.

It's hard to see why they'd do all of that work of replacing AMP if your theory is right and they just loooved stealing those URLs.

Re: Standardizing lessons learned from AMP

#44

Post by lern_too_spel »

ocdtrekkie wrote: post #36
Ajedi32 wrote: post #31

Earlier quoted context omitted.

> AMP is not a "well-lit" project. How so? As the blog post points out, the whole thing is open-source with almost all discussion surrounding the project happening out in the open on their GitHub repo. You might not agree with the direction the project is going, but I'd say it's about as well-lit as any open source project can be.

It seems like that until you start asking questions. Then you discover that AMP4Email is controlled by Gmail team, that you can't get a straight answer to save your life, and when they don't like the topic, they subtly threaten the Code of Conduct when no violations are occurring to indicate they are actively searching for an excuse to close down discussion.

AMP4Email has nothing to do with AMP as a validatable preloadable subset of HTML and the web packaging standard discussed in this article.

Re: Standardizing lessons learned from AMP

#45

Post by Ajedi32 »

xab9 wrote: post #37
Ajedi32 wrote: post #35

So, this is pretty much everything the HN crowd was asking for, right? Pull AMP apart into a bunch of web standards and switch Google search to promote any content which follows those standards rather than AMP content specifically? Why are all the top comments so negative?

Probably because AMP should not have existed in the first place :) We already have everything we need to make fast and performant pages - we can't do it, because of marketing and trackers and spying and shit though: not technological factors, but human factors.

And yet, AMP has succeeded at getting publishers to deliver fast and performant pages where other efforts did not.

I dispute the idea that technological factors are not at play here. AMP's preloading and automatic CDN caching system have a pretty big impact on load times, and its technically-enforced restrictions on what sort of performance-impacting content publishers are allowed to include in their pages seems to do a pretty good job of ensuring pages do not become bloated.

Re: Standardizing lessons learned from AMP

#46

Post by x0x0 »

dfabulich wrote: post #43
x0x0 wrote: post #42

Earlier quoted context omitted.

Why should we trust a monopolist that -- and this is totes a coincidence! -- is pushing a standard that breaks all urls to point to them? This is the next attempt after google plus or whatever their stupid social network is/was. They're basically terrified of facebook and, instead of supporting the internet, they're trying to become fb. But in your browser. Pretending google didn't want to steal all urls requires act…

I'm not telling you to trust them. I'm certainly not telling you to use AMP. I'm just saying, they've done a lot of work on this Web Packaging thing, and it's a pretty good replacement for AMP. You should check it out. It's hard to see why they'd do all of that work of replacing AMP if your theory is right and they just loooved stealing those URLs.

Because

1 - they got caught with their hands in the cookie jar

2 - the internet isn't quite as dumb as google hoped

3 - thank god for the EU & Margrethe Vestager. Maybe we can talk her into adding a zero.

ps -- that status, as near as I can tell, of the amp url fix is vaporware. Deployed yet? Nope. So let's wait to get all triumphant until their supposed solution is deployed. https://www.androidpolice.com/2018/01/09/google-finally-fixi...

Re: Standardizing lessons learned from AMP

#47

Post by username223 »

Ajedi32 wrote: post #31
ocdtrekkie wrote: post #8

Earlier quoted context omitted.

The fact that Malte is still trying to call the AMP project "well-lit" is really what throws a lot of question on this blog post. AMP is not a "well-lit" project. Why not hand AMP itself over to standards groups as well as all of the other things mentioned here? What about the proprietary GMail implementation of AMP4Email? Or the fact that none of the justifications for AMP given in this (or The Verge interview[0]) h…

> AMP is not a "well-lit" project. How so? As the blog post points out, the whole thing is open-source with almost all discussion surrounding the project happening out in the open on their GitHub repo. You might not agree with the direction the project is going, but I'd say it's about as well-lit as any open source project can be.

> ... open-source with almost all discussion surrounding the project happening out in the open on their GitHub repo.

Yeah, well... "Open-source" in the sense that they throw something over the wall from time to time. "Almost all discussion" in the sense that they use a heavily-moderated public newsgroup for some things. It's better than completely internal development, I guess, but don't kid yourself: it's a PR exercise coupled to a near-complete capture of the RFC process.

Re: Standardizing lessons learned from AMP

#49

Post by ocdtrekkie »

Ajedi32 wrote: post #45
xab9 wrote: post #37

Earlier quoted context omitted.

Probably because AMP should not have existed in the first place :) We already have everything we need to make fast and performant pages - we can't do it, because of marketing and trackers and spying and shit though: not technological factors, but human factors.

And yet, AMP has succeeded at getting publishers to deliver fast and performant pages where other efforts did not. I dispute the idea that technological factors are not at play here. AMP's preloading and automatic CDN caching system have a pretty big impact on load times, and its technically-enforced restrictions on what sort of performance-impacting content publishers are allowed to include in their pages seems to d…

The fact that Google Search is a monopoly is not a technological factor. Google gives preference to AMP sites on Google Search, therefore publishers must implement AMP.

I actually have a lot less issue with AMP as a technological solution, as I do with the Google's "our way or the highway" treatment of the Internet. Google uses both it's search monopoly and it's browser monopoly (and often, both at the same time) to force the entire world to do whatever Google wants them to.

Sometimes you might perceive the result to be "good", but that doesn't justify the behavior. That's why another technical implementation change blog doesn't improve anyone's mood about the whole thing: Because Malte Ubl is still pretending he's on #teamweb and not #teamgoogle.

Re: Standardizing lessons learned from AMP

#50

Post by mattigames »

jashkenas wrote: post #16

Just for kicks, folks, let's collect all of the adjectives, adverbs and qualifiers used in this post to describe ~AMP: * a leading format * consistently excellent * invest strongly in ... * well-lit * user-first * instant-loading * tightly-integrated * highly-optimized * great * well-lit * great * well documented * easily deployable * validatable * opinionated about user-first principles * fast development * constant…

Text editors should have a feature to warn about a high number of qualifies/adverbs: "you are using to many qualifiers and adverbs, you may look biased to your readers, it may be a good idea to remove or rethink some of them."
Post reply on HN