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

71–80 of 95 posts

Re: Standardizing lessons learned from AMP

#71

Post by tyingq »

Ajedi32 wrote: post #63
tyingq wrote: post #51

Earlier quoted context omitted.

“Why are all the top comments so negative?” Google could still be planning to keep the top banner, the left/right swipe to your competitor functionally for carousels, etc. That top banner, for example, has an [x] button that end users expect to dismiss the banner and stay on the page. Instead, it goes back to Google. The negativity is because they aren’t being explicit as to what is actually being delivered. They are…

In that case I'd suggest that perhaps they just aren't understanding exactly what's being announced here. Eliminating the top banner was something AMP announced they were going to do _months_ ago, just as soon as they could do so without negatively impacting performance: https://amphtml.wordpress.com/2018/01/09/improving-urls-for-... And AMP having "the right to run their own arbitrary JS on YOUR site" is not somethi…

Can you quote something specific that says either the top banner or carousel takeover UI goes away? To me, it seems very high level and opaque. They could have been very specific, but haven’t been.

Web packaging does still require including a named google js url, right? With little restrictions on what it’s able to do with the DOM.

Why, for example, is there no Google source saying that the AMP page header is going away? They have not yet specified if they will only allow a very specific implementation of web packaging that allows your site into the carousel and other top of page search result URLs.

Re: Standardizing lessons learned from AMP

#72

Post by smacktoward »

jashkenas wrote: post #58
smacktoward wrote: post #52

Earlier quoted context omitted.

We need an AMP version of Buzzword Bingo: http://www.businessbuzzwordbingo.com/

Happy to provide, buddy: http://myfreebingocards.com/bingo-card-generator/results/w5z... Bingo!

I applaud your well-lit, user-first attitude!

Re: Standardizing lessons learned from AMP

#73

Post by [deleted] »

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.

[deleted]

Re: Standardizing lessons learned from AMP

#74

Post by beokop »

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.

... and we’re back to optimizing for fast delivery of the page that loads your page.

Re: Standardizing lessons learned from AMP

#75

Post by Kalium »

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.

You're absolutely right. Everything we need, in a strictly technical sense, to make wonderfully fast and performant web pages already exists. And has accomplished little, because as you say it's a human problem.

AMP exists because Google figured out a way to make non-technical humans want to be fast and performant. It's a nice carrot to offer people who normally don't care at all about performance.

Re: Standardizing lessons learned from AMP

#76

Post by xab9 »

beokop wrote: post #61
xab9 wrote: post #39

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 an…

We chose to use PHP for our site redesign after using React, Elm and Jekyll in other projects. It’s really liberating. No spending days setting up a build/deploy process. Gets out of your way unless you actually need it. Everything including the kitchen sink included. Pre-installed on all Macs. Our designer can code and deploy changes by himself. I used to hate PHP. Then I tried the alternatives.

It's not the framework, it's the people (and their whoring greed mixed with dilettantism). I love vue, I'm okay with A5 and react. I usually do node stuff, but php is okay nowdays, symphony is a good thing too.

Re: Standardizing lessons learned from AMP

#77

Post by agentdrtran »

beokop wrote: post #70
Ajedi32 wrote: post #56

Earlier quoted context omitted.

Fair point, but that problem (at least as far as AMP is concerned) is exactly the one this blog post is addressing: Google is planning to stop pushing AMP specifically in its search results and instead push a set of open web standards which achieve the same technical goals.

Even so, I’m tired of jumping through hoops to adhere to bullshit standards that make life hard without any actual benefit. We have HTML and CSS, why do we need AMP? How does my personal webpage benefit from HTTPS? Why did they enforce mandatory HTTPS across the entire .dev TLD in WebKit, breaking my local test env, when it’s only used by a few internal projects at Google? They seem to have a vested interest in makin…

> We have HTML and CSS, why do we need AMP?

Do you even know what AMP is?

Re: Standardizing lessons learned from AMP

#78

Post by patmcguire »

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…

Most of them are silly, some of them are true. It is super integrated, it is fast, and it is opinionated. User-first is debatable, but it's not exactly publisher first and it's definitely not (external) advertiser first. No idea what well-lit means.

I guess the takeaway is that the garden is great, build the walls higher?

Re: Standardizing lessons learned from AMP

#79

Post by vanadium »

drsim wrote: post #48
andrewn32 wrote: post #14

Haven't tried this myself but came across this interesting AMP workaround: https://www.goinflow.com/amp-mobile-pagespeed-score/

No technical detail, just a lead gen page. Am I missing something?

I'm glad I wasn't the only one wondering, "Ok, where's the technique here beyond just adding AMP markup in a conventional page?"

Still not entirely convinced what's supposed to work about this method.

Re: Standardizing lessons learned from AMP

#80

Post by skybrian »

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.

Well, technically, it is. Open source doesn't imply governance by an independent standards body. There are just requirements for what counts as an open source license.

A project run by a "benevolent dictator for life" (like Python or Elm) is entirely compatible with open source. The same is true for a project run by a corporation (like React).

Post reply on HN