7 ms·

If I understand correctly, the biggest problem was that google was hosting the cached amp pages. If this instead sends the user to your own domain, viewing your

If I understand correctly, the biggest problem was that google was hosting the cached amp pages. If this instead sends the user to your own domain, viewing your content which just happens to be hosted elsewhere, does that solve the primary complaints? I know google was also exposing content directly on the search results, but I feel that's a separate issue.

tyingq 8y ago
Curious if Google still owns the left/right swipe and back button events when a user lands on your page from a carousel. Also don't miss the bit about "currently just Chrome on Android"
mmastrac 8y ago
The problem is that the AMP standard is just generally poorly-thought-out, no matter who hosts it. Instead of a subset of HTML, it's a weird mishmash of everything that requires magic incantations to make things work for the browsers of the time it was invented. It's like NaCl/PNaCl - a good idea in theory, but created by a team that didn't do a great job at speccing something that could be long lived and satisfy other players than Google+Chrome.
- cromwellian 8y ago
  Isn’t it a subset by definition? It runs in html5 browsers. Other sunsets of HTML failed magnificently like XHTML basic and it’s siblings.
  - tyingq 8y ago
    Technically perhaps. But with things like <amp-img> instead of <img>, so yes, it "runs".
    - cromwellian 8y ago
      Web-components are HTML. Registering a new element (e.g. <amp-img>) that wraps <img> with some additional restrictions, is pretty much making a subset facade that restricts you to the subset. It's like complaining that BibTeX, LaTeX, AMSTeX et al aren't "TeX". In the original incarnation of SGML, the whole point of the DTD and DSSSL was to be able to define new elements, and specify how they are handled. This seems perfectly legitimate and part of the HTML standard. There may be other problems with AMP, but creating new high level elements that resolve to standard HTML elements, doesn't seem to be one of them, and arguing over whether something is named 'amp-img', or 'img' + some detailed validator that throws errors if you try to do anything with <img> off the rails, seems to be bike-shedding over naming, and if anything, I'd argue giving new names to a function to limit its inputs is more clear and readable, then adding precondition checks only.
      - deleted 8y ago
        [deleted]
      - tyingq 8y ago
        Well those new elements aren't functional unless you specifically include a Google controlled/hosted piece of JavaScript in your AMP page. If it's a standard, shouldn't there be some way for those elements to work without including someone else's JavaScript?
        cromwellian 8y ago
        Isn't that like saying "This page doesn't render without including this CSS or Font or XSL Stylesheet"? If your objection is that the ampjs has to be loaded from Google's CDN, well, the whole point of Signed Exchanges/Web packaging is to move to a world where AMP caches are federated and you can host this stuff elsewhere. The only real objection that has merit IMHO is that Google Search should rank these things based on performance, not on amp validation alone, so if you authored your own AMP-like framework, it could be similarly ranked.
        tyingq 8y ago
- dfabulich 8y ago
  This new thing substantially improves the design. What design problems do you see in the new thing?
  - mmastrac 8y ago
    The whole spec is still a giant mess [1] of HTML and HTML-like-but-not-quite-really, with a boatload of ceremony that does nothing but glue it into an existing ecosystem. Hosting it on someone else's site doesn't fix that. [1] https://amp.dev/ru/documentation/guides-and-tutorials/learn/spec/amphtml?referrer=ampproject.org https://amp.dev/ru/documentation/guides-and-tutorials/learn/...
    - themacguffinman 8y ago
      I honestly don't see the mess that you're referring to. Can you be a bit more specific? AFAIK, Amp is 100% valid HTML because it's a HTML subset, it is not "HTML-like-but-not-really".
      - pdkl95 8y ago
        That is patently not true. From mmastrac's [1]: > Resources such as images, videos, audio files or ads must be included into an AMP HTML file through custom elements such as <amp-img> From: https://github.com/ampproject/amphtml/blob/master/spec/amp-tag-addendum.md#amp-specific-tags https://github.com/ampproject/amphtml/blob/master/spec/amp-t... Amp Specific Tags <amp-img> <amp-video> <amp-ad> <amp-fit-text> <amp-font> <amp-carousel> <amp-anim> <amp-youtube> <amp-twitter> <amp-vine> <amp-instagram> <amp-iframe> <amp-pixel> <amp-audio> <amp-lightbox> <amp-image-lightbox> None of that is "100% valid HTML".
        themacguffinman 8y ago
        Custom elements are 100% valid and standards-compliant HTML. https://html.spec.whatwg.org/multipage/custom-elements.html https://html.spec.whatwg.org/multipage/custom-elements.html https://www.w3.org/TR/custom-elements/ https://www.w3.org/TR/custom-elements/
