Many web developers had been dreaming about including JavaScript in AMP pages as the natural form of AMP bans JavaScript. Now it looks like their dream has come true.
In this episode of the award-winning Here’s Why digital marketing video series, Ben Morss joins Eric Enge to explain why Google now allows third-party JavaScript in AMP and the work behind it.
Don’t miss a single episode of Here’s Why. Click the subscribe button below to be notified via email each time a new video is published.
Resources
- The glory of amp-script: Unleashing the kraken (AMP Conf ’19)
- What’s new in JavaScript (Google I/O ’19)
- See all of our Here’s Why Videos | Subscribe to our YouTube Channel
Transcript
Eric: Hey, everybody. Eric Enge here. I’m pleased to tell you today that I’m joined by Ben Morss, a Developer Advocate in the AMP and PWA and other things involved in making the web wonderful and fast at Google. Thanks for joining us, Ben.
Ben: Thanks for having me.
Eric: Absolutely. So, it’s really interesting. For a while now – I think it started in 2018 – Google has been talking a little bit about allowing JavaScript more broadly in AMP, while the natural form of AMP bans JavaScript other than the provided libraries. But now the door seems to have opened to allowing third-party JavaScript to be coded in there. I think you expanded the conversations about this at the AMP conference in April and then more in Google I/O. But what’s going on with JavaScript and AMP?
Ben: It’s quite a change for AMP. When AMP was first made, it didn’t allow JavaScript at all except for its own JavaScript which kind of runs the page. I remember there was a slide I’ve seen where people had a little JS symbol and a line and a circle through it. This was controversial because developers love JavaScript because it gives them control over the page. But it was thought, and still is by performance experts around the world, that JavaScript is one of the prime causes of slowness on the web. JavaScript is often used more than necessary; often a lot more than necessary because it’s just easier to keep it than to get rid of it, especially if you have a CMS that adds its own JavaScript over the plugin that you use. In many ways, JavaScript has been a very big source of slowness that isn’t necessary, so AMP didn’t allow it.
Controversial. AMP began then allowing it in very small ways with a component called AMP Bind that allows you to use a little bit of JavaScript expressions but in quotation marks inside HTML elements. So, AMP could control how the expressions were used. It was used in a very small way, which was helpful and allowed people to make e-commerce experiences, other interactive experiences that were more elaborate. But it wasn’t really JavaScript. There’s been a fantasy among developers for a long time, for the thing that’s called multi-threaded JavaScript. As you may know, JavaScript in the web runs in a single thread, which means that it’s kind of like it was one person doing everything, each thing one at a time. Each event that happens, each mouse click, each thing that happens in the browser that JavaScript loads and runs all happens one at a time. And if JavaScript is running, it can block other things from happening. When loading up JavaScripts and working on it, maybe it won’t show an image for a while or something. This is a problem.
But there’s been a thing in all major browsers from IE10 and on, and Chrome, Firefox, and Safari from the beginning, that everyone supports now, which is called a web worker. This is a way of using JavaScript in a different “thingy” – if I can use the word “thingy” technically – a “thingy” called a worker where it can run in its own thread, so it could run simultaneously. And JavaScript and the worker cannot block things that happen in the main thread. The advantage of this is that JavaScript won’t slow things down. If you’re loading up images, doing things, and you’re just clicking on things, those things all keep on happening while JavaScript is running elsewhere on your computer, which is kind of neat. So, this has been a fantasy for quite a long time. And finally, people started working on this on the AMP project at Google and created this library that allows you to actually run JavaScript in a web worker that could actually control things on the main page.
Eric: It’s really cool being able to do that because, for a long time, people have wanted to do that. But if I’m not mistaken – maybe I am and this is a question I wanted to ask you – isn’t part of the deal here that JavaScript is typically only allowed after initial page load? Is that right or do I have that wrong?
Ben: It’s also true for AMP script. It waits for the page to load first. But the thing about web worker that was a challenge was that web workers cannot access the DOM; DOM being what’s on the page. They can’t see that, they can’t touch it. So it runs its own little private area and doesn’t know what’s on your page at all. This is, of course, an obstacle. What they did, which was a lot of work and really intriguing, is they made this thing called WorkerDOM. It makes a copy of the DOM and puts that copy in the worker. So then, when things change on your page, the copy is updated. The worker knows what’s going on in the page. The worker changes the page that gets copied into the main page. It’s more elaborate and involves more back and forth, but it means the JavaScript is safe and it preserves AMP’s guarantees of performance.
So, this became something called AMPscript, and is now a component you can use to run JavaScript as much as you want to. There are, as you said, some restrictions to make things fast still. It can’t run on page load, only after the user does something. So the page loads as it usually would. If the user, say, clicks on your mortgage calculator or something else elaborate that involved AMPscript, then it can go ahead and do whatever it wants to after that. And also, to make things not too slow, it must be less than 150k so you can’t have lots and lots of JavaScript still. And certain features don’t work the same way because they’re in a worker, so you have to do some workarounds in some cases. It’s elaborate in some cases. It’s pretty new. There are still bugs being found right now, but people are using it and it’s kind of exciting because it allows you to use JavaScript again.
This is kind of like the new hotness. So I’ve seen people saying, “Ooh, JavaScript in a worker is great but you just can’t really do it right because it can’t access the page.” But now it can so it puts the AMP on the forefront of the greatest and newest things in web performance.
Eric: So that’s really awesome and it allows a lot more capability for your pages that were previously not available with an AMP. So, it’s one of the reasons why people are excited about that. But there’s another new initiative out there called Bento AMP. And as I understand this, this is the idea that you can use just chunks of AMP on your page. You don’t have to convert the hole page to AMP. So maybe you just use a coding practice to speed up one piece of it.
Ben: This is pretty exciting, too. And this generally is part of the effort to make AMP part of the web more. You don’t have to choose to make an AMP page or make a webpage. There are various efforts underway to make it possible to use AMP with the rest of the web just kind of in a seamless way. Another example of this is the effort to give non-AMP pages that are fast the same treatment as AMP pages in search. If this happens, and Bento AMP happens, then AMP becomes less important and best practices become important.
What Bento AMP actually is, is the idea that any AMP component, like an AMP image carousel, a menu, a lightbox, whatever, can be used on non-AMP pages. Actually, it turns out it’s possible right now. Google has done this for years. It seems to work just fine. But it’s not guaranteed to work and the components think they’re on this page that AMP controls. If you have JavaScript that modifies the page in some way, it might confuse the components in some way. So the effort now is to rewrite all of the components so they’re guaranteed to work in any context, an AMP page or a non-AMP page.
Eric: Yeah. That’s very cool because, that way, you can speed up individual elements, as I mentioned earlier. A lot of exciting stuff happening in AMP. I think it’s really important, as you said a few moments ago, it’s not really about AMP or non-AMP. It’s just about making the web a heck of a lot faster.
Ben: That was the idea all along, but the execution was a little complicated. There are efforts now to make that really true. So, the web can be faster and more stable, and everybody will gain from this, we hope.
Eric: Yeah, and it fits into a theme that I’ve been pushing around AMP for a long time. If you’re looking for a way to speed up your webpage, why not use an industry standardized way for doing that. And that’s a cool thing. But some people have some philosophical objections about AMP being this other thing, and now it’s just kind of a part of the way you can go about it, and that’s very, very good.
Ben: It’s understandable. I think that, in my experience, it’s very hard to maintain performance without using AMP. But if you can do it, then you should do it. And why should Google or someone else care how you do it as long as you make your page better for users?
Eric: Super. Well, thanks for joining us, Ben. Appreciate it.
Ben: Thanks for having me. It’s a pleasure.
About Ben Morss
Ben is a Developer Advocate at Google, where he’s working to help the Web be faster and more beautiful. Prior to Google, he worked at the New York Times and AOL, and before that he was a full-time musician. He earned a BA in Computer Science at Harvard and a PhD in Music at the University of California. Rumor is that he still runs a band called Ancient Babies.
Don’t miss a single episode of Here’s Why. Click the subscribe button below to be notified via email each time a new video is published.
See all of our Here’s Why Videos | Subscribe to our YouTube Channel
