 If you've seen a talk at Chrome Dev Summit, you already know that much of the web is too slow, too heavy, and inefficient, making sites hard to use for people on slower connections or lower-powered devices. Your site may work great on your $1,000 phone in your major metropolis, but someone in a rural area or another country may find your site frustrating or simply unusable. What if you could keep your sites look and feel while making it accessible to everyone? What if you could make your site more elegant, leaner, and more maintainable with less code? This is why AMP was created to make it simple for all developers to create fast, lean sites for all users. So what is AMP? First, fundamentally, AMP is a web components library. Working on all major browsers, it provides new HTML tags that do the work you'd normally do with JavaScript. AMP is also a set of guidelines on how to create fast sites for everyone. It requires HTML attributes that enable accessibility. It stops you from including too much CSS, and JavaScript can only be used in contexts where it can't harm the user experience. Sites that follow the rules of AMP get a bonus. Caches like Google's store AMP pages so that they can be loaded from search in less than a second, even on 3G. While it's most known for pure content sites, AMP also provides tools to create interactivity. We'll talk about two ways to do this. The old way, which we'll call AMP Classic, and AMP Script, which we'll just call, well, AMP Script. We could also call them JavaScript Lite and JavaScript Pro. So first, AMP Classic. For this, we'll use some examples from our AMP Camp demo site and some that aren't. Let's say that when a user taps this button, we want to open a menu. For this, we use AMP Events and Actions. AMP processes browser events into AMP events and exposes those to you, the developer. For example, when a user clicks a mouse or taps a touchscreen, AMP fires an event called Tap. AMP Actions allow you to change things on your page. For example, to show a DOM element, we'd use an action called Show. To toggle its visibility, we'd use an action called Toggle. And that's how we open the menu. Notice the form here, on equals tap sidebar toggle. Tap is the event. Sidebar is the ID of the element we're acting on. And toggle is the action. Next, how about server calls? When a user visits our site, we want to call an API to find out how many items are in their cart and then show this on the screen. For this, we use two components that work well together. AMP List and AMP Mustache. AMP List sends an XHR request to an endpoint. The data returned gets formatted through a Mustache template. Here's how this works on AMP Camp. On page load, AMP List calls the endpoint specified in the source attribute. Our API returns JSON that contains the number of items in the user's cart. AMP then plugs that JSON into this Mustache template. If there's a count, that gets displayed in a span. If the count is zero, we display nothing. Simple. Finally, to change what's on the screen in response to user actions, AMP lets you store application data in HTML state variables and bind expressions to DOM elements. Here's a simple example. We start with a state variable called team that contains an object with one property, star, whose value is initialized to Yao Meng. Now, here's a p tag with something unusual, an attribute called text and brackets. These brackets let AMP know this is a bound attribute. We've bound this to the expression team.star plus is tall. When that expression's value changes, so will the content of the p tag. Now, remember actions and events? Here, we're saying that when this button is tapped, go into our team state variable and change the value of star to Yao Meng and Mandarin. And here's the results. You tap this button, and the text on the screen changes. Now, let's put all this together. We can use data binding to change an API endpoint. On our site's product listing page, our user can filter and sort results. Each time they make a selection, we call our API to retrieve the appropriate JSON. When the user makes a new selection under sort by, AMP fires an event called change. Then we store their selection in the filter property of a state variable called products. Meanwhile, we've bound the source property of this amp list to an expression that calculates the query string for the API. So when the user makes a selection, the products object changes, and the expression is recomputed, which then triggers a new server call. And presto, new products appear. You might be excited to try out these techniques, or you might just be saying, why can't I just use JavaScript? The AMP team loves JavaScript too, but part of the promise of AMP is that JavaScript isn't allowed to block the main thread and slow things down for the user. Fortunately, now there's a solution. You may have heard talk about workerized JavaScript. It's the new hotness. The nice thing is JavaScript in a web worker runs in a separate thread, so it doesn't block the main thread or user interactions. The problem is, workers can't access the DOM, so how can a worker control web interactions? AMP Script provides a clever solution. It maintains a copy of the DOM in the worker itself. When something changes in the real DOM, AMP Script changes the copy in its virtual DOM and vice versa. This makes workerized JavaScript easy. To preserve AMP's performance guarantee, scripts can only run after a user interaction, not on page load. And your code can't exceed 150K. AMP Script is pretty exciting, but it's so new that at the time I'm making this video, we haven't yet had time to include it in our AMP Camp site. Hopefully, by the time you see this, we will. I urge you to try these techniques. If you don't like them, by all means, create your interactive site in another way. You don't have to use AMP. But I will say, it's still hard and rare for non-AMP sites to be as fast and lean as AMP sites. It takes effort and discipline. And especially on larger teams, it's simply hard to avoid excessive JS and CSS. AMP can be your product manager, your scrum master, urging you onward. So why not give this a try? Check the links in the video description for more information and for documentation, as well as for links to the AMP Camp demo site and the AMP Camp code on GitHub. Thanks for watching, and see you next time.