4 ms·

The custom elements are handled by the AMP runtime: https://github.com/ampproject/amphtml/blob/master/spec/amp-html-components.md https://github.com/ampproject/

The custom elements are handled by the AMP runtime: https://github.com/ampproject/amphtml/blob/master/spec/amp-html-components.md https://github.com/ampproject/amphtml/blob/master/spec/amp-h...

nailer 11y ago
Answering own question: AMP runtime is a JS library.
- pmlnr 11y ago
  Therefore and AMP page is a mess with NoScript.
  - gregable 11y ago
    Potentially. However, <noscript> tags can be used to deal with some of this. Most web pages probably won't do this though.
  - wanda 11y ago
    AMP is not supposed to necessarily replace existing pages, but can rather be created by publishers as lightweight/performant alternatives for mobile visitors arriving via Google Search. Hence why you can declare <link rel="amphtml" href="/yourampversionofpage" /> in the normal page. Those with JavaScript switched off probably won't be suggested the AMP pages in Google Mobile SERP. So you could serve the JS-optional pages to all clients, progressively enhance for JavaScript users and offer AMP pages to mobile JavaScript users.
  - tripzilch 11y ago
    haha :) I didn't even realize :) I've been running NoScript (in addition to my usual bloat-blockers uBlock and Ghostery) the past two weeks, to determine the trade-off between convenience and CPU/responsiveness on my low-end laptop (so far: so good!). The crazy thing is that the demo-page actually loads quicker with NoScript on. Okay, so I didn't see the images (and because the text was Lorem Ipsum, I didn't realize they were missing), I'm on a high-bandwidth connection so unless the images are secretly huge, the images on their own shouldn't be too much of a factor to account for the difference. So in other words, while AMP may be a useful line in the sand for responsive guidelines versus corporate politics / environment / product managers / etc, it's no replacement for just writing lean and efficient code in the first place (if at all possible). edit: turns out the comparison wasn't entirely fair because obviously I didn't have Google's JS code cached. On the second load there's less of a difference.

The custom elements are handled by the AMP runtime: https://github.com/ampproject/amphtml/blob/master/spec/amp-html-components.md https://github.com/ampproject/amphtml/blob/master/spec/amp-h...

nailer 11y ago

Answering own question: AMP runtime is a JS library.

pmlnr 11y ago
Therefore and AMP page is a mess with NoScript.
- gregable 11y ago
  Potentially. However, <noscript> tags can be used to deal with some of this. Most web pages probably won't do this though.
- wanda 11y ago
  AMP is not supposed to necessarily replace existing pages, but can rather be created by publishers as lightweight/performant alternatives for mobile visitors arriving via Google Search. Hence why you can declare <link rel="amphtml" href="/yourampversionofpage" /> in the normal page. Those with JavaScript switched off probably won't be suggested the AMP pages in Google Mobile SERP. So you could serve the JS-optional pages to all clients, progressively enhance for JavaScript users and offer AMP pages to mobile JavaScript users.
- tripzilch 11y ago
  haha :) I didn't even realize :) I've been running NoScript (in addition to my usual bloat-blockers uBlock and Ghostery) the past two weeks, to determine the trade-off between convenience and CPU/responsiveness on my low-end laptop (so far: so good!). The crazy thing is that the demo-page actually loads quicker with NoScript on. Okay, so I didn't see the images (and because the text was Lorem Ipsum, I didn't realize they were missing), I'm on a high-bandwidth connection so unless the images are secretly huge, the images on their own shouldn't be too much of a factor to account for the difference. So in other words, while AMP may be a useful line in the sand for responsive guidelines versus corporate politics / environment / product managers / etc, it's no replacement for just writing lean and efficient code in the first place (if at all possible). edit: turns out the comparison wasn't entirely fair because obviously I didn't have Google's JS code cached. On the second load there's less of a difference.