- throwawaymath 8y ago
  What's wrong with NaCl?
  - dfabulich 8y ago
    I believe the gp was referring to NaCl the Native Client https://developer.chrome.com/native-client https://developer.chrome.com/native-client Not the crypto library https://nacl.cr.yp.to/ https://nacl.cr.yp.to/
  - mmastrac 8y ago
    NaCl was an interesting tech demo, but it was a complex set of rules built on the x86 house of cards and it took a lot of work to port it between platforms (I think it was demoed on ARM but never took off). PNaCl was a "lazy" attempt at making this cross-platform by leveraging LLVM's intermediate format which was never designed to be a "format" like that. WebAssembly is 10x better than either of those formats and you can see the benefits of having multiple players design something to work for a long-term horizon.
chime 8y ago
As I understand it, Google actually hosts the AMP content but the browser “lies” and says the content is coming from the original domain. I honestly would prefer what you are suggesting, even if that meant using iframe on the original domain to host the AMP cache from Google. 1. example.com/long-url with content and meta tag specifying AMP url (2) below. 2. example.com/long-url/amp that embeds a full-height 0-margin iframe to google.com/amp/example.com/long-url and has no external styles/JS. 3. Google caches content from (1) example.com/long-url and when user clicks it, directs them to (2) example.com/long-url/amp. Other than 1 extra HTML page, everything is from Google’s AMP cache. The browsers do not need to lie. And if Cloudflare hosts the (2) AMP page, it can be fast as the rest of their services.
- gruez 8y ago
  >but the browser “lies” and says the content is coming from the original domain. Is this a chrome thing? I don't notice it on safari.
  - tyingq 8y ago
    It's "Signed HTTP Exchanges" "It is worth noting that SXG is already supported by the Opera web browser, still under evaluation by the Microsoft Edge team, while Mozilla Firefox considers it harmful, and the Safari team already expressed its skepticism" https://www.bleepingcomputer.com/news/google/google-chrome-adding-support-for-signed-http-exchanges/ https://www.bleepingcomputer.com/news/google/google-chrome-a...
  - judge2020 8y ago
    It's a technically feasable thing: > The solution makes use of Web Packaging (which incorporates some clever use of cryptography) to allow the cache (run by Google, Cloudflare or others) to keep a copy of an AMP page and serve it quickly to the end user, but to also contain cryptographic proof of where the page originally came from. Not sure if WebKit/safari have implemented this yet.
    - tyingq 8y ago
JohnFen 8y ago
> If I understand correctly, the biggest problem was that google was hosting the cached amp pages. Speaking for myself, that's one large problem. The other large problem is that I dislike the AMP pages themselves.
snek 8y ago
The biggest issue is that google is forcing websites to use its own html subset by judging sites that use it instead of by judging sites based on actual speed. There are a lot of posts on HN about sites that got no speed increase or even regressed when switching to AMP.
stephenr 8y ago
> If this instead sends the user to your own domain, viewing your content which just happens to be hosted elsewhere But it doesn’t. It sends them elsewhere and pretends it’s your domain.
- AgentME 8y ago
  Is that different than a CDN? This seems even better than a CDN, because the client verifies that the content is signed by the original server, where a normal CDN is free to modify content that goes through it.
  - stephenr 8y ago
    A data-whoring mega-corp isn't forcing anyone to use a CDN, and a CDN doesn't mandate Javascript (and CSS to punish visitors who block that JS).
