
CPP: A Standardized Alternative to AMP - Yennick
https://timkadlec.com/2016/02/a-standardized-alternative-to-amp/
======
xd1936
This was first published last February, and the top comment was from a Googler
who's involved with the AMP project:

> Love this. Not sure by coincidence, but the AMP team has been playing around
> with the same thing under literally the same name. We should meet up some
> time and discuss details. Not sure it would be an alternative, but rather a
> complementary thing.

I wonder what ever came of that.

~~~
cbr
The spec has been moving along:
[http://wicg.github.io/ContentPerformancePolicy/](http://wicg.github.io/ContentPerformancePolicy/)

~~~
yoavweiss_
The spec has been split into smaller pieces. The first one that made the most
progress is [https://wicg.github.io/feature-
policy/](https://wicg.github.io/feature-policy/)

------
fefe23
I can't take AMP seriously as long as it forces web sites to include resources
from Google.

That basically turns all AMP web pages into something that Google can track.
Google can track enough of the web already, thankyouverymuch.

If your "standard" proposal starts with telling me I have to include content
from a specific URL, you already lost me as a potential proponent.

I also happen to disagree with "all CSS needs to be inline".

Unless I missed something, CPP appears to not require me to include some 3rd
party content, so I'm on board already :-)

~~~
acqq
Aren't the AMP pages anyway delivered from the Google servers to the users?
Then Google can track them anyway?

I'm just a casual observer and that's just how I understood the idea.

~~~
mcbits
AMP pages are served from the publisher's server as usual, but Google can
easily direct their users to their cache instead of the official site. Every
AMP page also includes JavaScript hosted by Google, so Google gets pinged
every time someone visits an AMP page, even if it wasn't through their cache.

~~~
acqq
[https://developers.google.com/amp/cache/](https://developers.google.com/amp/cache/)

"Google products, including Google Search, serve valid AMP documents and their
resources from the cache to provide a fast user experience across the mobile
web."

So it's Google who does deliver from the cache. Moreover, they motivate others
to do the same on the same page.

~~~
mcbits
Yes, Google can direct its own users to the cache, and others can also link to
the cache. But if you or someone else link directly to the page, it is not
served from Google's cache. Google would not be able to track those visits
except for the fact that the page also loads content (at the very least, the
AMP JavaScript) from Google's servers. AFAIK, it is not considered "valid" if
you serve the JavaScript yourself.

------
Longhanks
Isn't there a better alternative to an abbreviation that's already widely used
in the software engineering context?

~~~
deno
Search engines already deal just fine with context. Just type in “cpp
language” or “cpp html,” respectively.

I think everyone keeps making name collisions to be a much bigger deal than
they are in reality.

~~~
maccard
If it was a minor collision, sure. But CPP is one of the most used programming
languages on the planet. I suppose you think we should create standards for
C++ and call them JS or RB or py, for short?

~~~
deno
If you can always find what you’re looking for for any non-trivial (2 keywords
or more) search terms, how is it _not_ a minor collision? “CPP” is not even
the name of the language—it’s the file extension.

EDIT: Mostly I’m just annoyed that those useless off-topics about naming keep
crowding out actual discussion.

~~~
jstanley
But CPP _is_ the name of the language!

[https://en.wikipedia.org/wiki/C_preprocessor](https://en.wikipedia.org/wiki/C_preprocessor)

~~~
deno
You are contradicted by literally the first sentence in that article.

------
throwaway2016a
This is very interesting and I don't want to detract from that .

However, pointing out that for a (large?) portion of us, CPP means "C Plus
Plus" so I was confused for a few seconds.

~~~
happyslobro
Welcome to the world of "$lang-lang" queries. Go, Rust, please make room.

~~~
aviraldg
You would then need to disambiguate between "clang" the compiler and "c-lang"
the language.

------
pcwalton
I'm much happier to see this. My concern with AMP has always been that it
removes incentives for browsers to get faster, because if most of the content
is using AMP there's no point in optimizing important things. Having a multi-
vendor solution gives us non-Chrome browser vendors a voice at the table.

(To give a concrete example, why bother with optimizing layout-affecting
animations to run off the main thread if AMP just forbids them? Such
animations are _useful_ , precisely because they affect layout; we aren't
doing Web authors any favors by forbidding them instead of just making them
fast.)

~~~
hilop
AMP is for news pages, stuff is one page away from Search. Browsers still work
to optimize the overall experience for web apps and full sites.

~~~
pcwalton
1\. Animations have their place on news sites.

2\. I'm not just talking about animations: things like parallel layout are
also useful for static sites.

------
dorianm
The proposal:
[http://yoavweiss.github.io/ContentPerformancePolicy/](http://yoavweiss.github.io/ContentPerformancePolicy/)

------
pjmlp
Just use pure HTML/CSS and the web sites will fly by comparison.

~~~
onion2k
For a single page load, sure. For subsequent page loads you're loading a lot
more than necessary (a JS app can fetch just the content that's changed, and
without a blank page in between), so a pure HTML and CSS solution is a great
deal slower.

Plus, if you users have unreliable internet connections then a JS app can use
a service worker to cache the entire app to work offline, and only load in new
content when possible. An HTML page doesn't work at all in those
circumstances.

Sometimes JS does actually make a site better. It's not _always_ unnecessary
bloat.

~~~
sanbor
There is a thing in HTML5 called Subresource Integrity
([https://developer.mozilla.org/en-
US/docs/Web/Security/Subres...](https://developer.mozilla.org/en-
US/docs/Web/Security/Subresource_Integrity)).

It looks like this:

    
    
      <script src="https://example.com/example-framework.js"
      integrity="sha384-oqVuAfXRKap...."
      crossorigin="anonymous"></script>
    

I wonder if browsers could keep a cache with those hashes as keys and whenever
the integrity hash has a match, then it can take the JS from the cache. That
would save huge amounts of bandwidth and pages would be so much faster to
load.

Probably right now we're fetching the same version of jquery hundred of times
from 20 different domains a day.

~~~
sangnoir
> There is a thing in HTML5 called Subresource Integrity

It piqued my interest, but I was disappointed to discover that it's only
supported by Gecko & Blink[1] - not supported by Safari or IE/Edge. Javascript
is currently unavoidable for offline apps.

1\.
[http://caniuse.com/#search=integrity](http://caniuse.com/#search=integrity)

~~~
robin_reala
It’s a progressive enhancement. Browsers that don’t understand the integrity
attribute will just load the JS regardless, but at least Firefox and Chrome
will get a safer experience.

------
djsumdog
Someone posted this in a reply the other day and I feel it should go here as
well:

[https://vimeo.com/147806338](https://vimeo.com/147806338)

It's a pretty interesting talk. Just thinking about this kind of stuff can
make way skinnier web pages than AMP. I mean really, if we designed pages for
56k modems, the web would be much much fast on mobile.

~~~
honkhonkpants
I would just about give my left arm for a consistent 56k mobile connection.

------
msorvig
Mildly interesting: CPP AMP is already a thing:
[https://msdn.microsoft.com/en-
us/library/hh265137.aspx](https://msdn.microsoft.com/en-
us/library/hh265137.aspx)

------
jasonhansel
I think the real concern about AMP is not that it's nonstandard, but that
Google's caching mechanism reduces publishers' control over how their content
is presented and keeps users on Google's domain. This is a problem for
publishers, but I assume it increases performance (perhaps because Google
prefetches the page while the user is looking at search results?).

------
mxuribe
I agree with the premise that the amp framework (or any such framework) should
be separate from being forced to work with only a specific set of tools, etc.
However, it seems to me that what the author is proposing is really just
more/better adherence to html/web specs...no? Or perhaps, a few performance-
related tweaks to existing html/web specs...I mean, if we all (that is web
producers, website managers, content authors, etc.) simply produce sites that
adhere more to already established web standards (a la html5, xhtml, etc.),
AND have browser makers be more strict in their interpretations of the
established html/web specs, then we'd be almost all the way there...no? I'm by
no means stating that this is easy, just stating that the author might be re-
inventing a wheel that simply could use some optimization.

~~~
noir_lord
> However, it seems to me that what the author is proposing is really just
> more/better adherence to html/web specs...no?

Pretty much but buzzwords/PR work, "CPP Compliant" vs "We build stuff properly
(for a given value of properly)"

~~~
deno
No, there are terrible antipatterns that browsers enable to not break
compatibility. A strict performance sensitive mode for web platform
(HTML/CSS/JS) is long overdue. AMP is a pretty great solution, and the only
issue with it has been the proprietary feeling. The browser support is the
cherry on top.

The argument that people will just use best practices out of sheer goodwill or
even just basic competence has been thoroughly debunked. No one optimizes for
performance if they are not penalized.

------
eganist
COP? Content Optimization Policy?

That's the quickest alternative I can think of to CPP, though I'd be fine with
CPP in any case.

------
krakmh
No alternative can take part of AMP, now it become standard and there are
hundred of scripts and plugin available for it. I am using WordPress plugins
[https://talktopoint.com/wordpress-amp-and-instant-
articles/](https://talktopoint.com/wordpress-amp-and-instant-articles/) and
they are just working fines. What is need of this new alternative and why
should I use it?

------
pmlnr
We already have a standardized alternative to AMP; it's called HTML.

Just cut the crap.

------
irq-1
Shouldn't this be a white-list? If we restrict the features allowed we won't
run into all the same security and performance issues we have with the web.

(also, we could call it HTML Light, or htmll)

------
theandrewbailey
> No synchronous external scripts nor blocking external stylesheets

I know we have:

<script type="text/javascript" src="script.js" async></script>

but for stylesheets, why can't we have something similar? Instead of a JS
workaround, can't we have:

<link rel="stylesheet" href="sheet.css" async/>

I hate hate HATE the idea of having css dependent on some JS (even if enabled)
that might or might not run depending on what feels like working today.

~~~
wanda
In the future, (i.e. only Chrome support this) you will be able to do this:

    
    
        <link rel="preload" href="/assets/stylesheet.css" as="style" onload="this.rel='stylesheet';">
    

which will more or less be async CSS. You can see that it will download in the
background and morph into a stylesheet when it's ready, while the document
continues to be parsed below it.

Then it will just be a matter of including this for people with JS switched
off:

    
    
        <noscript>
          <link rel="stylesheet" href="/assets/stylesheet.css">    
        </noscript>
    

And then for browsers which have JS enabled but don't support the resource
hint 'preload', you could do something like this as a fallback:

    
    
        window.addEventListener(  'load', function sweepUnloadedPreloads() {
          
          window.removeEventListener( 'load', sweepUnloadedPreloads, false );
    
          [].slice.call( document.querySelectorAll( '[rel=preload]' ) )
            .forEach( function( item ) {
              
              // simply doing this might work:
              item.rel='stylesheet';
              
              /** OR, if that doesn't work (I haven't tested it)**/
              var new_link = document.createElement( 'link' );
              new_link.rel = 'stylesheet';
              new_link.href = item.href;
              document.head.appendChild( new_link );
            });
    
        }, false );
    

The sketchy hypothetical fallback technique above, or any JavaScript CSS
loader, could be augmented by using prefetch to attempt to get the tyres warm
and start a low-priority download of the stylesheets in question.

    
    
        <link rel="prefetch" href="/assets/stylesheet.css">
    

And obviously there's Service Worker, which is also slim on support, but
promises to turn your website into a near-native experience by providing the
mother of all caches for resources and offline pages/resources.

Preload spec: [https://www.w3.org/TR/preload/](https://www.w3.org/TR/preload/)

Preload support: [http://caniuse.com/#feat=link-rel-
preload](http://caniuse.com/#feat=link-rel-preload)

 _You could also just put the link element(s) specifying your stylesheet(s) in
the body to 'async' it — Stripe does this on stripe.com. It's not valid HTML
but very few browsers seem to give a damn._

------
nailer
> It’s also the only JavaScript allowed: author-written scripts, as well as
> third party scripts, are not valid.

Minor nitpick: they're allowable in iframes. I.e. sandboxed.

------
ephimetheus
[http://xkcd.com/927](http://xkcd.com/927) comes to mind

