4 ms·

The real problem is, no one has proposed an alternative solution that solves the same problems. Either people claim it's not a problem (slow loading mobile site

The real problem is, no one has proposed an alternative solution that solves the same problems. Either people claim it's not a problem (slow loading mobile sites driving people away from the web and onto mobile), or people claim it'll just fix itself because everywhere will just make fast pages if they're incentivized to (penalized SEO, users leaving their sites to use Facebook/Apple News) But that has been tried, and it didn't work, and you had people desperately blocking all JS, or going to native apps. My suggestion is, if you don't want people to use AMP, provide an alternative Web framework that provides similar performance, show in a side-to-side demo you can meet the same performance, take it to the W3C or IETF getting Mozilla to push it. No one on a crappy 3g connection really cares about the nuances of the politics here, they don't care bout Web vs native, they care only that their phone seems slow as molasses. If there is no Web solution, then you're going to see native apps with proprietary formats, in essence, non-standard RSS readers. And honestly, I really don't want to download the WashingtonPost, NYT, or Verge App to read articles less painfully. AMP is just JS using the Web Components spec, and some tools, the purveyors of JS frameworks like Vue, Ember, or various Bootstrap-like templates, could ship their own competing proposal. The way standards used to work on the internet is rough consensus and running code. People would propose multiple specs and implement them, working groups would evaluate the various solutions, and the best proposals would be folded in. Provide some competition for AMP and maybe there will be a different outcome. Google shipped NaCL in Chrome, and Asm.js defeated it. Google shipped SPDY, and it won and became HTTP/2. Less talk and politics, more shipping code.

dmitriid 9y ago
Have you even read the article? The only reason AMP is perceived as better than anything out there is because Google aggressively preloads it. At best it's not better than anything else out there. Solutions to slow loading pages are well known and have nothing to do with AMP or "other web frameworks". Even Google themselves lay out the solutions: https://developers.google.com/speed/docs/insights/rules https://developers.google.com/speed/docs/insights/rules. Nowhere does it say AMP. And if you bothered to read the article, you'd see that Google's own tools consider Google's own AMP to be bad and non-performant. > Less talk and politics, more shipping code. That's exactly how and why we ended up with AMP.
- cromwellian 9y ago
  The article is wrong, as no amount of preloading will make the non-amp Verge fast to load as it runs too much JS to block the initial render. You could provide a mobile framework and tools for publishers that helps sites create pages that render fast by putting them on rails. AMP is that framework, other people could similarly introduce tools to help. Chrome DevTools and Google has long offered the Page Speed tools and others to audit your code for slowness, but curiously, no one seems to use them or care, which is why we ended up with millions of slow ass mobile sites shoehorned with megabytes of JS.
  - fchristant 9y ago
    You're missing the entire point. It is fine to have a framework like AMP that puts up technical constraints leading to a performance-friendly web page. The problem is the cache and specifically the preloading of it. This gives AMP an unfair advantage of multiple seconds over anything else.
    - cromwellian 9y ago
      That's why Redfin (https://redfin.engineering/how-to-fix-googles-amp-without-slowing-it-down-522bc5e1e11d https://redfin.engineering/how-to-fix-googles-amp-without-sl...) pointed out that the Web Packaging spec could fix this. But before you have a general purpose spec that fixes something, you need a specific embodiment that does. asmjs came before WASM. SPDY came before HTTP/2. Flash came before HTML5. I didn't like Flash, but would you have suggested Adobe worked with browser vendors for years to bring the Web up the capabilities needed and never having shipped Flash? Still, even without the AMP-cache, mobile sites were loading way too much JS, even after Google penalized them. The effect of AMP showing how sites could be loaded as fast as native Apple News/Facebook Instant, has finally gotten publishers to strip down their sites. You might not like the way it played out, but the end result is that not only do end users get AMP-cached fast loading, but they also end up download far less data, because the sites themselves have been pared down.
      - 9y ago
ocdtrekkie 9y ago
The problem isn't the code, Ray. The problem is the monopoly forcing people to adopt it. If AMP wasn't a search incentive, nobody would be upset about it. It would just be a trashy thing you can opt into if you want. But by tying AMP to Google's monopoly, all other options to solve this problem became non-viable, because they don't come with Google's search ranking blessing.
- cromwellian 9y ago
  Google shipped NaCL built into their browser and Web store and it didn’t take off. Mozilla shipped a subset of JS just like AMP is a subset of HTML and then they put special accelerated support for it if it validated as asmjs. This won and forced everyone else to adopt it even before it was a standard. Eventually, everyone got together and WASM superceded asmjs. Eventually, something will super-cede AMP, but AMP is the kick-in-the-butt that is needed to get the ball rolling, and like asmjs, it is nothing more than a subset of the standard web and works on all browsers and sites, albeit with different performance characteristics, just like asmjs's introduction.
  - ocdtrekkie 9y ago
    Let me ask you the question I've tried to get the AMP tech lead to answer a couple of times: Why won't Google hand AMP over to the W3C? Bear in mind, in discussions with the AMP tech lead, I've discovered AMP4Email isn't even being approached as a standard. Gmail is implementing it as a proprietary fork of email, and the AMP Project is just deciding whether or not they'll support it directly. It seems to me that Google only submits to the W3C when it needs other browsers to implement something. Whenever Google's monopolies can handle it, they keep it proprietary.
    - cromwellian 9y ago
      I don't know the answer, I'm not involved in those things, as I say in my profile, my opinions are mine. In my opinion, it might be better to do this through the W3C or IETF, but I don't have the context, so that's an ill-informed gut opinion. Perhaps there's a perception that the W3C is premature at this stage, as things are quickly evolving and standards committees usually standardize stuff after there's been some proprietary experience. The W3C might not even be the right venue. For example, changes to JS go through TC'39, whereas changes to protocols go through IETF. Lots of XML/SGTML spec work has been done outside the W3C. I don't feel knowledgeable enough to make an informed comment.

