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

31–40 of 95 posts

Re: Standardizing lessons learned from AMP

#31

Post by Ajedi32 »

ocdtrekkie wrote: post #8
dmitriid wrote: post #6

A lot if big words disguised as good intentions. There’s nothing fast, instant, or open about AMP. The latest article debunking those myths: https://ferdychristant.com/amp-the-missing-controversy-3b424... Google’s fully opaque process around AMP for email (yes, it’s a thing): https://github.com/ampproject/amphtml/issues/13597 and https://github.com/ampproject/amphtml/issues/13600

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.

Re: Standardizing lessons learned from AMP

#32

Post by Ajedi32 »

justinph wrote: post #15

Lots of talk and no code or proposals, in so far as I can tell. The thing that makes the web slow isn't web standards, but too many ads and too much tracking code. If only there were a company that controlled a lot of the ads and tracking code on the web...

> no code or proposals

What are you talking about? They linked like half a dozen concrete proposals in the post itself! Even provided a dashboard so you can easily track all of them: https://github.com/ampproject/amphtml/blob/master/contributi...

Re: Standardizing lessons learned from AMP

#33

Post by tyingq »

Ajedi32 wrote: post #30
tyingq wrote: post #26

Earlier quoted context omitted.

The reddit AMP pages you land on from Google searches are particularly irritating. You aren’t logged in when you go to them, and various UI expectations are broken. Web packaging could help here since it would remove the google url, allowing cookies/sessions to function again.

Web Packaging (at least on its own) wouldn't help with that, since the whole point of that standard is to allow content to be prefetched from a CDN (like AMP pages currently are), and CDNs can't cache content that's user-specific. What _would_ work is serving the main content immediately, then using JS to fetch user-specific stuff after the page load.

Right, which you can’t do now, but could do after the main page url is yours again.

Re: Standardizing lessons learned from AMP

#34

Post by dfabulich »

wmf wrote: post #28
dfabulich wrote: post #24

I wrote a blog post about these proposals a couple of weeks ago and a nice HN thread formed around it. https://news.ycombinator.com/item?id=16424445 But as I said in my post, the problem with posts like today's AMP blog post is that they're too full of jargon to be comprehensible to a general audience. The Web Packaging standard is really cool, but today's blog post just linked out to a ton of web standards without d…

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' privacy.

But here's the point: most people think that Google wants to host nytimes articles on google.com, to seize control of the web's traffic. They don't. They've done a bunch of work to get out of that business while preserving the performance benefits of prerendering, but nobody knows that, because they talk about it in bizarre technical jargon like today's OP AMP blog post.

Re: Standardizing lessons learned from AMP

#35

Post by Ajedi32 »

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?

Re: Standardizing lessons learned from AMP

#36

Post by ocdtrekkie »

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.

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.

Re: Standardizing lessons learned from AMP

#37

Post by xab9 »

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.

Re: Standardizing lessons learned from AMP

#38

Post by username223 »

reaperducer wrote: post #7
falcolas wrote: post #3

From the point of view of a user concerned with Google's influence, this seems like a good move. From the point of view of a SRE who would have to help configure a server side implementation of web packaging, having yet another http request/response type to build and maintain seems like a bloody nightmare. And OCSP with the signature when Chrome themselves have disabled its use? It also requires custom behavior from…

> And OCSP with the signature when Chrome themselves have disabled its use? It's not the first (or probably last) time that Big G's said "Do as we say, not as we do." Heck, the blog post is hosted on WordPress instead of Google's own Blogger.

> Heck, the blog post is hosted on WordPress instead of Google's own Blogger.

That made me chuckle, and gave me a sense of how much they value this PR chum. Please, guys; at least make a semi-convincing attempt to pretend you think we're not morons. Hosting a blog post on your own domain would cost you almost nothing. You could even load it up with your own ads to recoup the cost.

Re: Standardizing lessons learned from AMP

#39

Post by xab9 »

I wish one day marketing, print designers and useless business architects would just step back and let me build a damn page.

No trackers, no spying, no fancy multilayered parallax video scrollers, no animated video carousels, no fucking ads, no taboola shit, no related clickbait articles, no tag cloud sidebar, no ooh-so-shiny bleeding edge web frameworks that has a lifecycle of a single year (megabytes of minified angular), no isomorphic shit, just a plain site with the relevant information and minimal styling.

Re: Standardizing lessons learned from AMP

#40

Post by pathseeker »

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.

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.
Post reply on HN