Why did I write this book? Back in 2006, I was working with a company called dotMobi. I had the wonderful opportunity of working with some super-smart people--Ronan Cremin, Jo Rabin, and James Pearce--who were trying to make the mobile web happen (every year, according to James, was going to be the year of the mobile web, until 2008, when it eventually was).
One of the things that the team at dotMobi was doing was working with the W3C to help draft the Mobile Web Best Practices (MWBPs). We had already built the mobiReady mobile web checker, and the W3C was building its own Mobile Web Best Practices checker that, with my experiences with mobiReady under my belt, I was able to help out with. It was around this time, too, that we launched mobiForge; this was an educational site for web developers getting into mobile web development.
The point of all these initiatives? To give web developers and site owners the tools and knowledge they needed to build sites that performed acceptably under the constraints of the devices and cell networks of the day. This was 10 years ago, pre-iPhone, and the challenges for mobile web developers were considerable. Slow devices, slow networks, and small screens were the order of the day.
When the AMP project was launched, the similarities with the W3C MWBPs struck a chord with me. For one thing, the general goal was the same: follow good development practices, make the mobile web faster, and deliver a better user experience. However, even more than this, the AMP restrictions echoed very much the MWBPs, and the rules we'd built into mobiReady, even if some of the exact details had changed during the intervening 10 years. These were things like not using JavaScript, limiting the number of external resources and HTTP requests, and keeping the page size down. I could be talking about AMP, or the MWBPs.
So, AMP was a project I could identify with, even if some parts of it (such as the AMP cache URLs) are controversial, and I embraced what--as Alex Russell described it at the first AMP conference--has become "the most successful component library in the world." I understand the criticisms of the project, but coming from a background where web performance and user experience goals are important, I believe that, right now, the benefits outweigh the drawbacks.
Even without the cache, AMP is a fast, easy-to-use, and versatile component library. I hope that this book will help you see it the way I do.