mook 8y ago
The biggest problem for me is loading an external script (hosted by Google), plus CSS rules to hide the content until a timeout if that script doesn't load. It literally makes the pages load slower for me (but will never show up in their telemetry).

tyingq 8y ago

Curious if Google still owns the left/right swipe and back button events when a user lands on your page from a carousel. Also don't miss the bit about "currently just Chrome on Android"

mmastrac 8y ago

The problem is that the AMP standard is just generally poorly-thought-out, no matter who hosts it. Instead of a subset of HTML, it's a weird mishmash of everything that requires magic incantations to make things work for the browsers of the time it was invented. It's like NaCl/PNaCl - a good idea in theory, but created by a team that didn't do a great job at speccing something that could be long lived and satisfy other players than Google+Chrome.

cromwellian 8y ago
Isn’t it a subset by definition? It runs in html5 browsers. Other sunsets of HTML failed magnificently like XHTML basic and it’s siblings.
- tyingq 8y ago
  Technically perhaps. But with things like <amp-img> instead of <img>, so yes, it "runs".
  - cromwellian 8y ago
    Web-components are HTML. Registering a new element (e.g. <amp-img>) that wraps <img> with some additional restrictions, is pretty much making a subset facade that restricts you to the subset. It's like complaining that BibTeX, LaTeX, AMSTeX et al aren't "TeX". In the original incarnation of SGML, the whole point of the DTD and DSSSL was to be able to define new elements, and specify how they are handled. This seems perfectly legitimate and part of the HTML standard. There may be other problems with AMP, but creating new high level elements that resolve to standard HTML elements, doesn't seem to be one of them, and arguing over whether something is named 'amp-img', or 'img' + some detailed validator that throws errors if you try to do anything with <img> off the rails, seems to be bike-shedding over naming, and if anything, I'd argue giving new names to a function to limit its inputs is more clear and readable, then adding precondition checks only.
    - deleted 8y ago
      [deleted]
    - tyingq 8y ago
      Well those new elements aren't functional unless you specifically include a Google controlled/hosted piece of JavaScript in your AMP page. If it's a standard, shouldn't there be some way for those elements to work without including someone else's JavaScript?
      - cromwellian 8y ago
        Isn't that like saying "This page doesn't render without including this CSS or Font or XSL Stylesheet"? If your objection is that the ampjs has to be loaded from Google's CDN, well, the whole point of Signed Exchanges/Web packaging is to move to a world where AMP caches are federated and you can host this stuff elsewhere. The only real objection that has merit IMHO is that Google Search should rank these things based on performance, not on amp validation alone, so if you authored your own AMP-like framework, it could be similarly ranked.
        tyingq 8y ago
dfabulich 8y ago
This new thing substantially improves the design. What design problems do you see in the new thing?
- mmastrac 8y ago
  The whole spec is still a giant mess [1] of HTML and HTML-like-but-not-quite-really, with a boatload of ceremony that does nothing but glue it into an existing ecosystem. Hosting it on someone else's site doesn't fix that. [1] https://amp.dev/ru/documentation/guides-and-tutorials/learn/spec/amphtml?referrer=ampproject.org https://amp.dev/ru/documentation/guides-and-tutorials/learn/...
  - themacguffinman 8y ago
    I honestly don't see the mess that you're referring to. Can you be a bit more specific? AFAIK, Amp is 100% valid HTML because it's a HTML subset, it is not "HTML-like-but-not-really".
    - pdkl95 8y ago
      That is patently not true. From mmastrac's [1]: > Resources such as images, videos, audio files or ads must be included into an AMP HTML file through custom elements such as <amp-img> From: https://github.com/ampproject/amphtml/blob/master/spec/amp-tag-addendum.md#amp-specific-tags https://github.com/ampproject/amphtml/blob/master/spec/amp-t... Amp Specific Tags <amp-img> <amp-video> <amp-ad> <amp-fit-text> <amp-font> <amp-carousel> <amp-anim> <amp-youtube> <amp-twitter> <amp-vine> <amp-instagram> <amp-iframe> <amp-pixel> <amp-audio> <amp-lightbox> <amp-image-lightbox> None of that is "100% valid HTML".
      - themacguffinman 8y ago
        Custom elements are 100% valid and standards-compliant HTML. https://html.spec.whatwg.org/multipage/custom-elements.html https://html.spec.whatwg.org/multipage/custom-elements.html https://www.w3.org/TR/custom-elements/ https://www.w3.org/TR/custom-elements/
