6 ms·

I don't consider either necessary. Clicking a link and then loading the page works just fine for the web. Creating a custom HTML fork that puts more pressure o

I don't consider either necessary. Clicking a link and then loading the page works just fine for the web. Creating a custom HTML fork that puts more pressure on limited publisher dev teams to end up with another copy o the site (and now SSR) is a worse approach than placing loading speed into search results ranking and letting sites optimize the site for everyone with a browser.

lern_too_spel 7y ago
> Clicking a link and then loading the page works just fine for the web. No, it doesn't. If it did, there would be no need for Facebook Instant Articles, Apple News, or their successor, AMP. > Creating a custom HTML fork that puts more pressure on limited publisher dev teams to end up with another copy o the site They're already doing this with Facebook Instant Articles and Apple News. Imagine if they had to do separate integrations with Bing, Google, Yahoo! Japan, Baidu, and any future link aggregators. AMP lets them publish one page and support all of them.
- manigandham 7y ago
  No, none of this is needed. Make speed a factor in search results and sites get faster. The single HTML version will get faster for everyone on every device, not just mobile sites from certain platforms. Facebook IA and Apple News are also attempts to control ads and data, just like AMP. They're all bad for publishers. IA and AN have both failed in providing anywhere near the benefits and revenue they promised. AMP only survives because it's compatible with existing ads served by Google's ad network and given higher placement in their search results. It's rather amazing how Google is specifically offering the solution to a problem caused by their own adtech software.
  - lern_too_spel 7y ago
    > No, none of this is needed. Make speed a factor in search results and sites get faster. You can't get faster than prerendered, which is what Apple News and Facebook Instant Articles offer, which AMP is the open alternative to. > AMP only survives because it's compatible with existing ads served by Google's ad network and given higher placement in their search results. If that's the case, why does Bing use it? > It's rather amazing how Google is specifically offering the solution to a problem caused by their own adtech software. What's rather amazing is that after having repeatedly heard the problem that AMP solves (instant loading pages), you continue to straw man what it solves and what technologies it competes with. > Facebook IA and Apple News are also attempts to control ads and data, just like AMP. They're all bad for publishers. Yet only AMP gets the rabid hate. Why is that? AMP is essentially RSS items with support for above the fold prerendering, interactivity, and monetization. You probably love RSS, even though it is even worse for publishers. Why?
    - dmitriid 7y ago
      > which AMP is the open alternative to. It's not an open alternative. All decisions on what AMP should look like and what it supports are done by Google behind closed doors. See, for example, AMP 4 Email [1] The only reason AMP exists is because Google needed its own way to control content. That is it. > If that's the case, why does Bing use it? Because you're forced to compete against the behemoth on the behemoth's terms. > What's rather amazing is that after having repeatedly heard the problem that AMP solves (instant loading pages) AMP's problems are well documented. You chose to ignore all of them and go for "instant loading pages". > Yet only AMP gets the rabid hate. Why is that? Because it reaches a wider audience and Google has the gall to call it "open" and "good for the web". It's neither. > AMP is essentially RSS items It is not like RSS in any way, shape, or form. [1] https://news.ycombinator.com/item?id=16455593 https://news.ycombinator.com/item?id=16455593
      - lern_too_spel 7y ago
        > It's not an open alternative. All decisions on what AMP should look like and what it supports are done by Google behind closed doors. See, for example, AMP 4 Email [1] Your examples predate https://www.google.com/amp/s/blog.amp.dev/2018/11/30/amp-projects-new-governance-model-now-in-effect/ https://www.google.com/amp/s/blog.amp.dev/2018/11/30/amp-pro... and no longer seem to apply. > The only reason AMP exists is because Google needed its own way to control content. That's nonsensical. Why then does Bing use it? > Because you're forced to compete against the behemoth on the behemoth's terms. Why are they forced to use it? I would really like to see your position stated coherently. > AMP's problems are well documented. How do you propose to achieve instant loading web pages, while working around all of iOS's bugs? > It is not like RSS in any way, shape, or form. This just demonstrates that you don't understand AMP, don't understand RSS, or don't understand both. AMP allows the link aggregator to cache and directly serve the article contents, exactly like RSS does.
        dmitriid 7y ago
        > Your examples predate <Advisory Committee> Advisory Committee has no say in anything that AMP does. Everything is designed and specced inside Google (or Google-dominated work groups) and then vetted by the Technical Steering Committee. Advisory Committee's findings and advise is non-binding: https://github.com/ampproject/meta/pull/37 https://github.com/ampproject/meta/pull/37 And all the WG's are assigned projects that have already been accepted into AMP (such as AMP 4 Email). And yes, my example is important because it was a huge change that no one asked for, but now it's in AMP. As are all the other changes that already hurt the web. > Why are they forced to use it? I would really like to see your position stated coherently. Google has near monopoly on search. In order to compete with it you need to provide nearly all of the same features. > How do you propose to achieve instant loading web pages, while working around all of iOS's bugs? There are no bugs in iOS that preclude instant pages. And the bugs that AMP introduced are, well, the bugs that AMP introduced. AMP broke the behaviour on purpose and refused to implement any suggested fixes. > This just demonstrates that you don't understand AMP, don't understand RSS, or don't understand both. AMP allows the link aggregator to cache and directly serve the article contents, exactly like RSS does. I perfectly understand what AMP and RSS are. You don't understand what either one is. RSS was never about caching or link aggregators. RSS is a web feed. That has a standard XML format and can be read by anyone: a client app on your phone, a client app on your desktop, a link aggregator that can be built by a half-decent engineer in about two evenings. Additionally, it is trivially discoverable by including a standard meta tag on a page. Also, RSS always leads to the original URL. AMP is not a feed. It's a collection of specially constructed HTML pages (which are not valid HTML5, by the way). They are not "instant". They are underperformant by Google's own standards (try running Google's own Lighthouse tools report against one from cold cache). They are only "instant" when significant effort has been spent setting up an AMP cache so that some or all content is already on the client's browser before the client hits the AMP page. They are not discoverable. A meta tag linking to an AMP version will only link one URL, that's it. There is no feed. An AMP cache destroyes the very essence of the web: linking. You will not get the original URL, you will get the cache's URL. Implementing an AMP cache is a significant endeavour, and only a handful exists (as far as I know, there are no opensource AMP caches).

lern_too_spel 7y ago

> Clicking a link and then loading the page works just fine for the web. No, it doesn't. If it did, there would be no need for Facebook Instant Articles, Apple News, or their successor, AMP. > Creating a custom HTML fork that puts more pressure on limited publisher dev teams to end up with another copy o the site They're already doing this with Facebook Instant Articles and Apple News. Imagine if they had to do separate integrations with Bing, Google, Yahoo! Japan, Baidu, and any future link aggregators. AMP lets them publish one page and support all of them.

manigandham 7y ago
No, none of this is needed. Make speed a factor in search results and sites get faster. The single HTML version will get faster for everyone on every device, not just mobile sites from certain platforms. Facebook IA and Apple News are also attempts to control ads and data, just like AMP. They're all bad for publishers. IA and AN have both failed in providing anywhere near the benefits and revenue they promised. AMP only survives because it's compatible with existing ads served by Google's ad network and given higher placement in their search results. It's rather amazing how Google is specifically offering the solution to a problem caused by their own adtech software.
- lern_too_spel 7y ago
  > No, none of this is needed. Make speed a factor in search results and sites get faster. You can't get faster than prerendered, which is what Apple News and Facebook Instant Articles offer, which AMP is the open alternative to. > AMP only survives because it's compatible with existing ads served by Google's ad network and given higher placement in their search results. If that's the case, why does Bing use it? > It's rather amazing how Google is specifically offering the solution to a problem caused by their own adtech software. What's rather amazing is that after having repeatedly heard the problem that AMP solves (instant loading pages), you continue to straw man what it solves and what technologies it competes with. > Facebook IA and Apple News are also attempts to control ads and data, just like AMP. They're all bad for publishers. Yet only AMP gets the rabid hate. Why is that? AMP is essentially RSS items with support for above the fold prerendering, interactivity, and monetization. You probably love RSS, even though it is even worse for publishers. Why?
  - dmitriid 7y ago
    > which AMP is the open alternative to. It's not an open alternative. All decisions on what AMP should look like and what it supports are done by Google behind closed doors. See, for example, AMP 4 Email [1] The only reason AMP exists is because Google needed its own way to control content. That is it. > If that's the case, why does Bing use it? Because you're forced to compete against the behemoth on the behemoth's terms. > What's rather amazing is that after having repeatedly heard the problem that AMP solves (instant loading pages) AMP's problems are well documented. You chose to ignore all of them and go for "instant loading pages". > Yet only AMP gets the rabid hate. Why is that? Because it reaches a wider audience and Google has the gall to call it "open" and "good for the web". It's neither. > AMP is essentially RSS items It is not like RSS in any way, shape, or form. [1] https://news.ycombinator.com/item?id=16455593 https://news.ycombinator.com/item?id=16455593
    - lern_too_spel 7y ago
      > It's not an open alternative. All decisions on what AMP should look like and what it supports are done by Google behind closed doors. See, for example, AMP 4 Email [1] Your examples predate https://www.google.com/amp/s/blog.amp.dev/2018/11/30/amp-projects-new-governance-model-now-in-effect/ https://www.google.com/amp/s/blog.amp.dev/2018/11/30/amp-pro... and no longer seem to apply. > The only reason AMP exists is because Google needed its own way to control content. That's nonsensical. Why then does Bing use it? > Because you're forced to compete against the behemoth on the behemoth's terms. Why are they forced to use it? I would really like to see your position stated coherently. > AMP's problems are well documented. How do you propose to achieve instant loading web pages, while working around all of iOS's bugs? > It is not like RSS in any way, shape, or form. This just demonstrates that you don't understand AMP, don't understand RSS, or don't understand both. AMP allows the link aggregator to cache and directly serve the article contents, exactly like RSS does.
      - dmitriid 7y ago
        > Your examples predate <Advisory Committee> Advisory Committee has no say in anything that AMP does. Everything is designed and specced inside Google (or Google-dominated work groups) and then vetted by the Technical Steering Committee. Advisory Committee's findings and advise is non-binding: https://github.com/ampproject/meta/pull/37 https://github.com/ampproject/meta/pull/37 And all the WG's are assigned projects that have already been accepted into AMP (such as AMP 4 Email). And yes, my example is important because it was a huge change that no one asked for, but now it's in AMP. As are all the other changes that already hurt the web. > Why are they forced to use it? I would really like to see your position stated coherently. Google has near monopoly on search. In order to compete with it you need to provide nearly all of the same features. > How do you propose to achieve instant loading web pages, while working around all of iOS's bugs? There are no bugs in iOS that preclude instant pages. And the bugs that AMP introduced are, well, the bugs that AMP introduced. AMP broke the behaviour on purpose and refused to implement any suggested fixes. > This just demonstrates that you don't understand AMP, don't understand RSS, or don't understand both. AMP allows the link aggregator to cache and directly serve the article contents, exactly like RSS does. I perfectly understand what AMP and RSS are. You don't understand what either one is. RSS was never about caching or link aggregators. RSS is a web feed. That has a standard XML format and can be read by anyone: a client app on your phone, a client app on your desktop, a link aggregator that can be built by a half-decent engineer in about two evenings. Additionally, it is trivially discoverable by including a standard meta tag on a page. Also, RSS always leads to the original URL. AMP is not a feed. It's a collection of specially constructed HTML pages (which are not valid HTML5, by the way). They are not "instant". They are underperformant by Google's own standards (try running Google's own Lighthouse tools report against one from cold cache). They are only "instant" when significant effort has been spent setting up an AMP cache so that some or all content is already on the client's browser before the client hits the AMP page. They are not discoverable. A meta tag linking to an AMP version will only link one URL, that's it. There is no feed. An AMP cache destroyes the very essence of the web: linking. You will not get the original URL, you will get the cache's URL. Implementing an AMP cache is a significant endeavour, and only a handful exists (as far as I know, there are no opensource AMP caches).