7 ms·

This move is aimed to quell the critique based on a hypothetis that contributions to AMP that go against Google's vision would be rejected. It also is a move in

This move is aimed to quell the critique based on a hypothetis that contributions to AMP that go against Google's vision would be rejected. It also is a move in good faith to transition the project's governance away from Google to a goal-oriented crew of many interested parties who can derive benefit from its solutions. I've written about AMP on here a lot [1], and frequently include this disclaimer. My views on it have evolved as time went on, being more sympathetic to some of the critiques, but also to the efforts of the AMP team to address many of the complaints. While a number of technical critiques to AMP remain, increasingly, the criticism is: - ideological (e.g. "Google is trying to destroy the open web"), - misinformed (e.g. "Google is stealing traffic from publishers"), - nihilist (e.g. "everyone who uses AMP only does so because you need it to rank high in search"), - full of naïve bravado (e.g. "all we need is clean HTML"), - or related to the fact that Google's mobile search page has stealth-morphed into a captive newsreader that surfaces AMP-ified articles with Javascript without ever leaving the page. Out of these, the lattermost is the only one that raises a true anticompetitive concern, which Google seems keen on ignoring. However, I'd say that's for the Google Search team, rather than the AMP team, to address. [1] https://hn.algolia.com/?query=niftich%20%22AMP%22&sort=byDate&type=comment https://hn.algolia.com/?query=niftich%20%22AMP%22&sort=byDat...

lucideer 8y ago
Of your 5 bullet points, what's the difference between #2 and #5? You say people believing #2 are misinformed, but that #5 raises a true anticompetitive concern, but they're the same thing, no? As for it being for the Google Search team to address, rather than the AMP team, I'd be inclined to disagree. AMP Cache is a part of the AMP spec., the Google Search team are just implementing it as described. What they're doing is just what the AMP Cache is designed to do, nothing more. Also, while you describe #3 as nihilist,I fear it's the most true among the wider, non-HN implementers of AMP on sites.
- ninkendo 8y ago
  You can definitely care about #5 without caring about #2: Morphing my search results into a captive newsreader gives me a demonstrably terrible experience browsing to sites on my phone. The swipe-back gesture is broken, scrolling doesn't move the safari borders away like it's supposed to, there's a big AMP border I can't get rid of, swiping just moves between results instead of going back (or did they "fix" this?), the URL bar shows google.com instead of the site, making it harder to share, etc etc. I don't care that they're "stealing traffic", I care that my mobile experience is demonstrably worsened.
  - lucideer 8y ago
    That's true, but I was more addressing that #2 and #5 are two different outputs of the same technical mechanism—therefore saying that #2 is misinformed while #5 is valid is a contradiction.
