Amphtml: AMP components as standalone web components?

[triblondon]

I like a lot of the things AMP is trying to achieve, but I fear that in aiming high and wanting to get there quickly it may be too aggressively pushing publishers to create separately maintained, siloed versions of their web applications. It is, today, essentially a non-starter to build a major news website that is AMP compliant (I work directly for an organisation that runs such a site and have experience working with three others). But still, there are behaviours in AMP that we would dearly love to use.

A prime example is amp-img. I'm facing the need to fork my rendering process at a high level into a path that uses amp-img for image elements, and one that uses a script-enhanced <picture> with lazy loading powered by a library like lazySizes. Essentially I'm using two libraries that do exactly the same thing because I'm operating in two environments (AMP and non-AMP) and there is no solution that is acceptable in both. I don't know which of the libraries is better but I believe that AMP components are well designed and it would be great if there were more situations in which they would work.

It would therefore be extremely helpful to developers to be able to progressively adopt AMP, rather than be faced with an all-or-nothing choice. Even though this would still most likely mean two public versions of each document, we can at least share far more of the component parts, getting a lot of value from AMP components even when the page as a whole is not compliant.

Other advantages of this might include the ability for the AMP project team to gather useful metrics on what the key pain points are where developers are unable to fully comply with AMP by default, and feed this back into improving AMP - the end result being more cases where sites can simply be all-AMP compliant.

I appreciate that this is rather large in scope for a Github issue and hope this is the right forum. I was prompted to post here by Ade over on Twitter.

[jaygray0919]

Very thoughtful @triblondon . We have a challenge similar to your <img> example; ours is handling remote data sources. We can start with amp-list and amp-mustache, but need more powerful features medium-term if we are going to commit to AMP. The Github ampproject is remarkable open and transparent, and specialized threads provide valuable hints and solutions. If we had better information about a Project Plan - e.g. when larger issues about libraries for processing remote data will be handled - we could 'hold-our-breath' until then.

It's easy to criticize on these forums, and we do not want to be labeled as flamers. However, somehow, the remarkably capable folks guiding AMP could help content developers like us (we're not a news organization) determine when/how to deprecate existing library investment in favor of planed AMP libraries.

[adewale]

@jaygray0919 the roadmap is available here: https://amphtml.wordpress.com/2016/05/31/introducing-the-amp-roadmap/

If there are other features you want then the best approach is to file separate feature requests for each one.

[cramforce]

It would definitely be nice to use parts of AMP outside of AMP (and you sure can, we can't stop anyone at all), but doing it well is actually very hard to impossible right now. It might seem to work, but a single document.body.classList.add('foo') can break it.

amp-img is a good example. It is essentially impossible to make a generic implementation in browsers that do not implement IntersectionObserver (and it remains to be seen whether it would actually be efficient in browsers that do), because whether an element should be loaded depends on its position on the page and it is extremely expensive to calculate that if one has to (as one generically does) assume that everything could be different all the time – which requires remeasuring all the time.

AMP, by controlling when things change (it doesn't control when changes are made, but it knows about them), can do many things with basic arithmetic that require expensive layouts in the generic case. By the way: The most useful thing in AMP to use outside of it is amp-analytics. It does have the same IntersectionObserver issue, but might be worth abstracting away for the win of more efficient multi-vendor analytics.

AMP has the explicit goal of working in all current browsers. Only being efficient in Chrome (and in this case soon Firefox) is not an option. The more generic problem we are trying to solve is the "coordination problem", though. Don't want to get too deep, but the web has a great composition story (iframes, web components, yaihh), but a terrible coordination story. Every single composed element can mess things up. This is the real problem we are trying to address and coordination, for now, requires supervision by the AMP core framework.

Back to amp-img: This really should be a platform feature. Microsoft tried standardizing the lazyload attribute years ago but did not get anywhere. Similarly is is extremely hard to emulate layout=responsive without a CSS kung fu black belt. This really needs to be fixed in the platform and the AMP team will help drive these things, so AMP no longer needs to do them.

Finally, yep AMP is all-or-nothing. I know it is hard. On the other hand: All these sites could have been fast for years – the tech was there, but chose not to. The AMP validator brings a clear path in that direction. It seems to be working. This is incompatible with progressive adaptation of AMP. It is a trade off, but a good one for now.

Speaking of progressive adaption. The method that we are working on is to use AMP as a content format for PWAs. That way users who do not have the app installed get a fast version, and then AMP installs it. The PWA can then load the AMP file when it intercepts the network request and progressively enhance it when displayed in the PWA context. This story isn't done yet, but we are actively working on it.

Speaking of plans and stories. As @adewale points out we did publish a roadmap. This is basically a human friendly summary of the github issues. I'd not interpret it as some master plan. Everybody can influence AMP by filing a feature request or sending a pull request. The team that works full time on AMP really just wants to make the AMP users have an easier time building the documents they want to build. We really, really appreciate all the feedback we can get, because that is the only way how we can get better.

[triblondon]

Thanks for the detailed response. It is a neat idea to serve article pages using AMP and then add script on the front end to enhance if in an app context, but that's quite a specific architectural opinion, and may not suit the design goals of many sites. For those where it does, it does sound like a great solution.

My own approach will be to use AMP as a benchmark for good performance, and build our own versions of AMP components that we can use in our architecture. That does also mean that like many other publishers we will have an AMP version and a non-AMP version of every page.

As you say, sites have been able to use technologies for some time that could deliver better performance and the frustration of browser vendors when developers continue to churn out underperforming UX is understandable. Those of us that want to do better appreciate having a gold standard to compare against, and appreciate even more having tools or components that we can apply within our own products without having to fork. Hopefully we'll get there soon.

[ericlindley-g]

Closing this issue, as I think the main question here is addressed. But please feel free to re-open it or start another if there are any outstanding issues or feature requests to tackle. Thanks!