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>
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]
> *Sent:* Tuesday, March 29, 2016 8:57 PM
> *To:* Alan Stearns
> *Cc:* 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> 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 an *INGRAM* company
>
>
>



-- 
- Nick Ruffilo
@NickRuffilo
Aer.io an *INGRAM* company