- niftich 8y ago
  The difference between "stealing traffic" and the "Google Search Mobile is a captive newsreader" is nuanced. It's surprising and upsetting to people when they find out that in Google Search Mobile, their attempt to navigate to an AMP-lightning-marked search result doesn't result in a navigation to the target site, while an attempt to navigate to a non-AMP search result does go to the target site, as one would damn well expect. It's upsetting, because the designers of Google Search Mobile have gone through great lengths to hide the fact that the navigation didn't occur, and have adopted UI elements that intentionally try to mimic familiar navigation cues from browsers, rather than playing up the fact that they're viewing proxied content in a wrapping frame. On the other hand, the 'stealing traffic' critique is memetic from a catchy title by a much-revised blog post, and seems to genuinely be upset that bytes that would ordinarily be transferred between the end user and the article's originating host stop short of of the distant origin [1], and get served from a Google-owned CDN instead. It's a technically unsound mishmash of complaints, most probably deriving from the aforementioned behavior of the Google Search Mobile page, but imbued with the subtext that Google is exploiting publishers by providing a CDN. That's absurd. Maybe Google's exploiting publishers with its captive newsreader, but not by providing a CDN. [1] https://www.alexkras.com/google-may-be-stealing-your-mobile-traffic/ https://www.alexkras.com/google-may-be-stealing-your-mobile-...
  - MrStonedOne 8y ago
    Stealing traffic also means stealing information about how many hits a page has if such is recorded via the webserver logs. Honestly third party websites serving a proxy/cdn/transparent cache of a website is something that should require affirmative consent from either side of the party. Something Google is not getting, and as such stealing traffic is an acceptable critique. It also reduces the security of the website by allowing users to get used to it being hosted from a google search page. SEO an imposter website that shows the same fake ui border and phish logins, the user wouldn't notice as it looks absolutely normal. (Something I might make a grey hat attempt at just because it's likely the only way to get google to stop doing it.)
    - niftich 8y ago
      The publisher of the AMP content can configure hooks into their analytics solution [1]. These events can fire during any AMP pageview. Given this, I'm not convinced they'll mourn the lack of httpd logs. The typical practice for CDNs is that only the publisher consents; the CDN assumes responsibility for routing and serving the content (and has the private key for the origin's cert, to masquerade as them), and the requester doesn't get a choice. This isn't whataboutism, just an observation that CDNs are always the choice of the content originator, and never the content requester, who possesses few tools to convincingly tell the two apart. [1] https://www.ampproject.org/docs/analytics/analytics_amp https://www.ampproject.org/docs/analytics/analytics_amp
vorpalhex 8y ago
As a user, I really like AMP. It converts terrible web experiences into non-terrible ones because it forcibly removes the rope for major websites to hang themselves with. As a developer, most of my concerns with AMP are with it being very Google centric and controlled - and the addition of Cloudflare didn't really solve those for me. Seeing AMP move to a TSC however does, and I really hope that it helps AMP become a globally adopted standard instead of a "Google thing".
- chrischen 8y ago
  I hate AMP as a user. It breaks iOS Safari reader mode, and i always have to do extra work to get the actual link to the page. I'm also on LTE, so there's not really any noticeable speed difference on mobile. Initially there were also rendering bugs making 50% of amp clicks result in blank pages for me.
  - vorpalhex 8y ago
    It's not delivery speed that I care about, it's "time to first paint". I want to read the damned news article, not wait for your crappy fonts to load and have to mute your autoplaying video nonsense.
    - chrischen 8y ago
      CSS fonts are still supported by AMP, so it wouldn't get rid of it.
      - vorpalhex 8y ago
        AMP does some things to allow CSS fonts without letting them get out of scope and go insane.
  - baxtr 8y ago
    Exactly the same for me. It starts wir subtle things: Why do they have to override the system scroll speed? Then, as you point out, I’m a heavy user of safaris read mode which is essentially solving for the same problem as AMP. For me, the best thing about amp is the link leading to the non amp version EDIT: I have to apologize for both of my points. The scrolling thing was fixed as somebody pointed out and the reading mode works just fine for most pages I just checked. Have tried to avoid AMP for a long time I guess...
ChrisSD 8y ago
I appreciate that you're sympathetic to concerns, especially the last one. However I don't think it helps to frame other concerns so negatively. And tbh I don't think open governance addresses most people's concerns although it is a move that can be supported on its own merit.
kodablah 8y ago
> being more sympathetic to some of the critiques [...] efforts of the AMP team to address many of the complaints > full of naïve bravado (e.g. "all we need is clean HTML") These statements seem contradictory unless I am missing the "sympathetic" part wrt this critique and I am missing the "effort" part to address this complaint.
- niftich 8y ago
  The suggestion that the advantages that AMP purports to bring can be better realized instead with just lean websites that aren't full of obtrusive Javascript and dynamic ads seems to entirely miss the fact that just-in-time ad auctions, made possible by scripting in the browser, are a critical revenue source for outfits that publish text and (and short video) content on the web at upfront cost. This makes for awful UX, but expecting publishers to forego most types of display ads is simplistic. AMP raises the standards for ad networks and ad formats [1], and has hooks for analytics [2], giving publishers the features they -- well, at least, their marketing and engagement folks -- want, while insulating them from the most desperate attempts of adtech monetization that they'd otherwise feel the pressure to add. Therefore, AMP provides a story for business models [3] -- and fits into Google's vision where they provide solutions to derive revenue from content, either through ads, or through a user payment scheme [4]. [1] https://www.ampproject.org/docs/ads/introduction_ads https://www.ampproject.org/docs/ads/introduction_ads [2] https://www.ampproject.org/docs/analytics/analytics_amp https://www.ampproject.org/docs/analytics/analytics_amp [3] https://news.ycombinator.com/item?id=12273447 https://news.ycombinator.com/item?id=12273447 [4] https://news.ycombinator.com/item?id=18006178 https://news.ycombinator.com/item?id=18006178
  - kodablah 8y ago
    That this can't be done server side speaks volumes about their real goals. From your first link: > The AMP Project's goals are to do what's best for the user by helping to deliver fast web pages. Clearly what they mean is best for revenue THEN users. This deception makes it clear they will not compromise on revenue (such as requiring server-side ads as img elements). Inability to compromise is quite the opposite of being sympathetic towards critiques and putting forth effort to address complaints. Let's meet in the middle for the user's sake...have your ads, lose your client-side JS. But no, and then they wonder why it gets backlash.
user812 8y ago
Tech is always something that can be solved. It doesn't change the fact that AMP is mostly about Google et al. gaining control over the web. - What you call ideological is a mere fact; google is by definition not an open source movement, and it is creating things with the primary purpose of gaining more users into their own gated ecosystem - Google is obviously gaining control about how content is rendered, which makes it possible for google to control the monetarization - If you ever spent some time among SEO and marketing people this is a pretty obvious conclusion, as those people usually run that part of a company - There are very simple solutions available for making websites faster, it just so happened that AMP was a great way for Google to kill two birds with one stone, i.e. making the web faster and more googly at the same time; their incentives are just not so aligned with other parties All in all the entire thing is similar to the attitude of Google with their plan of changing how URLs work. The problem is not that it is in their best interest to control the web, the problem is that Google seems entirely unaware as a company that others want to have a different version of our future, and that it is entirely legitimate to not use Google solutions as a foundation of that future. As a whole company, Google appears to be somehwat autistic to me. "But this is good for everyone" Google says. No it isn't. The way Google is crippling open source is by offering open source on paper, but then controlling the gateways, like forcing smartphone manufacturers to ship their version of Android. So on the leadership level it is also acting deeply hypocritical.
- danShumway 8y ago
  > The problem is not that it is in their best interest to control the web, the problem is that Google seems entirely unaware as a company that others want to have a different version of our future, and that it is entirely legitimate to not use Google solutions as a foundation of that future. This is really well stated. > As a whole company, Google appears to be somehwat autistic to me. And... this isn't. Being proud or strongheaded, or having dysfunctional internal politics is not remotely the same thing as being autistic; let's avoid stigmatizing. ---- I think that Google has a lot of self-confidence, and it bothers them that they need to do this dance with other members of the community. Google makes its own decisions, on its own, and then is surprised when other stakeholders are "difficult" and don't just go along with their vision. "Because obviously we wouldn't be proposing something unless we were sure it was the right decision, so why is everyone running around questioning it?" That's not to say that there aren't good intentions (although it's become painfully obvious that when well-meaning employees clash with upper management on subjects like privacy or advertising, upper management will always win). But those good intentions have to be coupled with an understanding that the web is bigger and more complicated than Google is. Google isn't the web's parent or guardian, it is an equal stakeholder sitting at the table next to other equal stakeholders. It is not a laudable act of charity for Google to listen to those stakeholders or to include them in decision processes. It is expected. No single company is ever going to be diverse enough, or smart enough, or benevolent enough to control the web. Google certainly isn't -- ignoring user-hostile groups within upper management, Google will still only ever be able to solve problems from the perspective of an advertising company. Moving AMP to an open governance model is very positive, but doesn't get rid of my concerns about the technology. It's a very Google move to go off and do a thing despite significant criticism and pushback outside of the company, and then once they've shaped the result according to their own specifications to come back and say, "See, it's a community effort now. Why are you complaining?" The URL stuff you mentioned is a perfect example. This is the Chrome dev team internally deciding that URLs are an "obvious" problem, releasing a browser update that acts on that internal decision, and then responding to critics by saying, "well, we're just trying to start a conversation. Let's talk about it." That is the wrong order to use when messing with how the web works. It's not even necessarily a question of what's specifically wrong with AMP at this point -- it's that if we were collectively trying to solve the problem of page bloat, we could probably do a much better job in general than AMP does. AMP is an advertiser's solution to web bloat retrofitted to address the broader community's criticism. So you get Javascript requirements on each page load, you get URL breakages that have to be solved by future standards, you get prescriptive metrics about what components Google thinks pages need rather than descriptive metrics about what render targets a page should hit. Not necessarily because Google is evil, but because Google isn't the entire web and can't represent all of its needs.
jorgec 8y ago
"nihilist (e.g. "everyone who uses AMP only does so because you need it to rank high in search")," Why nihilist?. We used AMP because to rank higher. Otherwise, Bootstrap does a better job.
deleted 8y ago
[deleted]
lukestevens 8y ago
I don’t know, I’ve been very critical of AMP both in terms of transparency [1] and conflicts of interest [2]. I still find the whole project dispiriting for several reasons: 1. Forking HTML: They’re now forming a defacto standards body on top of the W3C and WHATWG. (HTML is now forked 3 ways, for those keeping score.) We now are supposed to implement either (a) HTML + AMP, or (b) AMP alone (which is what the project has advocated for). Either way, that sucks as a developer and for the web. AMP team talks about AMP both being the future for everything always, and a mere stop gap that will enable better, native web tech. Which is it? It’s a mess. 2. Engineering-is-always-the-answer ideology: Ideologically, I dislike the “What the web needs is more corporate-driven engineering”. The whole reason the project exists is to fend off Facebook and native apps like Apple News. (It’d be better named FoF-HTML.) That’s the corporate side. And the way to do that was to massively overengineer solutions to problems that could have been addressed largely through SEO incentives (treat it as a spam problem) and left things like URLs (!) intact. Instead we’ll be left with years of AMP detritus that’s going to pollute the web for who knows how long. It’s all corporation-driven engineering and no spirit or science. No one is actually studying if these overengineered micro-solutions actually matter. All we need is more engineering! 3. Picking winners: Google used its own market dominance to bless AMP as the web framework of the future. It could have worked on common standards; it could have created other incentives, but it chose not too. Imagine if Microsoft actually succeeded in creating some kind of MS-HTML in the 90s or 00s. Thus there’s no market-driven competition for Google’s over-engineered solutions. 4. The cognitive dissonance inherent in the project: It’s an “open source” project that was born out of Google’s corporate interests. It has a public tech lead, but the actual Google exec above him responsible for the project doesn’t respond to anyone or answer anything. They cherry pick contributor stats to mislead the actual amount of Google-driven involvement. They desperately want it to be this thing of pure intentions for the benefit of the web and have us all singing kumbaya, but fundamentally it’s the product of a corporation acting in its short term competitive interests and using whatever engineering it has as its disposal to achieve those ends. 5. I still hate the UX. Reader mode support has improved but can be hit-or-miss, URLs are still broken and will be for years, and frankly I want to go to the actual web site and use Reader mode if necessary, rather than read the web through Google’s faux news reader. While developers have to maintain multiple versions of their code base (AMP & responsive HTML) things are going to break. And all this for what? Slightly faster page loading and Google Web Reader experience, so Google can stick it to Facebook somehow? Is there any data on people using the web more instead of apps en masse now AMP is a thing? What %? And does that make forking the web worth it? I guess we’ll never know. It’s such a shame. [1] https://github.com/ampproject/amphtml/issues/13597 https://github.com/ampproject/amphtml/issues/13597 [2] https://github.com/ampproject/amphtml/issues/13623 https://github.com/ampproject/amphtml/issues/13623
JoshMnem 8y ago
It isn't misinformed to say that Google is effectively stealing traffic from publishers. Visitors literally do not visit your site when they land on AMP pages from Google Search. If the visitors copy the URL and paste it somewhere, it doesn't point to your site. An AMP CDN visit is not a website visit. There are extra elements added to those AMP CDN pages (back buttons, swipes) that are detrimental to the goals of publishers. AMP is an attempt to hijack the entire WWW and appify it on Google's platform. The speed problem is not due to HTML -- it's due to bloated JavaScript. There doesn't need to be a new HTML-like standard. There are other ways to fix the problems with bloated JavaScript.
- bitpush 8y ago
  This isnt true. You're right in the sense that bits are not transferred from publisher's servers, but AMP page can report metrics as instrumented by the publisher, ads get attributed to the publisher and links back to the publisher. It is a cache, and behaves like a cache. You're confusing this with an illegal upload of a video to a different site. The other site is 'stealing' the traffic, and the original creator is losing $$, ad impressions, attribution, exposure etc. None of that is happening with AMP Cache.
  - JoshMnem 8y ago
    It definitely isn't a web site visit. It is not only a cache -- it has extra junk added to the page (back button, left/right swipes), and isn't even on the same domain. Copied links and referrers don't point back to your site/domain. Publishers do not have a choice.

lucideer 8y ago

Of your 5 bullet points, what's the difference between #2 and #5? You say people believing #2 are misinformed, but that #5 raises a true anticompetitive concern, but they're the same thing, no? As for it being for the Google Search team to address, rather than the AMP team, I'd be inclined to disagree. AMP Cache is a part of the AMP spec., the Google Search team are just implementing it as described. What they're doing is just what the AMP Cache is designed to do, nothing more. Also, while you describe #3 as nihilist,I fear it's the most true among the wider, non-HN implementers of AMP on sites.

ninkendo 8y ago
You can definitely care about #5 without caring about #2: Morphing my search results into a captive newsreader gives me a demonstrably terrible experience browsing to sites on my phone. The swipe-back gesture is broken, scrolling doesn't move the safari borders away like it's supposed to, there's a big AMP border I can't get rid of, swiping just moves between results instead of going back (or did they "fix" this?), the URL bar shows google.com instead of the site, making it harder to share, etc etc. I don't care that they're "stealing traffic", I care that my mobile experience is demonstrably worsened.
- lucideer 8y ago
  That's true, but I was more addressing that #2 and #5 are two different outputs of the same technical mechanism—therefore saying that #2 is misinformed while #5 is valid is a contradiction.
niftich 8y ago
The difference between "stealing traffic" and the "Google Search Mobile is a captive newsreader" is nuanced. It's surprising and upsetting to people when they find out that in Google Search Mobile, their attempt to navigate to an AMP-lightning-marked search result doesn't result in a navigation to the target site, while an attempt to navigate to a non-AMP search result does go to the target site, as one would damn well expect. It's upsetting, because the designers of Google Search Mobile have gone through great lengths to hide the fact that the navigation didn't occur, and have adopted UI elements that intentionally try to mimic familiar navigation cues from browsers, rather than playing up the fact that they're viewing proxied content in a wrapping frame. On the other hand, the 'stealing traffic' critique is memetic from a catchy title by a much-revised blog post, and seems to genuinely be upset that bytes that would ordinarily be transferred between the end user and the article's originating host stop short of of the distant origin [1], and get served from a Google-owned CDN instead. It's a technically unsound mishmash of complaints, most probably deriving from the aforementioned behavior of the Google Search Mobile page, but imbued with the subtext that Google is exploiting publishers by providing a CDN. That's absurd. Maybe Google's exploiting publishers with its captive newsreader, but not by providing a CDN. [1] https://www.alexkras.com/google-may-be-stealing-your-mobile-traffic/ https://www.alexkras.com/google-may-be-stealing-your-mobile-...
- MrStonedOne 8y ago
  Stealing traffic also means stealing information about how many hits a page has if such is recorded via the webserver logs. Honestly third party websites serving a proxy/cdn/transparent cache of a website is something that should require affirmative consent from either side of the party. Something Google is not getting, and as such stealing traffic is an acceptable critique. It also reduces the security of the website by allowing users to get used to it being hosted from a google search page. SEO an imposter website that shows the same fake ui border and phish logins, the user wouldn't notice as it looks absolutely normal. (Something I might make a grey hat attempt at just because it's likely the only way to get google to stop doing it.)
  - niftich 8y ago
    The publisher of the AMP content can configure hooks into their analytics solution [1]. These events can fire during any AMP pageview. Given this, I'm not convinced they'll mourn the lack of httpd logs. The typical practice for CDNs is that only the publisher consents; the CDN assumes responsibility for routing and serving the content (and has the private key for the origin's cert, to masquerade as them), and the requester doesn't get a choice. This isn't whataboutism, just an observation that CDNs are always the choice of the content originator, and never the content requester, who possesses few tools to convincingly tell the two apart. [1] https://www.ampproject.org/docs/analytics/analytics_amp https://www.ampproject.org/docs/analytics/analytics_amp

vorpalhex 8y ago

As a user, I really like AMP. It converts terrible web experiences into non-terrible ones because it forcibly removes the rope for major websites to hang themselves with. As a developer, most of my concerns with AMP are with it being very Google centric and controlled - and the addition of Cloudflare didn't really solve those for me. Seeing AMP move to a TSC however does, and I really hope that it helps AMP become a globally adopted standard instead of a "Google thing".

chrischen 8y ago
I hate AMP as a user. It breaks iOS Safari reader mode, and i always have to do extra work to get the actual link to the page. I'm also on LTE, so there's not really any noticeable speed difference on mobile. Initially there were also rendering bugs making 50% of amp clicks result in blank pages for me.
- vorpalhex 8y ago
  It's not delivery speed that I care about, it's "time to first paint". I want to read the damned news article, not wait for your crappy fonts to load and have to mute your autoplaying video nonsense.
  - chrischen 8y ago
    CSS fonts are still supported by AMP, so it wouldn't get rid of it.
    - vorpalhex 8y ago
      AMP does some things to allow CSS fonts without letting them get out of scope and go insane.
- baxtr 8y ago
  Exactly the same for me. It starts wir subtle things: Why do they have to override the system scroll speed? Then, as you point out, I’m a heavy user of safaris read mode which is essentially solving for the same problem as AMP. For me, the best thing about amp is the link leading to the non amp version EDIT: I have to apologize for both of my points. The scrolling thing was fixed as somebody pointed out and the reading mode works just fine for most pages I just checked. Have tried to avoid AMP for a long time I guess...

ChrisSD 8y ago

I appreciate that you're sympathetic to concerns, especially the last one. However I don't think it helps to frame other concerns so negatively. And tbh I don't think open governance addresses most people's concerns although it is a move that can be supported on its own merit.

kodablah 8y ago

> being more sympathetic to some of the critiques [...] efforts of the AMP team to address many of the complaints > full of naïve bravado (e.g. "all we need is clean HTML") These statements seem contradictory unless I am missing the "sympathetic" part wrt this critique and I am missing the "effort" part to address this complaint.

niftich 8y ago
The suggestion that the advantages that AMP purports to bring can be better realized instead with just lean websites that aren't full of obtrusive Javascript and dynamic ads seems to entirely miss the fact that just-in-time ad auctions, made possible by scripting in the browser, are a critical revenue source for outfits that publish text and (and short video) content on the web at upfront cost. This makes for awful UX, but expecting publishers to forego most types of display ads is simplistic. AMP raises the standards for ad networks and ad formats [1], and has hooks for analytics [2], giving publishers the features they -- well, at least, their marketing and engagement folks -- want, while insulating them from the most desperate attempts of adtech monetization that they'd otherwise feel the pressure to add. Therefore, AMP provides a story for business models [3] -- and fits into Google's vision where they provide solutions to derive revenue from content, either through ads, or through a user payment scheme [4]. [1] https://www.ampproject.org/docs/ads/introduction_ads https://www.ampproject.org/docs/ads/introduction_ads [2] https://www.ampproject.org/docs/analytics/analytics_amp https://www.ampproject.org/docs/analytics/analytics_amp [3] https://news.ycombinator.com/item?id=12273447 https://news.ycombinator.com/item?id=12273447 [4] https://news.ycombinator.com/item?id=18006178 https://news.ycombinator.com/item?id=18006178
- kodablah 8y ago
  That this can't be done server side speaks volumes about their real goals. From your first link: > The AMP Project's goals are to do what's best for the user by helping to deliver fast web pages. Clearly what they mean is best for revenue THEN users. This deception makes it clear they will not compromise on revenue (such as requiring server-side ads as img elements). Inability to compromise is quite the opposite of being sympathetic towards critiques and putting forth effort to address complaints. Let's meet in the middle for the user's sake...have your ads, lose your client-side JS. But no, and then they wonder why it gets backlash.

user812 8y ago

Tech is always something that can be solved. It doesn't change the fact that AMP is mostly about Google et al. gaining control over the web. - What you call ideological is a mere fact; google is by definition not an open source movement, and it is creating things with the primary purpose of gaining more users into their own gated ecosystem - Google is obviously gaining control about how content is rendered, which makes it possible for google to control the monetarization - If you ever spent some time among SEO and marketing people this is a pretty obvious conclusion, as those people usually run that part of a company - There are very simple solutions available for making websites faster, it just so happened that AMP was a great way for Google to kill two birds with one stone, i.e. making the web faster and more googly at the same time; their incentives are just not so aligned with other parties All in all the entire thing is similar to the attitude of Google with their plan of changing how URLs work. The problem is not that it is in their best interest to control the web, the problem is that Google seems entirely unaware as a company that others want to have a different version of our future, and that it is entirely legitimate to not use Google solutions as a foundation of that future. As a whole company, Google appears to be somehwat autistic to me. "But this is good for everyone" Google says. No it isn't. The way Google is crippling open source is by offering open source on paper, but then controlling the gateways, like forcing smartphone manufacturers to ship their version of Android. So on the leadership level it is also acting deeply hypocritical.

danShumway 8y ago
> The problem is not that it is in their best interest to control the web, the problem is that Google seems entirely unaware as a company that others want to have a different version of our future, and that it is entirely legitimate to not use Google solutions as a foundation of that future. This is really well stated. > As a whole company, Google appears to be somehwat autistic to me. And... this isn't. Being proud or strongheaded, or having dysfunctional internal politics is not remotely the same thing as being autistic; let's avoid stigmatizing. ---- I think that Google has a lot of self-confidence, and it bothers them that they need to do this dance with other members of the community. Google makes its own decisions, on its own, and then is surprised when other stakeholders are "difficult" and don't just go along with their vision. "Because obviously we wouldn't be proposing something unless we were sure it was the right decision, so why is everyone running around questioning it?" That's not to say that there aren't good intentions (although it's become painfully obvious that when well-meaning employees clash with upper management on subjects like privacy or advertising, upper management will always win). But those good intentions have to be coupled with an understanding that the web is bigger and more complicated than Google is. Google isn't the web's parent or guardian, it is an equal stakeholder sitting at the table next to other equal stakeholders. It is not a laudable act of charity for Google to listen to those stakeholders or to include them in decision processes. It is expected. No single company is ever going to be diverse enough, or smart enough, or benevolent enough to control the web. Google certainly isn't -- ignoring user-hostile groups within upper management, Google will still only ever be able to solve problems from the perspective of an advertising company. Moving AMP to an open governance model is very positive, but doesn't get rid of my concerns about the technology. It's a very Google move to go off and do a thing despite significant criticism and pushback outside of the company, and then once they've shaped the result according to their own specifications to come back and say, "See, it's a community effort now. Why are you complaining?" The URL stuff you mentioned is a perfect example. This is the Chrome dev team internally deciding that URLs are an "obvious" problem, releasing a browser update that acts on that internal decision, and then responding to critics by saying, "well, we're just trying to start a conversation. Let's talk about it." That is the wrong order to use when messing with how the web works. It's not even necessarily a question of what's specifically wrong with AMP at this point -- it's that if we were collectively trying to solve the problem of page bloat, we could probably do a much better job in general than AMP does. AMP is an advertiser's solution to web bloat retrofitted to address the broader community's criticism. So you get Javascript requirements on each page load, you get URL breakages that have to be solved by future standards, you get prescriptive metrics about what components Google thinks pages need rather than descriptive metrics about what render targets a page should hit. Not necessarily because Google is evil, but because Google isn't the entire web and can't represent all of its needs.

jorgec 8y ago

"nihilist (e.g. "everyone who uses AMP only does so because you need it to rank high in search")," Why nihilist?. We used AMP because to rank higher. Otherwise, Bootstrap does a better job.

deleted 8y ago

[deleted]

lukestevens 8y ago

I don’t know, I’ve been very critical of AMP both in terms of transparency [1] and conflicts of interest [2]. I still find the whole project dispiriting for several reasons: 1. Forking HTML: They’re now forming a defacto standards body on top of the W3C and WHATWG. (HTML is now forked 3 ways, for those keeping score.) We now are supposed to implement either (a) HTML + AMP, or (b) AMP alone (which is what the project has advocated for). Either way, that sucks as a developer and for the web. AMP team talks about AMP both being the future for everything always, and a mere stop gap that will enable better, native web tech. Which is it? It’s a mess. 2. Engineering-is-always-the-answer ideology: Ideologically, I dislike the “What the web needs is more corporate-driven engineering”. The whole reason the project exists is to fend off Facebook and native apps like Apple News. (It’d be better named FoF-HTML.) That’s the corporate side. And the way to do that was to massively overengineer solutions to problems that could have been addressed largely through SEO incentives (treat it as a spam problem) and left things like URLs (!) intact. Instead we’ll be left with years of AMP detritus that’s going to pollute the web for who knows how long. It’s all corporation-driven engineering and no spirit or science. No one is actually studying if these overengineered micro-solutions actually matter. All we need is more engineering! 3. Picking winners: Google used its own market dominance to bless AMP as the web framework of the future. It could have worked on common standards; it could have created other incentives, but it chose not too. Imagine if Microsoft actually succeeded in creating some kind of MS-HTML in the 90s or 00s. Thus there’s no market-driven competition for Google’s over-engineered solutions. 4. The cognitive dissonance inherent in the project: It’s an “open source” project that was born out of Google’s corporate interests. It has a public tech lead, but the actual Google exec above him responsible for the project doesn’t respond to anyone or answer anything. They cherry pick contributor stats to mislead the actual amount of Google-driven involvement. They desperately want it to be this thing of pure intentions for the benefit of the web and have us all singing kumbaya, but fundamentally it’s the product of a corporation acting in its short term competitive interests and using whatever engineering it has as its disposal to achieve those ends. 5. I still hate the UX. Reader mode support has improved but can be hit-or-miss, URLs are still broken and will be for years, and frankly I want to go to the actual web site and use Reader mode if necessary, rather than read the web through Google’s faux news reader. While developers have to maintain multiple versions of their code base (AMP & responsive HTML) things are going to break. And all this for what? Slightly faster page loading and Google Web Reader experience, so Google can stick it to Facebook somehow? Is there any data on people using the web more instead of apps en masse now AMP is a thing? What %? And does that make forking the web worth it? I guess we’ll never know. It’s such a shame. [1] https://github.com/ampproject/amphtml/issues/13597 https://github.com/ampproject/amphtml/issues/13597 [2] https://github.com/ampproject/amphtml/issues/13623 https://github.com/ampproject/amphtml/issues/13623

JoshMnem 8y ago

It isn't misinformed to say that Google is effectively stealing traffic from publishers. Visitors literally do not visit your site when they land on AMP pages from Google Search. If the visitors copy the URL and paste it somewhere, it doesn't point to your site. An AMP CDN visit is not a website visit. There are extra elements added to those AMP CDN pages (back buttons, swipes) that are detrimental to the goals of publishers. AMP is an attempt to hijack the entire WWW and appify it on Google's platform. The speed problem is not due to HTML -- it's due to bloated JavaScript. There doesn't need to be a new HTML-like standard. There are other ways to fix the problems with bloated JavaScript.

bitpush 8y ago
This isnt true. You're right in the sense that bits are not transferred from publisher's servers, but AMP page can report metrics as instrumented by the publisher, ads get attributed to the publisher and links back to the publisher. It is a cache, and behaves like a cache. You're confusing this with an illegal upload of a video to a different site. The other site is 'stealing' the traffic, and the original creator is losing $$, ad impressions, attribution, exposure etc. None of that is happening with AMP Cache.
- JoshMnem 8y ago
  It definitely isn't a web site visit. It is not only a cache -- it has extra junk added to the page (back button, left/right swipes), and isn't even on the same domain. Copied links and referrers don't point back to your site/domain. Publishers do not have a choice.