dmitriid 9y ago

Have you even read the article? The only reason AMP is perceived as better than anything out there is because Google aggressively preloads it. At best it's not better than anything else out there. Solutions to slow loading pages are well known and have nothing to do with AMP or "other web frameworks". Even Google themselves lay out the solutions: https://developers.google.com/speed/docs/insights/rules https://developers.google.com/speed/docs/insights/rules. Nowhere does it say AMP. And if you bothered to read the article, you'd see that Google's own tools consider Google's own AMP to be bad and non-performant. > Less talk and politics, more shipping code. That's exactly how and why we ended up with AMP.

cromwellian 9y ago
The article is wrong, as no amount of preloading will make the non-amp Verge fast to load as it runs too much JS to block the initial render. You could provide a mobile framework and tools for publishers that helps sites create pages that render fast by putting them on rails. AMP is that framework, other people could similarly introduce tools to help. Chrome DevTools and Google has long offered the Page Speed tools and others to audit your code for slowness, but curiously, no one seems to use them or care, which is why we ended up with millions of slow ass mobile sites shoehorned with megabytes of JS.
- fchristant 9y ago
  You're missing the entire point. It is fine to have a framework like AMP that puts up technical constraints leading to a performance-friendly web page. The problem is the cache and specifically the preloading of it. This gives AMP an unfair advantage of multiple seconds over anything else.
  - cromwellian 9y ago
    That's why Redfin (https://redfin.engineering/how-to-fix-googles-amp-without-slowing-it-down-522bc5e1e11d https://redfin.engineering/how-to-fix-googles-amp-without-sl...) pointed out that the Web Packaging spec could fix this. But before you have a general purpose spec that fixes something, you need a specific embodiment that does. asmjs came before WASM. SPDY came before HTTP/2. Flash came before HTML5. I didn't like Flash, but would you have suggested Adobe worked with browser vendors for years to bring the Web up the capabilities needed and never having shipped Flash? Still, even without the AMP-cache, mobile sites were loading way too much JS, even after Google penalized them. The effect of AMP showing how sites could be loaded as fast as native Apple News/Facebook Instant, has finally gotten publishers to strip down their sites. You might not like the way it played out, but the end result is that not only do end users get AMP-cached fast loading, but they also end up download far less data, because the sites themselves have been pared down.
    - 9y ago

ocdtrekkie 9y ago

The problem isn't the code, Ray. The problem is the monopoly forcing people to adopt it. If AMP wasn't a search incentive, nobody would be upset about it. It would just be a trashy thing you can opt into if you want. But by tying AMP to Google's monopoly, all other options to solve this problem became non-viable, because they don't come with Google's search ranking blessing.

cromwellian 9y ago
Google shipped NaCL built into their browser and Web store and it didn’t take off. Mozilla shipped a subset of JS just like AMP is a subset of HTML and then they put special accelerated support for it if it validated as asmjs. This won and forced everyone else to adopt it even before it was a standard. Eventually, everyone got together and WASM superceded asmjs. Eventually, something will super-cede AMP, but AMP is the kick-in-the-butt that is needed to get the ball rolling, and like asmjs, it is nothing more than a subset of the standard web and works on all browsers and sites, albeit with different performance characteristics, just like asmjs's introduction.
- ocdtrekkie 9y ago
  Let me ask you the question I've tried to get the AMP tech lead to answer a couple of times: Why won't Google hand AMP over to the W3C? Bear in mind, in discussions with the AMP tech lead, I've discovered AMP4Email isn't even being approached as a standard. Gmail is implementing it as a proprietary fork of email, and the AMP Project is just deciding whether or not they'll support it directly. It seems to me that Google only submits to the W3C when it needs other browsers to implement something. Whenever Google's monopolies can handle it, they keep it proprietary.
  - cromwellian 9y ago
    I don't know the answer, I'm not involved in those things, as I say in my profile, my opinions are mine. In my opinion, it might be better to do this through the W3C or IETF, but I don't have the context, so that's an ill-informed gut opinion. Perhaps there's a perception that the W3C is premature at this stage, as things are quickly evolving and standards committees usually standardize stuff after there's been some proprietary experience. The W3C might not even be the right venue. For example, changes to JS go through TC'39, whereas changes to protocols go through IETF. Lots of XML/SGTML spec work has been done outside the W3C. I don't feel knowledgeable enough to make an informed comment.