Update (5/2/2019): Added a paragraph to clarify compatibility with other frameworks (to not suggest a zero-sum game), and removed some language on how AMP was misunderstood that wasn’t needed to get the point across.
Read a blog post comparing popular frameworks lately? Participated in a frontend tooling survey? I can almost guarantee that AMP was not on the list. Which strikes me as odd, considering the millions and millions of domains running it. So, how come?
How we got here: HTML vs. JS Frameworks, perception as distribution format, and paired AMP
The first reason why AMP isn’t perceived as a framework is that AMP isn’t a JavaScript framework. It’s a framework written in JS, but the authoring language for you is HTML, so technically it’s an HTML framework. The idea of HTML Frameworks isn’t new but they’re still fairly rare, so they are often not considered a serious alternative.
The second reason is that many compare AMP to RSS, and the media positioned it as competitor to certain other big companies’ walled garden media formats. That narrative certainly didn’t help, and for what it’s worth, we, the AMP team, never loved that comparison (but we also did our part we did confuse people with complicated words such as runtime and AMPHTML format). Web pages are already a great distribution format, and AMP just improves upon it by accelerating delivery via AMP caches and by bundling the main content further, for instance by inlining CSS.
And third, most AMP sites today use Paired AMP, a technique we allow to connect an existing non-AMP webpage to an AMP equivalent. Look, Paired AMP can be useful because the initial investment is much lower: If I packed my bag and later realize I want to pack more stuff, I can just pack another one and travel with two, but it gets really annoying. The same is true for Paired AMP. It’s super hard to maintain both versions over time, and Paired AMP was never meant to be the end state. (That’s why we’re now calling it Transitional mode in AMP for WordPress).
From Accelerated Mobile Pages to AMP
Even our name has been a cause for confusion. I’ve been struggling to properly explain what AMP is for a while now, especially to those who are familiar with its long form: Accelerated Mobile Pages. The reality is that we’ve outlived our own name long ago:
- AMP isn’t just accelerated, it comes with all sorts of built-in UX advantages (e.g. disallowing interstitials, enforcing a free main thread for smooth interactions).
- AMP isn’t just for mobile, it not only works across many device types including Desktop and tablet but comes with super handy responsive design features
- And AMP doesn’t just power pages anymore – you can now build ads, emails and stories with it.
So, what’s the solution? Easy: As announced by AMP’s tech lead Malte at AMP Conf, AMP is now just AMP, and does not stand for Accelerated Mobile Pages anymore (if you must have an expanded form, how about Awesome Magical Power).
From page to site: Going AMP First and using AMP as a service
We, the AMP team, want AMP to become a natural choice for modern web development of content websites, and for you to choose AMP as a framework because it genuinely makes you more productive. This represents our core mission this year, and we’ve rolled out our new site at amp.dev (along with plenty of new content and beginner-friendly courses) to help you do it. So what do you get when you embrace AMP as your development framework (besides the obvious, like speed, UX, easy to use components)?
For starters, you’ll focus more on layout, style and content, and less on boilerplate code. Web development has gotten too hard, and it’s more important than ever to choose the right level of abstraction, with just the right amount of flexibility for your use case. We’ll worry about maintaining the JS for all components, and will ship backward compatible updates every two weeks. We call this way of lowering your maintenance burden “AMP as a Service” (watch Naina’s excellent talk on the topic).
You’ll now only maintain one version of each page by making your AMP canonical, or so-called “AMP first“, and that means your pages benefit from AMP’s performance and UX optimizations across Desktop, mobile and beyond.
Bento: Mix and match AMP components on non-AMP pages, interop with other frameworks
AMP First doesn’t mean that strictly all pages of your site must be AMP – sometimes you might want maximum flexibility and distribution is not a big concern, like with a member-only area or complex shopping cart. In that case you could use vanilla JavaScript or another framework to power that part of the experience.
To then make it possible to re-use existing templates you’ve built with AMP components, we’re working on what we call Bento AMP, the ability to use AMP components in an “un-managed” way, without loading AMP’s main JS file (v0.js), and coexisting with other web components and frameworks on the same page.
This, along with frameworks like Next.js adding support to server side render AMP and amp-script, the ability to run custom JavaScript in a web worker, means AMP and other frameworks can co-exist peacefully and can make each other stronger, which we’re really excited about.
Accelerated development with support for JS and running AMP components outside AMP
Of course, it might not make sense for you to drop everything and reimplement your site in AMP today, and that’s OK! I just want you to know that we’ve grown up quite a bit, and when you set out to redesign or create something new, AMP is here to help you succeed.
With the dynamic state binding capabilities of amp-bind, the dynamic data fetching of amp-list and the ability to use custom JavaScript via amp-script, the possibilities for content sites are now endless. And with new open project governance in place, the future of AMP is open for everyone to shape – everyone who wants the web to continue to flourish.
Posted by Paul Bakaus, Developer Avocado, AMP