Re: An interesting take on AMP versus PWP

Further elaboration of Baldur’s position:

https://www.baldurbjarnason.com/notes/some-notes-on-security/


From: Nick Ruffilo <nickruffilo@gmail.com<mailto:nickruffilo@gmail.com>>
Date: Wednesday, March 30, 2016 at 10:44 AM
To: Bill Kasdorf <bkasdorf@apexcovantage.com<mailto:bkasdorf@apexcovantage.com>>
Cc: Alan Stearns <stearns@adobe.com<mailto:stearns@adobe.com>>, "public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>" <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Subject: Re: An interesting take on AMP versus PWP

I realize that AMP might simply be a 3-letter acronym that people just nod their head to - so hopefully I can explain a bit more about what AMP is.

AMP has the outward goal of creating extremely high-performance content (little/no javascript, low filesize) that can be delivered quickly.  While there are some political issues around why they do this - the goal of an AMP page is to deliver a snippet of content extremely quickly to a user from a search on a device that has low-connectivity extremely quickly.

AMP does that VERY well - at the cost of doing anything else.  It's goal is to strip content down to content itself - removing most of the chrome/navigation/interaction of a website to deliver content to mobile devices quickly - especially in low-connectivity situations.

The following article talks about some of the good/bads of AMP. http://www.wired.com/2016/02/googles-amp-speeding-web-changing-works/


-Nick

On Wed, Mar 30, 2016 at 10:04 AM, Bill Kasdorf <bkasdorf@apexcovantage.com<mailto:bkasdorf@apexcovantage.com>> wrote:
This is also an example of the common confusion between "document" and "publication." Simply recognizing the issues around a "publication" as distinct from a simple "document" immediately reveals that AMP and PWP are apples and banquets. ;) AMP is basically a profile of HTML, mainly a subsetting. I don't see any reason why a content document in a PWP couldn't conform to AMP and thereby load and render faster. There is no conflict here, imo.—Bill Kasdorf

From: Nick Ruffilo [mailto:nickruffilo@gmail.com<mailto:nickruffilo@gmail.com>]
Sent: Tuesday, March 29, 2016 8:57 PM
To: Alan Stearns
Cc: public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>
Subject: Re: An interesting take on AMP versus PWP

I think it's worth noting that AMP could be considered a portable document format for sorts but by NO MEANS is it a complete or fully functional document that we hope to scope out with PWP.

It would be interesting for us to look at how AMP solves a few issues - but I really don't think it answers much - it just limits functionality to ensure high-performance (speed).

There are some interesting overviews and resources on AMP (https://www.ampproject.org/) but I personally disagree very strongly with Baldur's last paragraph (which sadly seems to be a theme - i like most of what Baldur says and then in his last paragraph he jumps the shark in a way that leaves me blinking...)

-Nick

On Tue, Mar 29, 2016 at 6:39 PM, Alan Stearns <stearns@adobe.com<mailto:stearns@adobe.com>> wrote:
I don’t know enough about AMP to evaluate this, but thought I should pass it on.

Thanks,

Alan

(an attempt to quote twitter in email)

https://twitter.com/fakebaldur/status/714941460416741376



Baldur Bjarnason
‏@fakebaldur

> An interesting side-effect of AMP's basic model is
> that anybody can run an AMP CDN and, because behaviour
> is well-defined, customise it
>
> If you have an app/platform & would like to control
> the performance or representation of AMP pages linked
> from it, you could do your own CDN
>
> That includes anything from aggressively pre-loading
> linked AMP pages to tweaking how its custom elements
> behave.
>
> By sub-setting HTML and limiting JS behaviour to a
> strictly defined set of custom elements, Google has
> effectively created portable web docs
>
> Which basically makes most of what the W3C's Digital
> Publishing Interest Group is working on, a modern
> XHTML2 to Google AMP's HTML5



--
- Nick Ruffilo
@NickRuffilo
Aer.io<http://Aer.io> an INGRAMcompany




--
- Nick Ruffilo
@NickRuffilo
Aer.io<http://Aer.io> an INGRAM company