I make this mistake too, but we need to stop calling it an open standard unless it's handed over to a neutral standards-making body. AMP's solution to the URL problem involves another Google-pushed web standard, webpackage. But the big difference is that webpackage is part of the WICG, a community group under the W3C. That's a real standard, this is not.

If AMP not handed over to the W3C, I don't think we can or should call it a standard.

I'm not at all up on my tech politics, but I'm curious about your implication that the W3C is neutral. Is that something we can take for granted, given the way they went forward with EME[0]? Otherwise, though, I'm inclined to agree.

[0] https://www.eff.org/deeplinks/2017/07/amid-unprecedented-con...

I'm definitely not fond of EME, but the W3C's interests go well beyond that of a single corporation. For instance, WICG, which I mentioned, lists three chairs, who are employed by Google, Mozilla, and Akamai respectively.

I don't think Mozilla was super fond of EME either, but couldn't afford to be "the web browser that can't watch Netflix".

I definitely do remain wary of these groups being forced to rubber stamp things, I do feel Google exerts way too much control even in that space, because due to their monopolies, they can just implement what they want, and sometimes the W3C has to accept it or be irrelevant.

I want instantly loaded web pages now, not in 5 years when the standard is ready and Apple has finished dragging its heels and implemented it in its browsers, allowing publishers to finally use it.

That attitude is what allowed Internet Explorer to become the dominant browser. What are you going to do when Google gets bored of supporting Chrome and disbands the team, leaving your web pages tied to a stagnating browser?

> What are you going to do when Google gets bored of supporting Chrome and disbands the team, leaving your web pages tied to a stagnating browser?

The whole point is that AMP works on all major browsers as they exist today. Waiting for a new standard and then waiting for Apple to implement it is a non-starter.

Sure, just like Google Earth works on any browser, or Hangouts, or ...

Google's always only supporting competing software just as much as absolutely necessary

Google might make web apps that work in only one browser, but publishers won't publish in a format that supports only one browser. That's why Microsoft, Baidu, Yahoo Japan, etc. also have AMP caches.

On the other hand, using the web package standard as the ancestor suggests would currently trap you to Google.

AMP isn't truly "open" technology. You can't even discuss its problems on Github without getting the conversation shut down. AMP is an insidious threat the the open WWW itself. It doesn't solve problems that can't be solved in better ways.

The best way to improve AMP is to drag it out behind the wood shed and shoot it. People just need to get better at making mobile web pages.

I'm not saying you're wrong.

But I will say I think your wood shed idea won't work.

(Though I am very open to hearing more about it's implementation.)

Yeah I don't think that's realistic either but validating Google by participating in their selfish initiative isn't going to do anyone any favors.

Where you can oppose the adoption of AMP and work on improving the rest of the ecosystem so that AMP has fewer compelling applications.

Am I reading the article right: the browser preloads resources from amp pages from the search page?

That's going to be hard to fix in an HTMLLite sorry of way.

HTTP/2 servers can preload (if they choose).

Doesn't that require same origin, and thus AMP-style central caching?

Google is pushing "HTTP origin signed responses" which will mean Google or any other implementing server can cache responses from other (willing) origins and push or offer them. Then, the address bar can show the actual origin, instead of www.google.com/amp as the origin.

Preload is different from push.