throwawaymath 8y ago
What's wrong with NaCl?
- dfabulich 8y ago
  I believe the gp was referring to NaCl the Native Client https://developer.chrome.com/native-client https://developer.chrome.com/native-client Not the crypto library https://nacl.cr.yp.to/ https://nacl.cr.yp.to/
- mmastrac 8y ago
  NaCl was an interesting tech demo, but it was a complex set of rules built on the x86 house of cards and it took a lot of work to port it between platforms (I think it was demoed on ARM but never took off). PNaCl was a "lazy" attempt at making this cross-platform by leveraging LLVM's intermediate format which was never designed to be a "format" like that. WebAssembly is 10x better than either of those formats and you can see the benefits of having multiple players design something to work for a long-term horizon.

chime 8y ago

As I understand it, Google actually hosts the AMP content but the browser “lies” and says the content is coming from the original domain. I honestly would prefer what you are suggesting, even if that meant using iframe on the original domain to host the AMP cache from Google. 1. example.com/long-url with content and meta tag specifying AMP url (2) below. 2. example.com/long-url/amp that embeds a full-height 0-margin iframe to google.com/amp/example.com/long-url and has no external styles/JS. 3. Google caches content from (1) example.com/long-url and when user clicks it, directs them to (2) example.com/long-url/amp. Other than 1 extra HTML page, everything is from Google’s AMP cache. The browsers do not need to lie. And if Cloudflare hosts the (2) AMP page, it can be fast as the rest of their services.

gruez 8y ago
>but the browser “lies” and says the content is coming from the original domain. Is this a chrome thing? I don't notice it on safari.
- tyingq 8y ago
  It's "Signed HTTP Exchanges" "It is worth noting that SXG is already supported by the Opera web browser, still under evaluation by the Microsoft Edge team, while Mozilla Firefox considers it harmful, and the Safari team already expressed its skepticism" https://www.bleepingcomputer.com/news/google/google-chrome-adding-support-for-signed-http-exchanges/ https://www.bleepingcomputer.com/news/google/google-chrome-a...
- judge2020 8y ago
  It's a technically feasable thing: > The solution makes use of Web Packaging (which incorporates some clever use of cryptography) to allow the cache (run by Google, Cloudflare or others) to keep a copy of an AMP page and serve it quickly to the end user, but to also contain cryptographic proof of where the page originally came from. Not sure if WebKit/safari have implemented this yet.
  - tyingq 8y ago

JohnFen 8y ago

> If I understand correctly, the biggest problem was that google was hosting the cached amp pages. Speaking for myself, that's one large problem. The other large problem is that I dislike the AMP pages themselves.

snek 8y ago

The biggest issue is that google is forcing websites to use its own html subset by judging sites that use it instead of by judging sites based on actual speed. There are a lot of posts on HN about sites that got no speed increase or even regressed when switching to AMP.

stephenr 8y ago

> If this instead sends the user to your own domain, viewing your content which just happens to be hosted elsewhere But it doesn’t. It sends them elsewhere and pretends it’s your domain.

AgentME 8y ago
Is that different than a CDN? This seems even better than a CDN, because the client verifies that the content is signed by the original server, where a normal CDN is free to modify content that goes through it.
- stephenr 8y ago
  A data-whoring mega-corp isn't forcing anyone to use a CDN, and a CDN doesn't mandate Javascript (and CSS to punish visitors who block that JS).

mook 8y ago

The biggest problem for me is loading an external script (hosted by Google), plus CSS rules to hide the content until a timeout if that script doesn't load. It literally makes the pages load slower for me (but will never show up in their telemetry).