Live data from Hacker News

CPP: A Standardized Alternative to AMP

timkadlec.com

61–70 of 97 posts

Re: CPP: A Standardized Alternative to AMP

#61

> No synchronous external scripts nor blocking external stylesheets I know we have: but for stylesheets, why can't we have something similar? Instead of a JS workaround, can't we have: 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.

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

    
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:

    
          
    
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.

    
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/

Preload support: 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.

Re: CPP: A Standardized Alternative to AMP

#63

Earlier quoted context omitted.

From back when LAMP (Linux being the L) was the buzz.

oh LAMP .. and if you were enterprise, it was SOA (Service Orientated Architecture) and today it's Microservices. So buzzy.

LAMP and SOA don't really have much to do with each other.

Re: CPP: A Standardized Alternative to AMP

#64

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

PPC is pay per click, which is more likely to create confusion in a web dev context. PCP is less widely used in a software engineering and web developer context (one hopes anyway), but probably not something you want to be searching for from a work computer. If we could get away from policies though, Performant Content Contracts doesn't overlap with much that is CS related.

PCP is also Performance Co-Pilot, a relatively widely-used systems performance tool. :)

Re: CPP: A Standardized Alternative to AMP

#67
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.)

Re: CPP: A Standardized Alternative to AMP

#68

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.

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

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

Re: CPP: A Standardized Alternative to AMP

#69

Earlier quoted context omitted.

Browser option to make hyperlinks clickable when rendering text files? Or client-side browser rendering of text-based markdown.

Having browsers intelligently render `text/markdown` sounds like a great idea. And while we're waiting on the browser implementation, maybe we can find some sort of temporary workaround to send a markdown parser to the client?

Maybe we could just send the raw markdown anyway - it might not be pretty on all clients, but it should be _legible_ on all clients.

Or maybe we could send markdown if the user agent included text/markdown in the request's Accept header, and pipe it through a markdown->HTML filter otherwise.

I would love to see some kind of native markdown support on the web.

Re: CPP: A Standardized Alternative to AMP

#70
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 :-)

Post reply on HN