From the AMP HTML readme on GitHub:
AMP HTML is a way to build web pages for static content that render with reliable, fast performance. It is our attempt at fixing what many perceive as painfully slow page load times – especially when reading content on the mobile web.
I have written in the past about web rendering, and techniques I've experimented with, but as time goes on, thoughts crystalize and it is worth an ongoing discussion. AMP (Accelerated Mobile Pages) is essentially a set of constraints designed to make websites render faster and ensure they can be sanely cached by interested parties. The protocol subject to the politics, commercial interests and technical complications that are unavoidable, so I have conflicting ideas and general uncertainty about the future. AMP HTML gives applications a realistic way to cache and serve content with great immediacy and I think that is fascinating. Google is the driver, but I would love to see Twitter serve outbound links this way. That would really improve the experience for clicking through to outbound links on the Twitter app, while still giving the content creator a lot of agency over the experience. But, like I said, everything about AMP is debatable.
Regardless of AMP politics, the general mantra is very sound and more websites should be built in this style. This application you are reading from was built with AMP-esque constraints and I think it is wonderful for the user experience. The site loads extremely quickly, internal navigation within the site is blazingly fast, and nothing takes priority over the content.
The guiding design principle of this application's front end is that everything necessary for the initial render is "inline" and as little computation as possible occurs before the initial experience is rendered. Essentially, that means there is a
The edge caching constraint means that supporting information relevant to the functionality of a page, such as whether you are logged in, are fetched asynchronously. The design, both software architecture and aesthetics, needs to support this constraint, but I think that is a great thing. Well-defined opinions and constraints are the lifeblood of a growing system.
As we move forward, we need to consider the various needs of the application, the needs of the user, opportunities that present themselves, and how we can creatively take advantage of those. As I write this, we have put off the task of making all the pages AMP-compatible because there are no use-cases so compelling that it is worth taking on that ongoing dependency. However, if AMP were to be adopted by Twitter in the manner described above, we would rush to include it.
AMP is on the roadmap either way, but the fact that our basic implementation is 99% compatible already and it would just be a manner of addressing a few particular concerns speaks to the notion that a dependency like AMP is a waste of developer resources if you are not certain about its role in your overall publishing strategy. Any news organization should have integrated AMP long ago because of Google's use of the technology in its mobile news results carousel. I experimented with AMP and wrote about it as soon as I heard about it, but I am glad we did not rush to make it part of our strategy. Time makes us wiser and I am happy to sit on this until the path becomes clear.