[HN Gopher] Resigning from the AMP Advisory Committee
       ___________________________________________________________________
        
       Resigning from the AMP Advisory Committee
        
       Author : robin_reala
       Score  : 51 points
       Date   : 2021-08-18 16:05 UTC (6 hours ago)
        
 (HTM) web link (adactio.com)
 (TXT) w3m dump (adactio.com)
        
       | MrStonedOne wrote:
       | I'm gonna re-post the rant I posted last time this came up:
       | 
       | > As a mobile user, I hate it.
       | 
       | > I hate that every fucking google search result on mobile web
       | has its stupid little icon
       | 
       | > _I hate that there is no way for me to disable it as a user_
       | 
       | > I hate that it has muddied the waters in what the url bar means
       | 
       | > I hate that it has trained users to not question fake url bars.
       | 
       | > I hate that cloudflare so thoroughly jumped on its dick
       | 
       | > I hate that we invented a way to fake the address in the url
       | bar just for this stupid fucking feature.
       | 
       | > I hate that we now have a system where somebody can share a
       | page url with a friend, and that friend can view it on the same
       | device model using the same browser with the same settings, and
       | will get a different page because one was viewing an amp page but
       | shared it's real url.
       | 
       | > I hate that every fucking amp page is lower featured in some
       | way, and almost never works in desktop mode.
       | 
       | > And most of all, I hate that it leads to everybody offloading
       | shit onto google's servers.
       | 
       | > AMP is not fast because it's served from google's CDN. AMP is
       | fast because it's incompatible with 99% of the bullshit client
       | cpu heavy tracking and ad libraries, so they don't get included
       | inside AMP pages.
        
       | stefan_ wrote:
       | This is a bit embarrassing. You joined the committee when AMP was
       | already dead in the water and even now it seems this has not been
       | made to clear you.
        
       | skybrian wrote:
       | He seems disappointed but it sounds about what I'd expect from an
       | "advisory committee." I would expect giving advice to be a form
       | of influence rather than power. You're only as good as your
       | persuasive skills and their willingness to listen.
        
       | josefrichter wrote:
       | Btw it's Potemkin, not Potempkin
        
       | gregable wrote:
       | I won't try to address every part of this writing, but there is
       | one claim that I feel is false: namely that the AMP validation
       | rules are not open source.
       | 
       | Here is the code:
       | https://github.com/ampproject/amphtml/tree/main/validator
       | 
       | All of the rules are written in human-readable config language.
       | Here are the rules for common HTML elements
       | (https://github.com/ampproject/amphtml/blob/main/validator/va...)
       | and there are rules per-amp-tag (example:
       | https://github.com/ampproject/amphtml/blob/main/extensions/a...)
       | 
       | You can build it, run it locally, etc. There are open-source
       | implementations that run in the browser, in a vscode plugin, on
       | the command line via NPM, etc. Other entities can and do use the
       | same code for their validation of AMP. Pull Requests are accepted
       | from anyone and those changes land in Google production and all
       | of the aforementioned tooling targets within a few days. There is
       | documentation on how to contribute to and edit these files (https
       | ://github.com/ampproject/amphtml/blob/main/docs/compone...).
        
         | dmitriid wrote:
         | > namely that the AMP validation rules are not open source.
         | Here is the code
         | 
         | Yes. That's the trick big corps play on you. They develop some
         | code, and push it to GitHub.
         | 
         | - all of the decisions where the code is going belong to the
         | corp
         | 
         | - all (or at the absolute vast majority) of contributions come
         | from the corp's developers
         | 
         | - there's little to no insight into why things are the way the
         | are. Sometimes you can be big enough to gain acces, or
         | important enough. Before "open governance" it was some
         | publisher group set up by Google that was supposedly there to
         | monitor
         | 
         | But sure, it's open source.
         | 
         | > Pull Requests are accepted from anyone and those changes land
         | in Google production
         | 
         | 1. What's the ratio of PRs from Google employees to those from
         | "anyone"?
         | 
         | 2. Indeed. They land in _Google_ production. The company with
         | $183 billion in yearly revenue thanks you for your unpaid
         | contributions (if they ever make it)
         | 
         | ---
         | 
         | BTW, there are 1 500 open issues in that repo. Quite a lot for
         | some validation rules.
        
           | gregable wrote:
           | I did some hacky analysis and roughly half of the PRs
           | originated in GitHub and the majority of those are not google
           | employees.
           | 
           | Most changes have a github issue attached with discussion,
           | all of the changes have descriptive commit messages
           | regardless of who authored them and there is significant
           | effort to document the decisions and decision process
           | throughout.
           | 
           | I can't speak for the release frequency for other
           | organizations' production that consumes this code. That
           | includes many publishers, as well as other AMP caches such as
           | Bing and webmail clients like Yahoo.
           | 
           | The repo is for all of AMP, not just the validator. The
           | validator related issues are handled by the "caching" working
           | group (since caches are the consumer of the validator) and
           | you can search for them with this query: https://github.com/a
           | mpproject/amphtml/issues?q=is%3Aissue+is...
        
           | jsnell wrote:
           | You're simultaneously complaining about how all the commits
           | are coming from the company and that they're exploiting
           | anyone making commits. You can't have it both ways, pick one.
           | 
           | The repository has 1k contributors over 20k commits. That
           | seems like an exceptionally diverse contributor base.
        
       | ohazi wrote:
       | > So it's best for everyone if I step away now instead of
       | descending into outright sabotage.
       | 
       | It's best for other members of the committee, and perhaps for the
       | sanity of the author, but I think you could make the argument
       | that _effective_ sabotage of the AMP project could actually be
       | best for the public at large.
        
         | kevin_thibedeau wrote:
         | Why would Google take advice from non-employees? Committees
         | like this only serve to shield Google from criticism. They
         | aren't meant to accomplish anything.
        
       | throw_m239339 wrote:
       | I don't like AMP. However, if I wouldn't use a mobile browser
       | which didn't basically do the same (MITM websites), my DATA plan
       | would be over by the forth day of the month.
       | 
       | The mobile web, after all these years, is still so heavy.
       | 
       | No, devs don't need all images to be for retina display, they
       | don't need to bundle 50 MB of JS on ever pages, they don't need
       | to load custom fonts for text, auto start videos, ... then why
       | are webpages still so big on mobile? What happened to mobile
       | first? Seems to me like it's just native app first on mobile then
       | some amount of responsiveness for desktop websites...
       | 
       | what happened? I'm not willing to visit or spend money on a
       | website that drains all my data plan while I'm browsing for
       | products...
       | 
       | For all the SEO tricks websites use to drive traffic, it doesn't
       | seem like mobile page speed is relevant in anyway when it comes
       | to SEO or we would have a very different web...
        
         | ohazi wrote:
         | Firefox mobile allows you to use uBlock origin, which improves
         | things tremendously.
         | 
         | Every time I accidentally end up in mobile Chrome, it's like
         | being transported back in time 15 years with popups and
         | overlays and modals that are deliberately designed to lag just
         | enough for you to accidentally click on the ad rather than the
         | tiny X button.
         | 
         | What happened? Google happened.
         | 
         | The mobile web is essentially the desktop web before ad
         | blockers, and Google won't allow mobile Chrome to support
         | extensions because "oh no, extensions are hard" -- they're
         | lying. They know that a mobile ad blocker is the easiest and
         | fastest way for us to hide their toxic cesspool of mobile ads.
        
         | albertgoeswoof wrote:
         | That's only a problem in countries with poor network
         | infrastructure, most developed countries have unlimited data
         | plans at reasonable costs
        
           | forcemajeure wrote:
           | Not true in Australia
        
             | 8ytecoder wrote:
             | Again as the OP said, " That's only a problem in countries
             | with poor network infrastructure".
             | 
             | Australia is a victim of its geography. (Plus last I heard
             | the National fiber backbone didn't go as planned either).
             | I'm would expect a high bandwidth wired backbone is
             | required to support scaling up mobile data throughput.
        
       | SquareWheel wrote:
       | I'd be curious if there has been any effort made towards
       | encouraging wider use of the Amp Cache. After CloudFlare dropped
       | theirs, now only Google and Microsoft maintain an Amp Cache.
       | 
       | Large search engines are probably the primary audience for that
       | technology, so would there be interest from Baidu or Yandex?
        
       | thepangolino wrote:
       | I really never got the point of AMP being anything else than a
       | set of recommendations for lighter mobile pages. A sort of
       | remnant of the time where you got redirected to another version
       | of the website you were visiting if you were doing so from a
       | mobile device.
        
         | vasachi wrote:
         | The point is to prevent user from leaving google.com.
        
         | SevenSigs wrote:
         | The main problem with AMP is that everything loads from
         | Google's servers... so it is not worth using even if sometimes
         | it can be faster (Google itself should probably use it instead
         | of their javascript mess that slows down everything for no
         | reason).
        
         | rakshazi wrote:
         | The ironic part of AMP is that it's heavely relies on js.
         | External js.
         | 
         | For example, you have a lightweight website with size of 140kb
         | for everything (html, CSS, js, images) without AMP. It works
         | blazing fast and you get 100/100 scores on any website speed
         | meter.
         | 
         | But it was not enough for google, because you don't use their
         | super-duper AMP tech.
         | 
         | You known what? Your website doubles in size when you implement
         | AMP, because you must load several additional scripts to make
         | AMP work, and not only size increases, load time (from click on
         | your website link till full render) will increase too, because
         | additional js processing to make AMP work.
         | 
         | The only benefit was preloading and heavely caching by Google,
         | so user feels like website shows instantly.
         | 
         | I "optimized" several lightweight websites with AMP and every
         | time I had exactly one thought in mind - that's useless stuff
         | adds more problems than benefits, except mobile search ranking.
         | 
         | Thanks God now AMP is not mandatory to be in google mobile
         | search top
        
           | esprehn wrote:
           | Do you have some examples of sites where the regular site is
           | faster than the AMP one?
        
             | dbbk wrote:
             | Literally anything that doesn't use JS and is CDN cached?
        
             | [deleted]
        
         | dmitriid wrote:
         | AMP was first and foremost an answer to Facebook's Instant
         | Articles (or whatever they were called), and, as an extension,
         | a death grip on publishers.
         | 
         | Everything else in AMP served that.
        
         | [deleted]
        
         | DrBenCarson wrote:
         | The point is Google keeps users captive and content publishers
         | hostage. All for a glorified CDN serving "light" static pages.
        
         | pornel wrote:
         | The AMP project allowed Google to dictate how ads can be
         | served, and host publishers' pages themselves. Don't forget
         | Google is a tracking-based advertising company.
         | 
         | It was very convenient that these things could be bundled in a
         | package with some webdev best practices, a JavaScript
         | framework, and marketed as a (questionable) speed improvement.
         | 
         | I've worked for a publisher that abandoned serving their own
         | fast no-JS article pages in favor of half-assed AMP pages full
         | of slow iframes, because Google favored any use of AMP over
         | actual page speed. It took Google many years to ease that AMP
         | favoritism.
        
       | openasocket wrote:
       | > We were immediately told that we could not discuss an ongoing
       | court case in the AMP advisory committee. That's fair enough. But
       | will it go both ways? Or will lawyers acting on Google's behalf
       | be allowed to point to the AMP advisory committee and say, "But
       | AMP is an open source project! Look, it even resides under the
       | banner of the OpenJS Foundation."
       | 
       | Google's lawyers will most likely do something like that, though
       | . But there's nothing stopping you from contacting the
       | prosecution and offering testimony against the claim that AMP is
       | open source. Unless the AMP advisory committee is somehow
       | considered a party in the lawsuit? Though even then, depending on
       | how the committee works, I don't think they could ban you from
       | communicating with the prosecution.
       | 
       | Actually I'd expect members of the advisory committee to be
       | deposed. The prosecution explicitly mentions the AMP committee in
       | their suit: "Although Google claims that AMP was developed as an
       | open-source collaboration, AMP is actually a Google-controlled
       | initiative. Google originally registered and still owns AMP's
       | domain, ampproject.org. In addition, until the end of 2018,
       | Google controlled all AMP decision- making. AMP relied on a
       | governance model called "Benevolent Dictator For Life" that
       | vested ultimate decision-making authority in a single Google
       | engineer. Since then, Google has transferred control of AMP to a
       | foundation, but the transfer was superficial. Google controls the
       | foundation's board and debates internally" . Both Google and the
       | prosecution will likely depose members of the committee to get
       | testimony regarding those facts.
        
       ___________________________________________________________________
       (page generated 2021-08-18 23:01 UTC)