In this third post in our series on contributing back lessons learned from AMP to the whole web, we’ll dive into the topic of innovating on the concept of navigation for web content. Additionally, we’re taking a look at how new primitives in the web platform are helping to make AMP simpler and “less of a thing”.
For as long as the web has existed, navigation meant that when the user clicked a link, the browser would paint white, and eventually it would paint the new page and update the URL bar. While this is an amazing model, more sophisticated interaction patterns have emerged on mobile. So far it has only been possible to implement these on the web using complicated “single-page app” patterns that use iframes for third-party content. Iframes are a great asset to the web platform. They enable composability, one of the SLICE special powers of the web. Unfortunately, the composability enabled by iframes inherently results in restrained user experiences. An iframe is like a fixed window: it lets you see into another world, but since it can’t be opened it doesn’t let you cross to the other side. The Chrome team took notice of an early exploration called iframe promotion which was designed to give iframes the ability to be navigated to. After a few rounds of discussion to build on this idea, the Chrome team identified a way to avoid the architectural complexity of a solution based on iframes and proposed a similar approach called Portals which allows for unfettered composability.
We’ve seen a lot of interest about Portals from the web community, if only because they’ll allow for applications with the simplicity and robustness of having single pages per URL with the interaction fidelity of single-page apps.
With Portals we hope to be able to implement experiences like Google’s Top Stories carousel without having to rely on application layer solutions like AMP. Beyond that there are a lot of exciting use cases for Portals such as payment or single-sign-on solutions that are visually integrated into a website, but when activated show the user the true origin they are interacting with such as their payment provider.
Putting all the things we introduced in this and previous posts together, one cool side-effect of the web platform getting more powerful is that we are getting ready to make large chunk of AMP literally go away and be replaced by simple platform primitives.
One example that is within arm’s reach is the removal of
amp-img as a web component. With lazy loading, priority hints, and intrinsic sizing being implemented in browsers, it is possible to see a future in which there is no longer a need for the custom component–and while it’ll stick around for backward compatibility, it makes us incredibly happy to make AMP less complicated and instead focus even more on providing high level components in an easy to use framework, as opposed to the platform magic on top to make it all work.
A lot of progress has been made over the last year in advancing web standards along various dimensions. Above we highlighted the areas that the AMP team together with our friends from Chrome and Igalia have invested the most time on, but we also want to recognize that lots of other folks in the entire web community are doing awesome work on web standards which are helping make the web better every day. The AMP team is learning a lot from the web community and is currently most excited about isInputPending, display locking, and Animation Worklet.
Concrete proposals for privacy-preserving instant loading, innovative navigation, performance assessment, and development guardrails are now on the table and in varying stages of implementation. We hope that these projects are a step in the right direction to help all web developers create more delightful experiences regardless of implementation choices. We are eager to hear your feedback and can’t wait for the progress that will be made in the next year!
Posted by Malte Ubl, Member of the AMP Technical Steering Committee, Software Engineer at Google