things like that. And then last one, something to consider is that if you already have a user's information and you already have a credit card on file or some way to pay, I wouldn't expect you to use, don't think you have to use payment requests. Like, give the user the best experience they can, and that means go ahead and just leveraging what you already have on file. But if you don't have anything and you don't have the credit card or the credit card expired and you need a new one, consider payment requests as a tool to help these users. We talked about sign up first, right? But that might not always make sense for your business. If you think about it, maybe your P0, your most important thing, is getting a user through that checkout flow. Then you can request an email address from payment requests. And now all you need from them at the end of that funnel to optimize the experience for next time is a password. And so consider leveraging this. Again, these are tools to help you be successful. So just a quick status update. So we are live in Chrome as of M53. So we've only been live for about eight weeks now. And it's sort of a quiet launch. We had a great set of early launch partners that we worked very closely with. And they integrated and tested and gave us a lot of great feedback. Again, the API is still early. Chrome is the first browser to implement. And so we're really thankful to all of these players for their great feedback. And from it, we're actually making a lot of changes and improvements and enhancements to the underlying experience. And so I just want to talk a little bit about what you can expect to come soon. So the first one that we're working really hard on is support for third party payment apps.  In India, you have Paytm and Snapdeal and all these other new emerging wallets. If you go to Holland, you have Ideal. If you go into other countries, whole new forms of payment that are not just credit cards and Android pay. And we want to be able to support all of this in a nice open way where we can support users from all over the globe no matter what. And so we're really close to finalizing this. And we hope to have support next year. Secondly, we have a lot of spec and feature enhancements coming. So we have the shipping address types I talked about.   So we added OCR scanning just recently. So you can now just like scan if you don't have a credit card, you can just scan it directly into the UI. So there's things to make it faster, easier, and fundamentally better onboarding flows. And then just quick timelines here just so you're aware. We're sort of targeting M56. That's our January release. It's like our next big major release. It's going to have all these enhancements, all these improvements. And we're really excited about it. You'll continue to get updates along the way. This is all live in Chrome stable. And we'd love to continue to work with you and get your feedback. Everything I talked about today is available online in a lot more detail. We have integration guides, a bunch of examples in sample code. Ooh, the phone's come up. And then we also have a gain start with Android Pay. Android Pay is really simple with payment requests. It's like less than 10 lines. We do almost all the heavy lifting for you. So just a quick shout out there. But I'll be around for the rest of the day. I would love to chat with you, learn about your challenges, things that you think you need from the browser, ways that we can help you be successful, especially in checkout. So thank you so much. Talk more. I love that. That is so exciting. This is a game changer. Brilliant stuff. Now it is time for lunch. It is indeed. Now you've got options. You can either stay here, or if you go around the corner to the Grove and show your badge. You can't have this one. It's mine. But if you show yours, then you get a free lunch. So you've got choices there. And if you want to take the shuttle bus to the other location, the Google Developers Launchpad, you can do that. And there'll be lunch there as well. So you have tons of options. We will be back. Well, if you opted in for particular dietary restrictions like a special meal, that is going to be available downstairs in the corner behind the bar over there as well. We have pushed back this afternoon's session. So we're going to be back here at 2 o'clock for Paul Irish. And more big web quiz. Oh, yes. See you then. Take it out. The last session is the Leadership Panel, where we'll have all people sort of like new various VPs and product managers and engineering managers going to be up here answering your questions. If you want to get any of your questions in early, if you ask them in the Slack channel, which an URL is on your badges. So you can have a look at that. But should we do some big web quizzing? Yes. And I think before we get to it, we should have a look at the leaderboard. We need the screen up first. So that would be, ah, here we go. Let's have a look at the leaderboard. Let's see who's leading the pack. Here we go. OK. Uh-huh. Ooh. Ooh, we're tied in first. Look at that. Would you believe it? Oh, hey. Some people have a bit longer names than you catered for in the layout. Not everyone's called Paul. Yeah, well, they should be. All right. You can see I've poached there. It's a Mozilla DevRel beating any of Chrome DevRel. I really like Mohamed's avatar. That's really cool, because that's like a ho-ho. It's not like a Batman mask, but with even glasses on. Even better Batman. That's amazing. Right. Well, we want to see a, oh. We want to spread that out.  We need to, let's have a question. We should also point out that there's someone, the first place is actually shared with another individual who's not opted into leaderboard, but they should feel very proud of themselves. They should. And don't forget, if you do want to be on the leaderboard, then you do need to check that box at the bottom that says, appear on leaderboard. So shall we do a question? Yes. Right. I think you want to read this one out. I am. Which of the following CSS properties triggers layout or reflow when changed? Backface visibility, outline, opacity, or background image. Select all that apply. Yes. Let's have a look at what chances are coming through. Oh, there's a lot of confidence in one of them there. Yes. 100% of people. That's interesting, isn't it? Look at that. One of them is just fluttering around the 20% mark, the pink one there. Very useful, which one that is. Invinced, apart from that one. Let's close the question in three, two. Confident on width. Not so confident. I'm pretty sure opacity doesn't in decision around outline. Yeah, does it? That's not surprising, is it? Because it's painty, but it doesn't actually change the size of the element itself. Let's have a look at the answers at some point. Here we go. Just width. Just width. Most of them will cause a paint or a re-raster, but it won't actually involve changing the dimensions of an element. Therefore, it doesn't trigger layout or reflow. I guess that's right. All of them will cause a re-raster. Outline during an animation won't. No, I said I meant opacity. I was going to say, I thought you knew something. It begins with an L as well. Yeah, it's fine. It's very confusing. Yes, width is the only one that triggers layout. Right. So this next question I would like to do is about the next speaker. It is, really. So it's not scored. Oh, yes. This is one that's just going to be for fun. Because we don't know how much we expect people to know this one. No. It's very interesting. And I think so. Here it is. It activates. Come on, Wi-Fi. You can do it. Don't film me now. Paul, can you? There we go. Of the many Pauls working on Chrome, which is actually Irish. Is it Paul Kinlan? Paul Lewis? Paul Backhouse? Or Paul Irish? Oh, hopefully us. Here we go. Oh, well, there's a pretty confident one of them. That is interesting. No one's really sure on this one. No, you're looking down that list going, really, they all might be one of my knobby. This is a select multiple one as well. So you are welcome to pick. Constructor Paul Egon. It's fine. Interesting. So what are you saying? Probably a low chance for the German Paul to also be Irish. OK. That seems relatively fair. Paul Kinlan, though, leading the charge there at 57%. Interesting. Shall we show them who it is? The correct answer is, of course. Yes, it's true. I actually am Irish, which means I have the great pleasure of being Irish Paul, introducing the non-Irish Paul Irish. And at this point, I have to confess, we've now had to start calling him Paul Lyrish. Ladies and gentlemen, give him a round of applause. Paul Lyrish. Like a little, not much, more than that. OK. We good? Yeah. So today, I want to talk about debugging the web. And really, this is about I want to share with you some of the work that we've been doing in the Chrome Developer Tools. We've been working hard on a lot of stuff. And I want to share with you today. And just to step back for a moment, I just want to point out that really our goal here with the Chrome DevTools is that we want to maximize your productivity as a developer. We want to make sure that you are as effective at developing experiences for the web as you want to be. And not just that. I think we all enjoy web development because we get to craft the experience that users consume. And we get to bring them joy. And we want, on the DevTools team, to make sure that you have that joy, too. So we want to maximize your delight as a developer.  So we're going to go through a few things from debugging and authoring, progressive web apps, and then some auditing stuff. And we've got a lot to get through, so let's get right into it. Debugging. I'm talking about JavaScript debugging. And so JavaScript debugging is how we understand the execution flow of our code. And it's how we remove all the bugs that we added to our code by accident. So it's a really important thing. And we spent a lot of time doing it. So we want to make sure that it's good. Let's start out small. This is the call stack. It's the humble call stack. This is what it looked like about six months ago. And we spent so much time here that we want to make sure that it's as good as possible. So we've done a little bit of UI refresh here. On the right-hand side is new call stack.  The asynchronous hops are a little bit more obvious. The where execution sits is very clear. And up at the top, of course, you'll see exactly why you're paused. And this is called out very clearly, because sometimes you're not really sure. Also, sometimes you just pause on a breakpoint. It's kind of clear. But other times, you're paused on an exception. So it tells you exactly what the exception message is right up there at the top so you don't have to go and figure out and open up the console. Or you're in a promise rejection. You're on an XHR breakpoint, a DOM breakpoint. Whatever the reason, we want to make sure it's very clear to you on why you're sitting there paused on execution. So some changes there. But also on the call stack are some other things. Now here, I have the DevTools fairly. Let me bring that back. It's good? It's great. The DevTools, in this case, are pretty big. It's not all the time that we have the DevTools maximized on the screen. And sometimes it's all over there, squished to the window, but we still want to be effective. So this is what the call stack looked like a while ago. As you kind of reduce the size of the call stack, everything gets shrinked down. My function names, I can't even read them anymore. So navigating between the call frames when I'm debugging is kind of rough. We decided we could make this a little bit better. So this is the experience now. So just as you have less screen real estate, we go in. We kind of stack the function name in the location. And when we run out of space, we just elide the location and take the text away from that. So making sure that whatever the screen orientation, and we're always changing it, it's going to be readable and usable for you. So again, these are small changes, but important. Now a lot of us are authoring not just in kind of plain old JavaScript, but we're using JavaScript Next, ES6, ES2016, whatever. And we might be using tools like Babel or TypeScript to transpile them down to code that can be deployed across a variety of runtimes. And I just want to point out that the DevTools works great with all these new language features. In fact, we use them ourselves. This is the DevTools inspecting the DevTools. I'm using the black DevTools to view the other one. And this is just some of our code and some of our layer profiler. We use a lot of these new language features ourselves in our JavaScript.  There's promises and error functions, template literals, the new array methods, good stuff. And this allows us to make sure that the experience of working with these new language features, whether it's debugging or in the console, is great for everyone who uses them. So the console itself is actually a really nice thing. So if you're using Babel or something to transpile, you're like, what exactly is happening here? Just come on over to the console and try it out in place here. Works great with all the new features and constant Lent. Here in the screenshot, we can see using the async await. This stuff is great. You can toss in a little debugger statement right there and understand exactly how it's moving. This is a lot of fun. So while we're talking about the console, let's spend a little bit more time here and talk about the console read line. Now the console read line is, how did I do this? Yeah, I don't know. Okay, coming on over here. So opening it up, DevTools on my favorite site, example.com, it's a good one. The console read line is this thing here that we type on. And so usually we type things that are just like fairly, like just one liners, but not all the time. Sometimes you actually want to have a few more than just one line that you want to type out. And this has been kind of a pain before. You have to hold like shift enter to avoid. To write in new lines, it's been kind of tough. So I'm gonna write out just top of a function. And as I hit enter now, we just immediately say, oh, actually, I don't think you're done here.  In fact, Safari kind of paved the way on this one. They had this feature and we really like it. It's fantastic. So now let me just finish the rest of this guy. I'm just gonna log out my args. I hit enter again. We still know that we're not done yet. I had a brace and it's like, oh yeah, I'll reinvent that for you back there. And I'll hit enter again. And it's like, yeah, you're done. We'll execute that, cool. So yeah, so as I had that too, you'll see that we are matching the braces too. So very clear brace matching. And in fact, this is now syntax highlighted, whereas that is pretty new. Even things like multiple cursors and select next match, all these features that you and these keyboard shortcuts that you use in sublime text or whatever, they also work here too. So some nice upgrades to the console read line. Now the other thing is that we use the console as a way to inspect objects and kind of understand what's going on with them. So actually having the completions as we type and explore things is really important.  So as I open up the square bracket, I do actually see immediately all the indices that I can use in child nodes. So I know that there's 11 child nodes and that's kind of cool. I'm gonna choose one. And one pain point that's happened in the console before is that any time that you have an array and you grab something from the array and then you hit dot, I might not see any, I can't, what is there? And I want those completions and it didn't work. Anyways, it works now. So we're all happy. So in addition to that, you kind of want a little bit more power and you've only been able to see what starts with what you typed. And so now if I wanna see what the content is of this child node, I might type content and then, oh, text content. Yeah, actually that's the text content. So substring completions work now too. In fact, the substring completions work not just here but also in elements panel. So in case you forget something like border color, you can type color and you'll eventually see where it is. All right, so some nice improvements there on the console. Again, small things, but nice. All right, sometimes you're writing some code and to be honest, like three lines of code isn't cutting it. You want a little bit more room and you could go over to something like JS bin and that's great for sharing but sometimes you just wanna play around. The snippets inside of sources, it's just kind of a place where you can noodle around, try out a few lines of code, put break points, try things out, execute it. These are persisted into your Chrome profile. In this case, I was just playing with the battery API seeing how much battery I was discharging and how much time is left, it's cool stuff.  All right, now one more thing to kind of finish up debugging. Yeah, so this line of code that we're looking at here, asynchronous code, we got promises and some thens. This is actually a really tough thing to debug currently. In fact, if I place this break point here on line 16, I pause like before any of this, but there's really no way for me to like pause inside of my error functions and see like what's happening inside of them. And if I try and pause here, because this has changed, it just doesn't work, and that's not great. We wanna make sure that debugging asynchronous code is as easy as debugging synchronous code. So we've been working on this and thinking that there must be kind of a better way. So let's see, I'm gonna open up a snippet that I have here. And yeah, yeah, okay, this is good. So we've been thinking about this and working, let me bring that back, yeah, there we go. Working with the V8 team to see if we can improve this experience. So what I have here is some code and we are going to ask the GitHub API for some data. We're gonna fetch it and then turn it into JSON and then get some stuff and hopefully log it out. And let me just try this real quick. Okay, well, it looks like there's a problem. Okay, yep, great, problems are good. Now before, it's been pretty hard to understand what's going on because again, I could only pause in the very first line of this. But so now what I wanna do is I'm gonna place a breakpoint here. In addition to that, we've also found all the candidates along that line of code where you can place inline breakpoints. All right, yeah, nice. So now that we have that, let's see. I'm gonna run this again. So what just happened is I ran it again. Right now we're paused right here at this first guy but I'll let that continue. All right, now, cool. We're paused halfway down the line right after JSON. Now I do see that this response up here is there. Forbidden, that's gonna be fun to figure out. And I even see the return value, this promise. This is actually the return value of this call right here. Now I think I can go for, yeah, okay, yeah, go for it again. And well, to be honest, it looks like data here is coming back. So problem with this demo is that I'm hitting the GitHub API and turns out that for whatever reason, RIP in this building has already exceeded its rate limit. We're like, kind of breaks the demo. So thanks for the people that are using the GitHub API unauthenticated right now. Luckily, I have a backup piece of JSON. This is what the payload was. That's just sitting there. So let me just, you know. There you go. There you go. There you go. There you go. There you go. There you go. There you go. There you go. Okay. How are we looking? Let's clear off these guys. Uno momento. Okay, okay, great. So run that again. I do have a problem and we can inspect exactly what is going on. I kind of think I know we go forward. It was asking for data avatar. Doesn't exist avatar URL. Yeah, that makes sense. Let me finish this off so that we don't have to worry about it anymore. And uno momento. All right, there we go. Avatar URL. Enter. Really? What did I do? No. Guys. I really, there we go. Yeah. So yeah, console image. A little known thing, you know, just tosses an image into your console. Why not? Okay, to be honest, the implementation is down here and it's cool. Stop. Yeah. Anyways, in line break points, I'm really excited about this, really introducing a much better development experience for asynchronous code and all sorts of code. It doesn't really break anywhere you need to. All right, moving on to authoring. And we're gonna start with the front end and I'm gonna head back into the browser. Over here, we have a PWA that me and Sam Sikoni have worked on. It's called CalTrain schedule. As you can imagine, it shows the schedule for the CalTrain. And now we've been developing this and there's always times when you wanna make changes. Now, a typical way of making changes, like we can try out some new colors. And if we like them, you know, usually the method is shift selection and copy paste over in your editor. Now, we don't really like this workflow and we think it can be better. And in previous talks, you might have heard us talk about features like workspaces. And workspaces allows you to bind your local development folder with the actual site that you're looking at in the browser, allowing you to save to disk the things that you're working on.  If you've tried it, like, you know, it's kind of like, is it working? I don't know. So we wanted to make sure it's really straightforward and simple. So I'm gonna come back over to sources and clear this out of the way. And so in sources, we see, okay, yeah, this is the code. I have a service worker here and some JavaScript and CSS, right? But I want to be able to persist the disk. So the new experience now is a lot easier. So I'm gonna take actually just my development folder. This is my CalTrain schedule folder locally. Just gonna drag and drop it here and say, yeah, you can access that. And then immediately you see a little, like, green checkmarks light up. And it says, oh yeah, the CSS of the file? Yeah, that's, I know where that is. That's right on disk. And over here, I'm gonna show you on the file system. Here's the entire folder, like my editor config and things, my service worker. But everything that is coming in from the network has a little checkmark to it. So this is a nice thing because we automatically find out for you how things map. In fact, it's not just the basics, but if you have a more complex setup, like you're transpiling your JavaScript or you're compiling SAS to CSS, that should work too without configuration. So we've, like, I could explain how we, you know, made it, to be honest, I don't. It's like magic. So things like, you know, this TypeScript, we were able to map it back and forth. As long as you have a source map for the actual compiled code, we will figure out where it goes and map it so that any changes you make persist. So let's make a changer. So this title could afford to be bigger. That's nice. It's a little too strong. I'm gonna change the foreground color a little bit, dial it back, get in the gray. That's good. Need some shadow. I'm gonna use the new shadow editor. Little too black, but if we lay it up. Ooh, that is some classy stuff. Yeah, I'm liking that. Now, one thing that you might see right here, this green check, it knows that this CSS is actually the one on disk. And if I click through to view it back in sources, we have the diff saying, oh yeah, I know, you actually changed these lines right here. And if I come back over to see my editor, or my terminal, and I just check my diff, oh yeah, that's the diff with the changes that I made. So automatically persist the diff. Cool, so that CSS is looking good, but I'm actually talking about CSS. So the original styles of this site, Sam actually was like pretty responsible for it, but I don't even know if we were like, there's like a lot of styles here and I don't even know if we're using all of them. I imagine that we've all been in this situation.  I'm not gonna try and remove them, because that's crazy, but I would like to know. This is hard. The browser kind of knows, right? We're like, maybe we should, hmm. So actually, yeah, as of today in a canary near you, you might find this little checkbox up here called CSS coverage. Now I'm gonna try it out and just hit record, and in fact, that's it, it's kind of done. I'm gonna head back to sources, and now in the CSS, we mark on the left-hand side if these styles were never used. Yeah, so actually, this is pretty good. Down here at the bottom looks like there's all this animation stuff that wasn't used, and I just wanna verify that this is good. The animation is like, actually these little bars that animate out. Looks like there's just two here. I wonder if I can, yeah, I'll try and trigger all of them. Ta-ta-ta, let's just switch this over there. Yeah, that's a few animations. And come back, and yeah, okay. So we are using all those, not that, but yeah, CSS is looking pretty good. So excited about this, because it gives us much better tools to understand, like what of the code that we're shipping are we actually using? Yeah, some good stuff. Okay, okay, coming back. Now, talked about authoring in the browser. A lot of us are full-sac developers. We write JavaScript for the backend too. And at Google I.O., we showed some work that we've been doing to bring profiling and inspection and debugging to Node.js. We've been excited about this, but there's always more work to do. So let's show a little bit of that. So coming back to this Caltrain schedule, I've actually been working on a small little feature to get the live position of every single train. There's an API for it, and I could get the live location. So you can see down here at the bottom of my JavaScript is I'm asking my local server for the position of a train, and I'm just polling for it. I've just started the feature. I'm very early on this one. Okay, so let's kick off the Node, right? So we'll come over here, this guy, and what we can do is we can hit Node-inspect in the app, and whew, ignore that for a moment. We get this URL right here, and this is URL, and we can just actually copy-paste it into our browser and start debugging. But in this case it's kind of awkward because I already have a tab open with DevTools, debugging the front-end, it'd be nice to be able to look at the back-end too. So I'm actually, yeah, just gonna allow this to run, but I'm gonna come back over to the sources panel. And now when I open this up, and it is just the main thread and the service worker down here is Node, and it's like, oh yeah, you're running Node, aren't you? Do you wanna debug that too? Yeah, yeah, actually I'd be done with that. Okay, good. So now we're connected to Node, and I know this because if I switch over here, and I'm looking at just the Node context, that error that I was getting over here is still also exploding my screen over here, so that's great. Okay, train is not defined, apparently. So let's see what's up. All right, so coming down there's my app.js. This is my Node code, and apparently there's an error. Let's just pause on exceptions. It just paused right here. Train is undefined, right, yes, good. And train ID, yes, mistake, by bad. Train ID is just train. Now I'm just gonna hit Control S, and I think that takes care of it, and we'll know if we see sending API request. It's paused, who said that? They get like two extra points in the quiz. Okay, paused. All right, yeah, yeah, good sending API, yes. Okay, and in fact, coming back to my other context, my page, I went from a bunch of, yeah, 500s internal service errors to 200s, and that's what you like to see. Oh, good, okay. So we're really excited about this because this allows us, yeah, sure, yeah. It got a clap on the 200s. We're excited about this because this allows us to use a single DevTools and speak to both the front end and the back end at the same time, keeping your attention in one place while managing multiple contexts. It's just good. All right, moving on. I've heard a bit about progressive web apps today, and there's some nice tools in the DevTools to tackle that. I'm gonna briefly just review some of them. Over in the application panel, there's some great stuff. First up, the manifest view will tell you what's in your manifest, and in fact, if the browser finds anything that's not so sure and it issues a warning or an error, you'll see them shouted out right up here at the top. Then the service worker pane tells you everything. The state allows you to manipulate your service workers, and then I really like this. The clear storage pane allows you to not only unregister your service worker with one click, but take care of your cache storage, your app cache, your any of your local storage. Just wipe it out and kind of start fresh. I use that all the time. I do wanna spend a little bit more time on the service worker panel itself, and there's two things that I wanna point out for you. Really helpful tips when you're doing this debugging. Up at the top are some checkboxes. The checkbox in the middle, update on reload. This is a super helpful guy. You can think of it kind of as like a disabled cache, but for the service worker JavaScript itself, like it's great for when you're working on SW.js, the service worker.js, and you're just making changes to it. You wanna make sure that you load in the new version every time. It'll just make sure that as you reload, it pulls in the new version. You don't have to worry about some of the caching stuff. The other checkbox, bypass for a network, basically says, hey, service worker, you love to intercept requests and serve from the cache and all this stuff, but I'm working on my site right now and I'm updating my styles and my pages JavaScript, and so I really don't wanna like you to be serving things from the cache and intercepting, so it's just like, just chill with the network stuff. So this allows you to just iterate on your pages, content, your styles, and JavaScript without the service worker getting in the way. So definitely check those out. And as you keep on, as you work with these tools and find things that are like, hmm, making your question stuff, feel free to just holler at us and ask us if there's a better way that the tools can represent what's going on because we'd love to make sure we can help. Now, there's a lot of things in doing progressive web apps that you kinda have to keep track of and especially if it's your first time just getting your manifest and your service worker set up the right way is a little tricky. And so we've thought of been working on better ways for us to understand if we're hitting all the right marks and if there's anything else that we can do to make sure that what we're building is great. A lot of that work and that investment has gone into a project called Lighthouse, and Lighthouse is a guidebook for helping you turn a web app into a great progressive web app. And more than that, it analyzes any web page and any website and not only collects performance metrics but helps identify all sorts of developer best practices that you could be doing and making things better. So like as an example, it audits for a number of different things as far as can the user be prompted to add it to home screen? Does it have a custom splash screen? But other things like are you using passive event listeners when you should? Are you avoiding mutation events and document write? And over 40 different audits checking for just developer excellence. On the other side, it also does a great job of having performance metrics that capture kind of the user perceived performance in the most accurate way possible. So you've heard a little bit about first meaningful paint and time to interactive, and Lighthouse measures those and helps illuminate what is actually happening when things are slow. So Lighthouse is available as a Chrome extension. Let's see a little bit over here. See over here, yeah, I can run it from the command line. It'll just kick off a new version of Chrome itself and just run all of its tests, the same tests there. And this works well. Lighthouse is just a node module. And in fact, a number of other tools are already using Lighthouse and building on top of it. So feel free to check it out like that. It works well with a headless Chrome in a continuous integration environment. So if you want to set up progression tests for performance or audits, you can definitely do that. And the other thing is that we've really been happy with how doing these checks to see like this along the right path. This has been working out for us. But we wanna make sure that it's even more available. So I wanna show you another new thing. I'm gonna come over to our Caltrain schedule and I'm here in the DevTools. And we're like, maybe we should have it available not just here as a Chrome extension, but what if, let's open this up more tools and we have a new Audits 2.0. So this Audits 2.0 is powered by Lighthouse. So as I, I'll just make this, yep, there we go. So I'm just gonna go ahead and this is using the same Lighthouse that is in the extension, the command line, running all the same checks. So it's looking for things like usage of document write, usage of blocking style sheets and helping you understand what's going on. So pretty soon it'll give me a report. I'll be able to browse that. And yeah, okay, looks pretty good. Fast, site is fast, good job, Sam, okay. But scrolling down, this was, this is interesting, check this out. Site opens external links using relnope. And in fact, there's, we have two links on the site which are external, open in new window and not using this guy. You'll have to read about this. And this, like, I saw this and I was like, honestly, we really need to do this. So this is super, yeah. So I'm gonna fix that like right after I get off stage. But yeah, I encourage you to check this out. And the nice thing here is that because this is using Lighthouse, Lighthouse is just sitting on GitHub.  So if there's anything that you're interested in auditing for or just wanna check, just please come by, drop by.  So come check it out, talk to us. If you have any ideas, we just love to work on it with you. So what do we see here today? A few things. We walked through looking at stronger debugging with modern JavaScript and I got to show the inline breakpoints. Love it. The parallel debugging with Node.js and the browser at the same time, a single window. The persistence, saving to disk, really painlessly, automagical mapping between everything. The CSS coverage to find what CSS you are not using and new auditing functionality available in all the right places. If you're not, follow us on Twitter, our doctor there, and just, yeah, please grab Canary, turn on some of the DevTools experiments if you want. And if anything, bugs, certainly, but even just feedback or ideas, go to CRbug. It'll be like, do you wanna report a bug? Don't file feature requests, but just ignore that and just file a feature request. It's just like, hey guys, what about, what do you think? That's fine. We'd love to hear from you. That's it for me. Thank you very much. Thank you very much, Paul. I loved the applications tab in DevTools. When I was building the Chrome Dev Summit website, it was the best thing to be like, here are your icons, here's your service worker, here's everything. I'd love that. It's a really good addition. Well, should we press on with the next talk? We absolutely should. Keep up the pace. To talk about web components, the next one. And it's the speaker who, for my money, has the best name anyone in Dev World. Oh, I can't say it. I can't say it. I was Taylor Savage. I really struggled then. Well, how would you say it? Taylor, Savage. You'd go for the movie one. Why not? See, for me, it sounds like a wrestler. Please welcome to the stage, Taylor Savage. All right, thanks, everyone. My name is Taylor Savage. Great intro. Yeah, my name is Taylor Savage. I'm a product manager here on Chrome on the Polymer project. I'm here with Monica, who's an engineer on the Polymer project as well, to tell you all things Polymer. So I'll start off by talking a little bit about where we are with the project overall and how we think that web components are really changing how we do web development. And then Monica will go into some of the more technical details around how to take best advantage of Polymer of web components to build a really great, high-quality, modern, mobile progressive web app. But first off, let's talk about the mobile web. And we've been talking about the mobile web a lot at this conference. It's kind of like the mobile web conference. And there's good reason for that. The mobile web is incredible. There has never been a more important time to have an open, decentralized communication network where anyone in the world can access this information coming from anyone else in the world. And as developers, this is incredibly exciting. You can put something up on the web and a user somewhere halfway across the globe is just a URL away from accessing your application. That's great. But for developers, there's also a dark side to the mobile web. And if you've been doing mobile web development, if you've been really trying to get the best possible user experience across to your users on their mobile devices, you know this dark side, which is that we are at war with phones. Phones are our enemy. They're our user's best friend. But as developers, they are our enemy. And it can feel like as we're trying to produce the best possible user experience, the phones are fighting against us at every possible turn. Mobile networks are vast. There are over 2 billion users with a mobile smartphone in their pocket to access our web applications.  And that's something that we've never had to really deal with as web developers, as developing for the desktop web, where you're plugged into the wall at all times. Mobile devices are everywhere. They're in everyone's pockets. You're a pocket reach away from a great user experience on the mobile web. But that means that mobile phones are fundamentally performance constrained. They need to have this tiny little battery that can power them all day long. And they need for when you take them out of your pocket for them to not burn your hand. And that means that to power, for the battery to last all day, to power the sensors and the radios and not to mention this high-resolution screen, it's going to be very constrained in the terms of the power that it can actually deliver to the CPUs that are doing your math for you that are running your application. And we've got a lot of tools available to us, a lot of open source tools available to us as web developers to allow us to create these web applications. Then these tools are incredibly diverse and incredibly powerful. But it can seem like more and more of the tools available to us are getting continually bigger and continually more complicated. Building a great mobile web experience is hard. It's a little bit like climbing Mount Everest. It's challenging. It's expensive. To really do it right, you need kind of a lot of training and a lot of good guidance.  It should be much easier to deliver experiences on the web to users, especially in this important mobile context. But there's good news. We have a mantra on the Polymer Project. We have kind of a philosophy about how we think we should be building web applications, how we should be thinking about as we're constructing these new mobile web applications to make our lives easier and to make our user's lives better. And that mantra is to use the platform. The web platform is getting increasingly powerful. With new primitives like Service Worker, like web components, with new serving mechanisms like HTTP2, we have more tools at our disposal as developers than ever that allow us to build and deliver a really high quality web application. And so it's our responsibility now. In fact, it's our advantage to take advantage of what's already there baked into the browser sitting on our user's devices in their pockets in the form of the web platform. So the Polymer Project is the Chrome web platform's team set of libraries and tools for web developers to help developers take full advantage of the modern mobile web platform, to take advantage of what's right there sitting on the browser. Now, the primary feature that Polymer the library has been focused around is web components. And web components is an umbrella term for a set of low-level APIs baked into the web platform, new web platform specs that allow you, the developer, to create reusable, composable components on the web. They create a new component model on the web, allowing you to essentially extend the HTML language to create your own HTML tags that get understood by the browser just like any other baked-in HTML tag. Now, if you've been following web components, they've been around for a little while now. So the first spec came out in 2012, which was a while ago.  We were over-optimistic as to the speed at which web components would become broadly cross-browser supported. But this is OK. We went back to work. We went back to work with all other major browser vendors to work out a new, an updated set of these APIs. The idea was sound, everyone was on board the idea. We just needed to kind of work out the kinks in the APIs themselves. And so I'm very happy to say that as of today, we've turned a major corner with the web components APIs with an updated version of some of these web component specs, Web Components V1. So previously, web component support was scattered and it was varied. Template was supported across the board across all major browsers. But Shadow DOM and custom element support was either behind a flag or unsupported in most browsers. Today, with Web Components V1, as you heard earlier at the keynote, this story is completely changed. So all major browser vendors are on board with shipping Shadow DOM and custom elements V1 versions of the specs. In fact, Safari in Safari 10 that just shipped recently has Shattered on V1 shipped. Chrome has Shattered on V1 shipped. It's on the high priority roadmap of Edge. This is very exciting time for web components. HTML imports are still on hold as we're working out how they're going to interact with ES6 modules. But I'm confident we'll come to a really good solution for how to load HTML with HTML. So I can't say this enough. This is a huge turning point for web components. At Google I.O. earlier this year, I said that cross browser web components was not a matter of if, but a matter of when. And when is right now? Cross browser web components are here with Web Components V1, which brings me to Polymer. So the Polymer library, the library itself that forms the soul of the Polymer project is a lightweight layer on top of these web components APIs. And it's designed as an opinionated way to pull together these different low level specs, these low level APIs, and make it easy to build, for us developers to build a reusable web component, a reusable custom element. Now Polymer started out as an experiment. It has evolved with web components as the web components specs themselves have evolved. So Polymer started out just kind of to test out what would be the different low level features that we would need as a web developer to create this kind of reusable element, to extend HTML. So Polymer 0.5 was the last release of Polymer that was still kind of in this experiment mode. And then after a few years of iteration, after working on the specs, after working on the library, it turned out that these web components things were actually pretty powerful. And so last year, we released the 1.0 version of the Polymer library, which was the production ready version of Polymer. It allowed us as developers to take advantage of web components today in production applications without necessarily the APIs having to yet be shipped broadly across the different browsers. So Polymer has kind of quietly been out for a little over a year. And I think because Polymer started out so much as an experiment with these very early web component specs, we often get the question, who is using Polymer? Is anyone actually using Polymer in the wild? So I want to just name a few of the companies that are using Polymer in production today. So Polymer is used by Comcast, which is the largest media company in the world. It's used by the USA Today, which is the flagship brand of the largest newspaper publisher in the US, GANET. It's used by ING, which is the largest online bank in Europe. It's used by Netaporte, the largest luxury fashion e-commerce company. Polymer is used by BBVA, which is one of the largest banks in Spain and Latin America. By Coca-Cola, which is the largest beverage company in the world. It's used by Electronic Arts, which is one of the largest game publishers in the world. By Predix, which is the software platform for the industrial Internet of Things from General Electric, which is the largest digital industrial company in the world. And of course, Polymer is used here at Google, actually quite heavily here at Google, on some of our biggest user-facing products. So Polymer is used in Chrome in the Chrome UI pages, which has over a billion users. It's used in plain music. It's used in YouTube gaming. And just recently at the Polymer Summit a few weeks ago, we announced that Polymer is actually being used on YouTube. YouTube, which is one of Google's biggest products, also with over a billion users, is now building the next generation of their mobile and desktop applications all on top of Polymer. So there's an immense organizational power that we're seeing to relying on standards. To relying on standards-based web development, you get this seamless frictionless sharing of code that we've never been able to really, truly achieve across all kinds of different teams on the web platform before. And we're seeing more and more large companies going all in with Polymer, with web components, with web standards-based development using the platform. So a big value prop for web components is that they're interoperable. That you can build a component with browser-based technology and then share it to other members on your team, share it with other teams at your company, share it with the overall ecosystem that anyone can take advantage of that component, no matter what kind of stack they're using, no matter what the rest of their JavaScript stack, your JavaScript stack looks like. But this is great, but clearly, we've got big projects working with web components, big teams that wanna not just build components, but wanna build entire applications. So we get the question a lot, how can I take web components and then build an entire application, specifically an entire progressive web application out of web components? And our answer in the past has always been, well, that's the whole point of web components, is there's no one way to build an application. You can choose any of the tools that you're familiar with, anything that you like already, and use that to put together web components into an application. But obviously that is kind of unsatisfying. And what we realized is that if you take web components, which are one new set of web platform primitives, and you combine them with other new, really exciting web platform features like ServiceWorker, like HTTP2, you can actually end up with a whole that's much greater than the sum of these individual parts. And so we wanted to put together kind of an opinionated showcase of how all these different features are really designed to come together and make for a really great user experience. And so earlier this year, we released the Polymer app toolbox. And again, the goal of the Polymer app toolbox was to go beyond just components and show how components can be put together with these other technologies into complete progressive web apps. So the app toolbox includes a set of web components, app level components for things like layout and routing and internationalization. It includes a command line tool, the Polymer command line tool that lets you build and deploy your application. And things built with, applications built with the Polymer app toolbox are designed to be served via what we call the purple pattern, a way of using HTTP2 in server push to being able to deliver just absolutely the minimum of what you need to be able to render each view of your application to your users with minimal overhead. And you'll hear more and more about this purple pattern across various talks at this summit. And then in addition to the components and the pattern and the CLI, we wanted to show what you could actually create when you put all these things together. And so we launched shop.polymerproject.org, which you've also already seen in many of the demos up here, a progressive web app that really is just a killer user experience, it uses the app toolbox, it uses the purple pattern, it uses Polymer web components to deliver an e-commerce-like application. You can visit that at shop.polymerproject.org. And we're already seeing the kind of value of this Polymer app toolbox being used by companies to build applications. So take Jumia Travel, which is the travel division of Africa's largest e-commerce site. Now, 75% of mobile connections in Sub-Saharan Africa are on 2G. And that's forecast to still be 45% in 2020. So there's an immense challenge to be able to deliver a rich full application over the narrowest network you possibly can. And so thanks to the Polymer app toolbox and thanks to web components in the purple pattern, Jumia's progressive web app is able to achieve this. They build a progressive web app on the Polymer app toolbox that has twice as fast a page load on 2G and uses six times less data than their native app to be able to deliver the same exact flow. And I think the quote from the Jumia team really speaks to the value and the power of web components, which is that they were able to build a complete kind of prototype of this website, the entire flow in just four weeks so that they could show it to their management and sell the management that this is a very valuable, compelling experience and then go from there to build the actual production application. So this is exactly what we want web components to allow developers to achieve really rapid prototyping all the way through to production deployment. So we're really starting to feel the momentum of web components. Web components are now being truly broadly adopted cross browser. They're being used in real serious production applications by large companies and here at Google. And this means that it's time to kind of open the next door for the Polymer project. So we're working right now on the next major push of the Polymer library, which is Polymer 2.0. So we just released the preview version of Polymer 2.0, it's up on GitHub. And there are a few key things that we're focused on when we're designing and working on Polymer 2.0. A few key features and distinctions that from the Polymer 1.0 release. So the first obviously is Web Component V1 support. Web Component V1 are the specs that are going to be broadly shipped across browser that we're already seeing out there. And Polymer 2.0 is designed to take advantage of these new custom element and Shadow DOM. V1 APIs baked into the browser. Polymer 2.0 also offers better interoperability with other JavaScript frameworks with other JavaScript tools by eliminating some of the Polymer specific abstractions that kind of leaked through in Polymer 1. Namely the Polymer DOM, Shady DOM APIs and some structured data manipulation that leaked through. So the takeaway is that an element, a custom element built in Polymer 2.0 is truly web native. It will be indistinguishable from any other vanilla Web Component that you might build with any other Web Components framework or just with raw vanilla Web Components. And finally, we don't want to leave Polymer 1.0 users in the dust. One thing that we took away from the Polymer 0.5 to 1.0 transition is that transitioning a major framework, transitioning a major dependency, even if it's small, is a huge pain point, especially for large companies, especially for large projects, especially for teams at Google that are relying really heavily on Polymer. So with Polymer 2.0 from the beginning, we've designed it with backwards compatibility in mind. So Polymer 2.0 comes with a near seamless backwards compatibility layer, making it as simple as possible to be able to transfer a Polymer 1.0 component to work in Polymer 2.0. And Polymer 2.0 also supports what we call hybrid mode. And hybrid mode means that you can, there's a way to write a component such that it can work on Polymer 1.0 or on Polymer 2.0. And so what this allows is, if you've got lots of components in your application, if you've got lots of components shared across your company, you can incrementally upgrade one element at a time while your application is still live in production. And once all of these components are upgraded to this hybrid mode, you can switch over from using Polymer 1.0 to using Polymer 2.0. And then continue to take advantage of the Polymer 2.0 specific features. So it's a much, much easier, much smoother, more seamless upgrade process than having to stop all the presses and upgrade everything at once before you put your application back into production. So Polymer 0.5 was an experiment for web components. Polymer 1.0 was allowing you to use and achieve the promise of web components in production. And with 2.0, we can finally realize the full value of web components, which is going web native, which is actually truly using the platform, using standards-based cross-browser APIs to use the platform to write less code, to ship less code, to write more elegant, smaller applications and deliver them across the mobile web. And we're actually seeing this use the platform mantra bearing out in the numbers with Polymer 2.0 when you take a close look at how Polymer 2.0 actually works and is built. So Polymer 2.0, if you build a web component with Polymer 2.0 and you ship it on a browser that doesn't need any polyfill, so that supports web components V1 out of the box, Polymer itself is only 12 kilobytes. It's small, and it's getting smaller and smaller. And that is our whole goal with Polymer. We're not trying to build a massive framework. We're trying to build a tool that gets smaller and smaller as the platform fills many of the gaps in our developer experience. So this is using the platform in actual service to the Polymer library. We are just at the beginning of the story for web components. And we're still actively figuring out all the kind of best practices and best ways that we as developers, as teams, as an ecosystem, can take advantage of all the things that web components provide. So we've been building web components for a few years on the Polymer team, and we've certainly learned a lot in those few years. And so here to tell you more about how to take advantage of web components in the browser and how to build really killer applications using web components is Monica, an engineer on the Polymer team. Coming up mid-talk means that I didn't get an awesome Paul Lewis introduction, so I'm super bummed about this now. Hi. So the thing about Polymer, the library, is that it's not really about the library itself. It's about what you do with it, and that's building elements. And what I've been thinking about on how to structure this talk, I've realized that when Taylor said that mobile web development is hard, the same thing can be said about element development. It takes a lot of expertise. It's really hard to make a good element that you can put on every page that you have, so I think it's really important to actually talk about it. And what we've been talking a lot about is how to make a good element, that how to make a fast element, and we've given talks about, oh, I'm not allowed to go back. And we've given talks about that, but then I thought about it, and there's three kind of people that actually interact with elements. You've got the people who use their elements, who don't actually want to build a good element. They just want to use other people's elements when they're developing a web app. There's people who author the elements, and we've been talking about them a lot, and there's people who maintain the elements, and these may be the authors, but it may just be other people who've inherited these elements, don't really know the intimate details on how this element came to be the monster that it is. So we need to be able to address their concerns too. So I'm gonna do two different things. I'm gonna talk about the people who use the elements and give you some advice about how you can architect your apps using web components, and how we've built some tools for the people who have to maintain those elements. And on the Polymer Elements team, we have a lot of experience with this. We initially authored over 100 elements. I think it's over like 130 now, which is kind of a lot. We've spread them across three different orgs to make everything actually really complicated and hard to sync and test together. Why not have a little fun while you're at it? We've used them internally, like just in our team on over 20 apps, and this is important to us, like the Shop app, because that's how we come up with advice for other developers. That's how we come up with patterns that you can use. And we're also on the maintaining side of this. Polymer Elements are used in over 500 apps. These are internal to Google. They're external to some of the companies that you heard about before. So we kind of cover all of those three different areas that I talked about. So let's talk about app developers. It's probably half of the audience. You maybe wanna use a web component in your application. How can we make this better for you? What best practices do we have for you? And the best advice that I have is that you should not look at web components as something that they are new. You already know about components. If you've used any language, you've got objects, you've got the ideas of like, compartmentalizing your code, that's not new. And web components themselves aren't actually new either. If you've ever used an input element or a button, they're kind of like a web component. They're a little nugget of functionality and code and styles that have been put together in a little box and given to you, and it has an API, and you know how to use them. You've been doing it for a long time. What's new is that other people can now build these web components that are just as powerful as input and button. They just have different names, and you should treat them basically in the same way that you've been treating input. So, I built this really to demonstrate like the next example. I built this really dumb app for the Polymer Summit. It's basically a emoji social network where it's kind of like Twitter and Slack jammed into one, but instead of being useful, the only thing you can type is English and it gets translated to emoji. So the only thing that you see is like a stream of emoji. And I'm walking around with a beacon now. I've got my first physical web beacon, so if you're like around me, you can actually get a link to it. It's mojibrag.frybase.com. But when I was designing it, I was like, okay, cool, let's say that I've never used a web component before and I want to design an app with them, what do I do? And it's basically the same way that you would use like a normal application. You just think about the features that you have in your application.  And once you figure out these features, you can like go ahead and dig deeper in each of them. Well, when you write a post, you have to somehow translate from English to emoji and then if you've got a list of posts, you can like like them and see their location and all sorts of other stuff like that. But once you have this idea of like what the logical components in your application are, it translates immediately to web components. The authentication part is done with Firebase Auth, which is an element that does authentication with Firebase. IronList is the thing that manages your list of elements. And then new posts in my app are little web components that I built internally to my app just to like logically structure code around. And it was really easy. And the awesome part about components, and this again is not new. It's happened if you've ever written a class before. If you've written a component, you can refactor it really easily because it doesn't affect the rest of the app. It just sort of sat there as a standalone thing and you just get to fix its code. So this shouldn't look scary. It's how you would write web components. You could call it a div class equals main screen, but now you can just say main screen as an element. And because web components aren't new and you've been using them in the browser, you just didn't know that an input was a web component, you should use these new web components that you're getting from users in the same way. And that's by using properties and events. If you look at an input, you set all these properties in it. You said it's type, you said it's value. You said whatever, the min length and max length. When an input does something, it fires an event, it fires an input event, it fires a change event, this isn't new. And this is exactly what people have been doing with their web components. Properties go down, events go up, and you get this magical unidirectional data flow in your application. So if you go back to my application from before, you have this giant screen at the top that knows about the state of the world and you've got your post button where you like mash on your keyboard and emoji comes out. And the app is gonna know things that not every component knows about. For example, it knows what channel you're posting to, so it's going to inform anybody that it cares about by setting a property on those elements. Again, just like you've been doing with input. And when you're done mashing on the keyboard and you have a new post ready, you fire the custom event and be like, hey, I got an emoji post, does anybody care? And if anybody cares, they're gonna intercept that event. And the same can happen if you wanna hide conditionally UI in parts of your application. You just set different properties. What I didn't tell you here is that you should call a public method on this element or something like that, because again, that's not how we've been using DOM elements before. We don't call random functions on input. We just set properties, which leads me to my third device. Use properties and non-message. You might be tempted to use methods because JavaScript is really keen on having methods, but that's not how the DOM really likes to be used. The DOM has properties and attributes. And this is really great if you're using properties because then you can just use them imperatively and you can have data bindings and stuff like that. So imagine you have a dialogue, you could call dialogue.open on it, but you don't need to. If it's got a property, you can just say, hey dialogue, dialogue.open equals true. And once you've done this, you can just do it as a binding somewhere in your code and it depends on like some other state of the world. And without writing any JavaScript, like things will open and things will hide as they should because that's how properties work.  Those are your rules. So that's the advice that I have for app developers. But what do we do about element maintainers? You're like this poor sucker that has inherited like 17 elements that somebody else wrote left the company and you don't actually know why they're in that state. And this happens whether you're maintaining elements externally like we do for like the rest of the world or internally, like a lot of companies do, they just have an internal set of elements, but they still have to maintain them. So we've been writing tools and the biggest advice that I have is you keep hearing about like test driven development, that's great, but I think you should practice fear driven development. And that's not being afraid of the code or anything like that. It's really just being afraid of your users and that's a healthy approach to development. Because most importantly, you should be afraid of like breaking them and breaking their applications. That's like your one responsibility as a maintainer. Don't break other people's code. So in preventing breaking changes, we've been using this tool internally and we're working on like making it, it's a public repo on Polymer Labs and we've been working on fixing it so that you all can use it. And it's called TAD2, which stands for test all the things over and over because why not come up with a complicated acronym if you can. And the idea is really simple.  Look at this dependency graph, which is not a real dependency graph, they're usually way worse than this. But if you modify a leaf at the bottom, unless you have the ability to like hold all the 130 elements in the Polymer Elements catalog in your head, you're probably not gonna know what that change is gonna affect. It could be a behavior, it's maybe like the ability to be included in like a custom form or something like that. You don't actually know how many elements depend on that change, especially since they can go many levels up the tree. So what TAD2 does is it lets you specify a branch or a particular hash or something like that in a particular element and rerun based on that commit a whole suite of elements, a whole suite of tests. So in this case, we make a change to one element and like make sure that all the other tests pass. And this is great because then you have the confidence as a maintainer that like this PR isn't gonna destroy all of YouTube because we've definitely not done that before. The other thing that you should be afraid of is perf regressions. It's really great that now you have the confidence that you're not gonna break somebody's application but making their application slower is kind of slightly worse because that's harder to fix. And we have two tools for that. The first one is Poly Dev, which is a Chrome extension and you can run it on any app that uses custom elements and basically ranks how expensive the elements that it sees on the page are. And it's great if you wanna like audit your page and make sure that as you're contributing to an app, so this is also good for the app developers. As you're like fixing your app, the performance sort of stays as you expect. But it's also really good for maintainers. If you have like a giant catalog that has like different demos for different elements and one of these elements that used to be really cheap after a commit suddenly like spikes to the top, that probably means something bad has happened and you wanna like undo that change. So that's what Poly Dev does for you. It's in the Chrome app store. You can download it, it's awesome. My favorite tool is Poly Perf. And please note how these names have a poly prefix at the end, but tattoo doesn't because poly tattoo is weird. So Poly Perf lets you basically compare the performance between changes. So here, this is an example from Steve Stock from the Polymer Summit where as a baseline, he has an input element and that's not, it doesn't cost you 20 milliseconds to make one input, it costs you 20 milliseconds to make 250 of them on a page.  And the reason why this is good is because you can start doing it for like, again, different commits and different shaws and different features that you're adding to an element and be like, cool, this element used to cost like 129 milliseconds and now it's 500 milliseconds. Is this change really worth it? Which is great for you as a maintainer because then you can go back and be like, no, this changes shit, we're not merging it, it's fine. So that's fear driven development. The sort of parallel and kinder version of development to that is demo driven development. If you think about your users, they don't really, like I personally can't look at a snippet of code and be like, I totally know what that element looks like and how it's gonna fit on my page, that's great. I can only like look at demos and be like, I want it, I want the shiny button. So that's what demo snippet is for. Demo snippet lets you write basically how you would use that element, shows you what the code is and shows you what that element looks like. Here is a whole bunch of paper fab buttons. Fab stands for floating action button, not fabulous, and it took me about a year and a half on the team to find that out and I was super sad. I think fabulous button is a way better name, but nobody listens to me. So that's a demo snippet, it's really great. And we've noticed, we've heard that Comcast, for example, uses this element very aggressively internally to just be like, these are all the elements we have, this is what they look like, do you care? And we've taken this demo approach very aggressively to the new beta site for the webcomponents.org. So beta.webcomponents.org is the new element catalog where we're moving all of our elements too, and it basically supports collections and elements and they're curated collections. You can make a collection called fabulous elements and you can add all sorts of web components to it. So when people search for fabulous elements, they'll get to it. Oh, sorry. But most critically, it supports inline demos. So this is the documentation page for paper fabulous. And here at the bottom, you see a demo. And it's a snippet, but the best thing about the snippet is that it's not static like the demo snippet used to be. It's actually interactive. So here I can change the contents of one of these buttons or I can even add a style because this kind of element advertises a custom property to change its color. So you can go ahead and do that. So what now? We have web components, they're native in the browser. Polymer 2.0 is right around the corner. What does this mean for you as developers? Because this is called Polymer Web Components in U. Let's talk about the U part. There's never been a better time to actually start using web components. So go ahead, just go and use an element. I have a really dumb element called emoji rein that makes it rain emoji in your page. Go ahead and drop it on your blog, why not? Use Polymer. Don't use Polymer. Use vanilla custom elements that you stumble across. Make your own element. And if you do share it, polish it up, submit it to beta.webcomponents.org so that everybody else can look at it and it's going to be really awesome so that their applications can get better. But most importantly, just make things. Use the platform. Use tools that make your life better and make you write less code. And build awesome things for the web, because it's up to you to make the web better. We can just help you along with it. But at the end, you're going to make it awesome. Thank you. Hello. Hello. Can you stand on the other side? No, you go really consistency. Consistency. Continuity error. Shall we do some more quizzing? Oh, yes. Right. If we get the quiz screen up, that would be fantastic. Bones and laptops ready for the big quiz.com? Yeah, come on. Give me that logo. Switches to the editor. Thank you, Miles. Everyone can get logged in. Look at that. That's a black screen. That was a good noise. That was great with that. OK, so we can talk a little bit about the next speaker. So the next speaker is Alex Russell. No. He was working on these slides reasonably late last night. So I'm staying with Alex right now while I'm in San Francisco. And yeah, he's such a nice guy. There's a few people staying with him. And I got up for the bathroom in the middle of the night last night and just sort of opened the door. And I was greeted there with Alex just sat on the landing and he built himself a kind of fort out of cushions working on his salt because every other room in the house was occupied by someone else trying to sleep. He had a little Alex fort. Yes. Into which he was. Until three o'clock in the morning. So yeah, we'll see if his code works any better than ours has. Can't be bad. Should we keep filling? Quiz is not going to work. OK, well. Well, we'll do the next questions after the next talk then. We certainly will. In which case, here to cheer you up. It's Alex Russell. Do we jig now? Like, is there a vamp? I thought this was their job. I'm, it really is. We thought we'd come back and just say, leave no man behind, as it were. You are not working on the quiz right now? No. No, we've quit. The quiz is solid now. No books. Off, off. Oh, your slides are here. OK, fine. Hi, good afternoon. I'm Alex Russell. I'm an engineer on the Chrome team. And to set expectations, this isn't the talk I usually give. So I hope you'll bear with me through some difficult content. These days, I usually put this slide up to start to talk about Progressive Web Apps, which Frances Berman and I named last year. Progressive Web Apps are the culmination of multiple years of my team's work. I've been working with Jake on service workers for like just four years now. And the team that I work on has been designing and building the core technology for Progressive Web Apps. The stuff that you've been hearing about for the last couple of Chrome Dev summits and all day today and probably all day tomorrow. And I apologize a little bit, but not really. But as you can imagine, building and maintaining all that stuff and working on the standards for it is a full-time job. But I'm not going to talk about Progressive Web Apps today, at least not directly. You see, for the past year, I've also been working with Tao and her team to partner with folks who are about to launch their Progressive Web Apps to make sure that they're really high quality. And this sort of incidental consulting work has given me a broad view into the practices of many of the teams that are building for the mobile web today. What I can say with only a few exceptions, exceptions like booking.com and the great work that the FlipPR team did, is that most of us don't really understand how hard mobile actually is. I haven't exactly been making friends in the JavaScript framework community by saying that sort of thing out loud, turns out. But as the Polymer team will tell you, this is basically the PG version of what I've been saying to them for something like a year and a half. We had some really tense meetings. I kept saying things like, it needs to be more asynchronous or, look at this trace, you really need to load a lot less JavaScript than 12k. Sounds good to me, actually. Or you really need to break up your script so you're not executing this entire long block. What the heck is going on here? And at some point, they said, we get it, we get it. Just stop telling us what to do and start telling us what goal to hit. And this was kind of a breakthrough in the conversation and we've been sort of at loggerheads for a while. And so I kind of put my finger in the air and said, it would be really great if you could get me something that's interactive in about three seconds on a 3G connection on first load and interactive in about a second when I launched it from the home screen. So the Polymers went off and they went through the stages of grief. We had some denial. I'll admit, there was some denial. Anger, yes, bargaining, absolutely. Depression, luckily they sit far enough away from me that I couldn't actually see them sobbing in their cubes. But I finally accepted the challenge and they came back with a purple pattern which Sam is gonna talk a lot more about. Meanwhile, the rest of the JavaScript community kind of hasn't internalized the same message to the same degree. So I'm here to let you down. Not easily, this may be a little bit hard and I apologize in advance, but we need to get to the bottom of what mobile actually means. And when you see me tweeting things like this, this is actually kind of desperate. I have spent years of my life working in TC39 to make JavaScript a better language. I have spent countless hours persistently advocating for extensibility to give you more power when you're writing JavaScript in the web platform. I've designed features like service workers with Jake and a load of other folks that are entirely predicated on JavaScript in the first place. Back in the day, I used to work on a JavaScript toolkit with Scott and Steve from the Polymer team.  I don't hate them. It's just that we're really in the midst of a crisis and collectively we don't understand how bad that crisis is. If we did, we would have already modulated our behavior. So what I'm seeing when I do reviews is almost universally bad news, specifically in the context of the rail performance model. A quick recap of rail, basically our stands for responding to input in under 100 milliseconds. We're animating at 60 frames a second, which means that because the browser has to apply the things that we hand it on every frame, we probably only have about eight milliseconds to get to do our work. When you think about WebVR, it gets 60 frames. 60 frames a second is hard, 120, oof. When we're doing background work, we need to make sure that we're breaking up that background work into 50 millisecond chunks so that we can respond to subsequent input and stay under that 100 millisecond budget. And we really want to complete actions for the user in under a second, because over a second, research suggests that users lose focus on the task that they're trying to accomplish. If we can't actually complete it, we definitely need to acknowledge that work in under a second. Give users the sense that we're doing something for them. So you've heard this number all day today. Darren had it in the keynote, but the double-click folks went and did a bunch of work to find out what are the bounce rates for sites and does performance matter? And the answer, of course, is yes. 53% of users bounce from mobile sites that take more than three seconds to load. You leave real money on the table when your site is slow. Yet most of the apps that I've traced over the last year have been performance travesties. My experience isn't an outlier. The last, that same report noted that the average mobile site takes 19 seconds to load. 19 seconds. Collectively, we're failing. Sam's got more data on this, and I actually don't have time to go into it because we're gonna talk about some of the reasons why. But I think one of the key reasons that we are not succeeding today, to put it kindly, is a lack of understanding and respect for how hard mobile is. I have faith that as a community, if we understood and respected the limits, we'd be doing much better. Nobody here wants to make bad user experiences. I think part of this is because we're the only platform in the world that tried to take all of our desktop stuff with us. You don't take a Java jar that was a swing application and run it on your Android phone. You don't take a Mac universal binary and run it on your iPhone, right? You don't take a Win32 app and run it on your Windows phone. Everybody else switched their tools when their form factor and their constraints changed. We didn't. We didn't make that switch, and the proof is in the pudding. It's in the traces that I'm looking at every day. But that's not the only reason. Why are most of the popular frameworks and the tools that we're using, the tool chains that we all wind up setting ourselves up with, unacceptably slow by default? Why are our tools producing such bismol results? It's not like we're bad people who want bad things for users. I think in part, it's that you all aren't actually developing on mobile phones. Paul showed you some really great DevTools. They're awesome. So, but I want to understand who uses Chrome DevTools to sort of get the responsive view and understand how things will look on a phone. Okay. Now, keep your hands up if you're using web page test for testing on real devices.  Some of you are liars. And keep your hands up if you use Chrome colon inspect over USB to do real on device debugging. Okay, who's done it more than once? Okay, that's what I thought.  Network throttling, CPU throttling, they're all kind of a fudge. They're better than nothing. Please use them. Please set them on by default. Please use them all the time, but they're not the real thing. Not even close. Let me give you a quick example. This is the IO 2015 website, which was a Polymer 0.5 progressive web app. It was super bleeding edge. It had push notifications, which I think we had launched in Chrome like the week or two before. There were bugs. It was amazing. On desktop, it felt super fast on this wifi connection. We get DOM content loaded and a meaningful paint at about 700 milliseconds. Onload isn't far behind, and that starts a nice swooping out animation, which is smooth most of the time. Overall, we spend about a half a second in script, which is well under our budget for actually getting a good responsive experience. And we get interactive content in about four seconds, including that long animation. This is a really great experience on a desktop-class device, which is to say my MacBook Pro. This is the same site running on the same wifi network on a Nexus 5x. DOM content loaded doesn't show up until two seconds. Onload triggers at the six second mark, which is where that animation starts. Part of that delay is down to this huge honking scriptive valve. That's locked up the main thread for nearly two full seconds. Script execution balloons up to four seconds in total, and for all of that work, we still don't even get smooth animations. Look at all those long frames. Content doesn't become interactive until seven seconds. This is what TTI will tell you in Lighthouse, and this is not acceptable. Ouch. So what have we learned? Traces from real mobile devices are a harsh master, and when I show folks their apps on real devices, most have the same reaction. And in fact, I do this a lot. They're shocked at how slow the median mobile CPU actually is, not the iPhones in their pockets.  I think we theoretically know at some level that they're bad. It doesn't begin to cover it. They're so bad. It's important to understand the depth of the deficit, though, so we can start to adapt. I've been letting out down a bunch of engineers for the last year, hard, soft. I've just sort of been easing them into this sort of grief curve, and then hopefully we get out the other side, and it goes well, but you have to put in the work. But unless we do that work, unless we change the way we're working, that web won't work for the next billion users, not practically speaking. So something I say in basically every meeting is that the truth is in the trace, and by that I mean dev tools and Chrome tracing attached to real devices. Nothing else cuts the mustard. It doesn't get you there.  The folks at Conga report that the most commonly used phones in their market are in the sub $100 range new. I carry most of these phones around in this bag. This bag is in my bag, my other bag, with me all the time, and these are some slow phones. And I carry them because I have zero faith that anything I trace in Chrome on the desktop is gonna be like the real world unless I've put it on a phone and emulated 3G. And we'll talk about 3G. I don't trust that unless I've done it on real hardware. And you know what I also don't trust is the marketing numbers from phone vendors. So here are some of the headline specs for the devices that are in my bag. All these devices have flash-based storage. Naively, there's no reason to think that script should run 10 times slower on my Nexus 5X than it did in my MacBook Pro. Especially if I looked at these headline numbers, 2.8 gigahertz versus 1.8 gigahertz. That's not a 10X difference. Naively, there's no reason for that, right? If we just looked at these numbers, we wouldn't really understand what's going on. It bears repeating, if you think the $700 iPhone in your pocket is what people are going to be adopting in the next couple of years, at the median, you're delusional. The average selling price of smartphones is going down, not up, because the next set of people who are going to buy phones are not replacing their current phone. They're buying a new phone for the first time. And all the rich people already have smartphones? The next billion users aren't buying high-end devices. They're buying at the margin. And that margin is a cheap device. Worldwide, phones are getting slower. So is the average network connection. Your test device needs to represent that reality so that we don't wind up building what Bruce Lawson has called the Wealthy Western Web. So this is MotionMark. It's a benchmark that Apple put together earlier this year.  On apples to apples hardware with Safari and Chrome on running the same version of OS X, Chrome ties or beats Safari in most cases. Basically, this is not something that we're actually slow at. So here's the same benchmark on the same version of Chrome on an XS5X. The desktop version is 25 times faster. For a slower than XS5X is, I was able to change just one thing and get the MotionMark benchmark running 15% faster. 15% for one change.  Is it magic? We're all adults here. So I think it's safe to admit that magic isn't actually a thing. Instead, I used a little bit of science and I added this makeshift ice pack to the bottom of the phone. I got this idea from my colleague Victor who's been looking at optimizing this benchmark earlier in the year and was seeing massive variants across runs. What the heck is going on here?  Those wires have resistance and voltage and power are running through them, which means they dissipate heat. And we dissipate some more heat every time a transistor flips from the on state to an off state or vice versa. That same process generates computation but it also generates XS wattage in the form of BTUs. So a chip built on the same process with roughly the same architecture with the same number of transistors that dissipates more power and turns it into heat is the chip that does more math. And doing more math is how you go faster. When it comes to computing, power is literally power and power equals heat. So these are the guts of a regular desktop class machine. The chip in there is a slower version of the one in my laptop. The square fins on the top of that thing, they're the heat sink. And the job of the heat sink is to evaporate or sorry, dissipate the heat coming off of the chip. Now that heat sink is seated on top of a metallic top of the assembly for the chip with a little layer of thermal paste between it. So there's no air gap. That air gap would cause a thing that would explode and break the chip because it gets so hot. There's a fan that's running over the entire box extracting all that heat that's getting dissipated out. And the result is that a desktop class or high-end laptop chip like this can dissipate something like 60 watts under load. This is what 60 watts looks like. I don't know about you but I haven't chosen to hold 60 watts or my hand is spitting more than once. And the key, this is the key reason that mobile phones don't run as fast as desktops or laptops even if they can include as many transistors or scale up to the same frequencies. These chips in these packages just can't dissipate 60 watts without burning your hand as Taylor said earlier. So let's look at inside the guts of one of these phones. This is the remains of the Nexus 5X that I use as my daily phone for a couple of years. It gave up the magical blue smoke and stopped booting a couple of weeks ago. So now I get to dissect it. And unlike desktop class machines with a GPU and the memory might be on different sections of the board or different boards entirely, the whole system on a chip lives under the other side of this and that's that thing there is the power supply. On the flip side of the same PCB is the entire system on a chip. It's got an aluminum cover like this, sort of a heat spreader. So when we flip it over, this is what you see. There's no thermal paste, no fans. I took the shield off, but that's all. In fact, the CPU module isn't even visible on this board because it's sitting underneath that Samsung made RAM chip. Think about that. To get heat off of this CPU, it has to go through another chip and then through the casing of that chip, then to air, then to a thin aluminum thing to maybe spread some of that. And then out what? The screen? The two layers of polycarbonate plastic in the back? Two layers, separate layers, I'm not even connected. Remember that polycarbonate plastic dissipates heat 1,000 times less efficiently than aluminum. If you can't evacuate the heat, then you can't really generate a lot of it without the core temperature rising to levels that damage the circuitry. And then the magic blue scapes, smoke escapes and you phones out spooting. I wonder what I did to mine. So chip designers saw this coming. They've been putting dynamic voltage and frequency scaling into chips for more than a decade. And more recently, they've started enabling features that allow OSs to turn off cores entirely. All this reminds me of this paper that I read a few years back from 2011. If you have some spare time, I recommend it. Well, perhaps not intended to be, it reads like a prophecy from half a decade ago about the experience that we're all carrying around in our phones, where a huge percentage of the silicon in our devices isn't actually available to be used thanks to the power and thermal constraints. And the power thing is real. There aren't any heat sinks in your phone, although I'm pretty sure that you wouldn't want a heat sink and a fan in your pocket. But imagine if you could have one. Why don't those exist? Why can't I get a bulky phone? The basic reason is that this battery only contains 10 watt hours of power. Think about that in terms of the light bulb. You'd only be able to keep it lit for a couple of minutes if you had to, if you could drain the battery that quickly, which you don't because doing that causes batteries to explode. So just don't try. Just FYI, not a fun experiment at home. This is why mobile phones are slow. We can't dissipate power because we can't carry power. That battery has to deal with all sorts of stuff. It has to deal with the CPU and the GPU and the Wi-Fi radio and the Bluetooth radio and the NFC radio and the cell radio and the screen and the touch digitizer. It has to power all that stuff and keep you satisfied for a day's worth of use on a single charge on something that can't keep that light bulb lit for more than a couple of minutes. So to keep from wasting power, there's a lot more complexity in modern phones. Most of them today use what's called a big little architecture. And that means that they try to move work from high power cores to low power cores very aggressively. The systems that move that work around are called schedulers. All kernels have schedulers and the Android ecosystem schedulers are a bit all over the map. The big thing to understand about them though is that your phone probably isn't using what's called symmetric multi-processing. That is to say, not all of the cores respond up to the same voltage and frequency running at the same rate all the time. There are different levels. Most of the phones that you probably have have something called a global task scheduler which moves work around between those things. The systems in Linux that wind up doing that management, that work management are notoriously hard to tune and they use all sorts of heuristics to do it. Some do something called touch boosting and what that means is when you put your finger down on the glass, they power up the big CPUs in anticipation of you doing some work like animating something or flinging it around. Some of them have special heuristics for launching applications so that when you launch something from the home screen they power up the big core so that thing launches very quickly. Now, that looks nothing like the web workload. The web workload today looks like tapping on the URL and waiting for the network. Maybe those cores got scaled down again and then your content comes in and then we start processing it. Basically, the web is fundamentally not aligned with the way mobile phones have been optimized to work because our workloads don't look like their workloads. Lastly, remember that light bulb? The light bulb is why you shouldn't believe any of the numbers that really you see in benchmarking, right? The idea that your mobile phone CPU is as fast as a desktop CPU may be true in the limited case but not in the common case. You're gonna get scaled. You're gonna get throttled. Things are gonna move to a low power state as aggressively as possible. That's not how the world works. We don't keep things spun up the way we do on desktop. So here's that chart again but I added the details of the CPUs. It looks a lot different now, doesn't it? I don't even gonna get into the details of the huge differences that come from caches and pipeline depths and in order versus out of order dispatch and memory bandwidth but all of it matters. The TLDR is that you actually get what you pay for on a mobile phone. Importantly, the MacBook Pro packs 100 watt hour battery. That's the FAA maximum limit that you're allowed to carry in a single battery onto a plane, design constraint. But as a result of having that much power available and because the heatsink and the fan and my MacBook Pro I can keep those four cores spun up under load and they can dissipate something between 40 and 60 watts. All the phones in the chart are big little devices and that means that many of the cores are powered down most of the time. That Moto 4G at the bottom has eight cores but if you get more than three of them working for you at any point in time, you are really lucky. Right, so mobile CPUs aren't exactly what you thought they were, I mean, since when would a hardware vendor ever use an opaque number to mask a major difference in performance, right? And okay, maybe memory pressure and smaller memory footprints on mobile devices don't allow us to, on the browser side, trade away space for speed as aggressively as we do on desktop and maybe the storage systems are roughly as fast though so maybe we could get something back there. I mean, they're just solid state flash devices on a Linux OS if you're running Android, right? Who has heard of the term MLC flash? Okay, I think it's like 10 people. That's about what I expected. MLC flash is multi-level chips. Basically, they are chips on top of chips inside the same chip package and that is how you make storage cheaper. And it's a primary reason why my Nexus 5X gets 400 megabytes a second of read throughput and my MacBook Pro gets two gigabytes a second of read throughput. In SSDs, the way you get better performance is parallelism. In order to read or write a block, you want to distribute reads and writes for large reads and large writes to as many different chips as possible because the latency for getting data to and from each of those chips is constant so you have a controller in front, it's got some memory and then it distributes that work out to those chips. Now, physical space is at a premium on mobile devices but so is power so vendors have tried to consolidate those chips as far as possible and that means that they're using fewer and fewer usually one chip for all that reading and writing and that means low parallelism which means low performance. We don't get that benefit that my MacBook Pro does of having many chips in a row on a mobile device. MLC flash is also just now slower and file systems haven't really caught up. Basically, what you should think about the median mobile phone having is spinning disk from 2008. Think of it that way. That's probably a pretty good parallel. Okay, that's kind of a bummer, right? Spinning metal. And if mobile disks make you sad, the state of mobile phone networks will make you wish that mobile disks were the problem you actually had. If you hadn't, I recommend checking out Iliy Grigorek's high performance browser networking. It's free, you can read it online and it goes over a huge amount of the total end to end networks stack that gets bits from your server to your phone. Highly recommended. If you spend some time with it, you'll get to where I got to which is that mobile networks hate you. Cell networks are basically kryptonite to the protocols and assumptions that the web was built on. Where TCP and the web was built around the assumptions of a relatively stable underlying transport condition, cell networks gyrate wildly and from millisecond to millisecond. Where TCP assumes relatively constant packet loss and constant RTT times, cell networks deliver anything but transitioning from one network type to another or one subtype to another in real time. And where the web's model of hot linking subresources assumes reliable networks for the duration of the page, well, we kind of know how badly that breaks down in practice, don't we? At least those of us who use public transport or ride in cars or basically use phones. So this paper is actually a pretty good entry point and especially its references into why these networks hate you so much.  When you dig in, it turns out that what's really killing you is the variance and the volatility and the underlying network substrate.  Well, yes and maybe. Here's last year's performance for US LTE users compared to the year before. These networks are actually getting slower. In fact, the variance in mobile networks is so massive that it feels like a farce to call something 2G or LTE. Some of the largest emerging markets have median RTT times north of 400 milliseconds. When you open DevTools and you do network throttling and you put it in the regular 3G mode, it says the RTT to 100 milliseconds, which is part for the course in the US, but wildly wrong in other markets. Especially when you think about how many carriers wind up throttling things even further down. The same network type may mean dozens of different things for your users. For the TCP gigs in the house, thinking about what that sort of around chip time does to the bandwidth delay product can really bring you down. Channel capacity be damned. That sort of latency eats your transfer speed for breakfast. But of course, this is mobile, so it's worse than that. As Ilya said to me recently, a 4G user isn't even a 4G user most of the time. Cell radios are magical things. Sure, they try to preserve power too though, and they seamlessly transition between their high power states and their low power states. Across different radio types, different cell locations, they do a ton of work to make sure that we never see what's happening under the covers, but that creates variance. When users try to connect, their phones might be in a low connectivity or a low power state when they weren't just a minute ago. In those cases, the radio resource control protocol that Ilya's book goes into some detail on determines how the connection gets made. For users in very low power states on 3G connections, it can take seconds to just start the radio handshake at the physical layer so that you can start transmitting data. If you wanna get bits on screen in three seconds, you're in a really tough spot. You can't do DNS, TCP, TLS, or even start sending those HTTP headers down the wire until all of that is complete. Now consider adding hundreds of kilobytes of JavaScript to the mix. That's not theoretical. The HTTP archive is showing that the top 1,000 sites put almost a megabyte of uncompressed scripts on their pages today. On those networks, on these CPUs, this is a recipe for disaster. No wonder users have the pervasive feeling that the mobile web is slow. I think it's only reasonable to be sad about all this. The tools and techniques that we've brought over from the desktop era really aren't serving us. To make great progressive web apps, we need to do things differently. We need to load less code. We need to load it at the right times. And we need to let the browser do work for us whenever possible. Use the platform isn't a nice to have. On mobile, it's the only way to go. Sam's gonna go into a lot more detail about the depth of the crisis that we're in, but make no mistake. If you're using one of today's more popular JavaScript frameworks in the most naive way, you are failing by default. There is no sugarcoating this. Except for the tiny club of fast enough to slow by default tools like the Polymer App Toolbox and Preact with some good webpack foo. Today's frameworks are mostly a sign of ignorance, or privilege, or both. The good news is that we can fix the ignorance. So when we're armed with data, we can make better choices and avoid those slow by default tools. Now, I talked to a lot of teams who've gotten a long way into their PWA development story and they've got very heavy clients by JavaScript apps. Their apps feel like Gmail, basically. They get a loading bar or something like it while a ton of script starts to execute, and then they get a fast UI. All the subsequent interactions wind up being fast because they've paid all that cost up front, but many developers find that this is kind of slow. It feels slow to use. Once everything is loaded, it's great. But as we saw earlier, JavaScript execution on phones makes this strategy kind of a loser. JavaScript execution is single threaded. Sure, we can parse and compile off thread, but we can't use the preload scanner to grab some resources if they're embedded in that script. We can't speculatively build DOM or parse CSS or apply it. When you go with one of these tools that doesn't use the platform well, you bet the farm on a single core, on a phone that might be thermally throttled or in a low power state. Good luck. So, what we're seeing now is something called server-side rendering, AKA isomorphic rendering, AKA universal JavaScript. I haven't looked in a couple of months. Is there a new term for this? I'll take that as a no, okay. So the idea is to run JavaScript on the server the same JavaScript on the server that you run on the client and then send down a pre-computed snapshot of the HTML that you were gonna send. And then you load the jargantuan JavaScript bundle and hope that it all works out. On my MacBook Pro or an iPhone with a fast connection or my Pixel, something like that, this works out pretty well. But for the vast majority of users with less expensive phones or less good connections, you get this crazy uncanny valley. When the JavaScript arrives, the main thread locks up all the same. Until it starts executing and finishes, the content might be displayed, but it isn't meaningfully interactive. Now there's a debate that starts. Some folks think that because maybe you can start scrolling this stuff because browsers are magic and they do threaded scrolling and scrolling actually is an interaction. If I can't put my finger down and tap on your UI and have it start responding and doing work for me under 100 milliseconds, it isn't loaded. It's broken. Okay, all right. What we really want is progressive interactivity. And this is what the purple pattern that Sam will go into delivers. The insight here is that you should only load the code that you need right now if possible for the views that you're actually sending to users. And combined with service workers and HTTP to push, it's possible to achieve this without overbundling. Purple in the Polymer app toolbox represent what's possible once we take that mobile by default thing seriously. And it's night and day from where most popular tools are. So this is the shop app that you've seen before. The Polymer team released it at IO. You can visit it right now at shop.polymer-project.org. And here it is running on a desktop browser. We get to interactivity very quickly on Wi-Fi and it only takes a few hundred milliseconds of script overall, you know. So what? We've seen this story before. But what about mobile? Again, Nexus 5x, same Wi-Fi connection. Despite this lower CPU, the app sends down an appropriate amount of script so that we get interactive performance at under two seconds. There's nearly a second and a half of script execution overall, but thanks to the granular use of HTML imports and HTTP to push in contrast to major bundling, most of the components load with tiny execution slices, which means that the content that's already on screen stays interactive. This is what mobile first looks like and it's radically different in a good way. The other thing that the purple pattern adds is a service worker. You might be thinking that service workers are about handling offline and while it does allow you to do that, that's not the primary benefit for most end users. Service workers matter because they let you deliver reliable performance because they can handle the top-level resource and always return something from the cache. You can dramatically improve the performance of your apps when you use service workers this way. That huge variability in network conditions, it evaporates when you've done this. So this is a chart that Eric Biddleman gathered from this year's IOS site. It's also a progressive web app, but with Polymer 1.0. But as you can see from the giant dark green spike, when the service worker is active, the distribution of load times moves hard to the left. And that's a good thing. This is very literally what faster looks like. I'm seeing a lot of teams try to add service workers as some sort of transparent pass-through thing using a network-first approach. Don't do that. Please don't do that. Use the purple pattern and make sure that your top-level app shell never depends on the network. If you do that, you can compete with native apps on the experience that you deliver. If you saw Darren's keynote this morning, you saw exactly that with the keynote tech, the CNET Tech Today PWA. If you don't do that though, you will never match their performance. Until recently, it's sort of been difficult to verify in an automated way that your service worker is installing and that the rest of your progressive web app properties are actually met correctly. You've heard a lot about Lighthouse, but please put it in your CLI, put it in your continuous integration system and let it tell you how you're doing. So I think it's safe to say that mobile is much, much harder than we've collectively understood it to be. To make good apps in this environment, we need to change our outlook, our tools, and most of all, our priorities. And the fastest way I know to get in touch with that, that ground truth is to test on real hardware. So please, if you don't already have a circa 2014-ish Android phone, go ahead and buy something like a Moto G4. If you can use one of these and Chrome Inspect on DevTools, you'll find yourself in touch with how it really feels to be at the median. If you can, get something worse. Like this is an Android one from last year. You probably can't buy one, but get something worse if you can. And if you can't afford any of those, please use webpagetest.org to select from the list of real mobile devices that are sitting in a rack at your disposal to test your URLs. And whatever you do, implement as much of the purple pattern as you can. Sam will fill you in in the details, so stay tuned for that. And lastly, Lighthouse and Chrome Telemetry are potent weapons in your ability to not regress on keeping sure that you're doing the right thing. I wanna apologize for being a bit of a downer today. Usually, I'm telling you about how good PWAs are and how great the experience is that you can deliver. And that's all true. And there is good news, and that it's that modern web technology makes it possible to build truly amazing experiences. But it will require ditching or radically reworking the way that we're using these slow by default tools. Addy's got a whole talk tomorrow about what kind of elbow grease you really do have to put in if you've bought into one of today's major frameworks. But no, I think now that the challenge is much larger than you probably thought it was. Now that you know, I'm actually very confident that the folks in this room and on the live stream are gonna internalize this and use it to make really great experiences. So thank you. I'm pretty sure I did promise he was here to cheer you up before he came out. I feel really sad. No, I was the backstage going, no, no, no, no. I want to touch the light bulb now. Are you? The whole point was you're not supposed to touch the light bulb. I did actually do that once as a child. I even remember being, it's one of my earliest memories sat on my dad's lap and seeing the light bulb and thinking, ooh, we're gonna touch that. And then my dad was like, no, Jake, don't do that. And then it's like, well, give it a second go. And he stopped me again and said, no, Jake, that's gonna really burn. And I remember watching him until his head was turned away and thinking, oh, got him now. This is my chance. This is my big chance. Bang, burned my hand to pieces, big blister to hospital. So that's you and Alex in the same boat. Yes, we've made the same bad life choices. Good to know. Good to know. Well, it looks like the quiz is available. Let's see if we, oh, here it is on the screen. Okay. Oh, thanks. Well, thanks to the fantastic AV team for restoring our quiz. It feels like it's been a while since we've done one of these. It has. Right. Okay. Ready? First question. Everybody on bigwebquiz.com? Bigwebquiz.com. Let's go. Let's launch into our first question. What does the following JavaScript lock? I'm not gonna read that out. No, because I can't take you. Promise.resolve.net. See that code? Does it log one, two, three? Three, two, one. Two, one, three, four. Not sure. Maybe. Maybe. I mean, so what we've got there? We've got some promises going on. We've got an async function. Oh, set time out with zero. Zero. Interesting. That's kind of like set immediate in some contexts. So what we're seeing here. Interesting. Well, there's a lot of confidence in one answer. Not being like, who is voting for that one? I'm pretty sure I know what it is. We have comedians in the house. I know. Four. Some people just don't want the muck, right? Is it not on big enough price? That is a shocker point there. So here we go. But then across the rest, it's pretty equal, isn't it? Let's close it. Shall we close it? So 38% of you said two, one, three. That was the most popular answer. Only just though, isn't it? Equals on three, two, one, and one, two, three. Shall we take a look? Oh, yeah. Let's see what the correct answer is. Two, one, three. So people are very pleased with themselves. So how is this actually working? Shall we take a look? So we've got promise.resolve that then, now, any promised reactions are going to queue a microtask. So that's what's gonna happen there. An async function, I mean, it's obvious to me that an async function will run synchronously. But that is what happens. That is true, yeah, well, wouldn't it? It's not awaiting anything. It's not awaiting anything? It's very much like the promise constructor also, also run synchronously. And then we've got a set time out which use a task. Microtasks happen before tasks, and then there you go, two, two, one, three. Fantastic. It's easy when you think about it. Makes me wanna cry. Yeah. Okay, now, backstage, you know, I remember from the intro this morning that we were wearing tuxedos. Yes. And we didn't feel comfortable in tuxedos, but management felt that we might wanna reconsider that option and we've been discussing it with them. Well, they've been pointing at Alex and saying quite smart and saying, maybe just up your game. Could we represent the company a bit better? A little bit. And so we said, look, you know what? We're gonna put it to you. Ah, okay. So this is a poll, it's an unmarked question. Would you like to?  Should Paul and Jake wear their tuxedo suits tomorrow? Yes. Or no. It's just one of the select one question. This is a select one, it's not a multi-select. Well, it's looking quite good. It's looking favourable in one direction, my friend. Yeah, sorry, it's 7427. This is where we find out whether they like us or not. Are we ready? Two, one. Right. This is the worst polling result in almost two days. I don't know what to do. I think we know where we stand with you. So I think the only thing left for us to do is to introduce Sam. Sam's gonna speak to you now. Bye. Big round of applause to Sam. Maybe we left too soon. Yes. Oh, hang on. Sam, is this a miming talk? Oh, it's one of his... Oh, with a... This is more of a statement about web performance like Alex was saying. We're waiting for him to boot up. That's what it is. It's like his calls are in low power mode. He's downloading his talk. It's just... I really don't like suits. And yet... Thanks! This will be... I mean, aside from the small intro video that we filmed, this will be the first time I wore a suit where someone's not getting married or has died. Because that's...  That's what I was like. I was just like, why am I even... I was really hoping I was gonna look like a spy.  By the way, how do I smell OK? Because we filmed the intro a couple of days ago, and for continuity, you know, we had to wear the same stuff. The same stuff from there, so it's kind of... It's into the second day of T-shirt wearing, especially with all the lights and stuff. I did wonder. So, we should have got you out with a saxophone again. No, I think we've all done that one. So, I am now, like yourself, a glasses-wearing person. Indeed. Not wearing them now. I noticed. As you can see, I'm not wearing mine. I'm glad we have this chat. But when I was getting my eyes tested, the optician, they'd go through the series of questions. Yes. Like, are you as well? Is it better, worse, or just the same? Well, this is before all of that, before the better or worse. Well, they have a look around your eye first, right? Well, this was just stuff like, do you smoke? Do you exercise regularly? And then she threw me an absolute curveball. She was like, what are your hobbies? And I panicked. Because I was like, well, I reset web standards, but the problem is that I ended up being my job, so it's no longer a valid hobby. And I just went, I played a piano. I mean, at least it's not verifiable at that point. Well, that's why I was worried about it. Did she ask you to do air piano at that point? Well, I was worried. I was like, oh, well, we're not going to use the normal charts then. Here's some sheet music, if you could just read me what notes are there. Interesting. I'm really good. I play by ear. I play many of their sheet music. Apparently, I discovered, because my kids had their eyes tested, they know if you lie to them, because when they look in your eye, they know what your prescription is, then after that, when they're going, is it better, worse, or just the same? They're just double checking what they already know. Why would you lie in an eye test? Well, do you not have a... I want... No, no, no, no, no. I want better glasses. I want to see into the next continent. I want to win the contest against the optician. Like, can you see that, yes? I can. You can't? Oh, you should get glasses. I have glasses. So, no, I like winning. So, maybe I'm thinking about this all the wrong way. Well, I'm still at a stage where I can't wear them when I am actually sort of walking around. Do you fall over? Yeah, it's kind of like that feeling of like, you know when there's an escalator that's not working? Oh, that's horrible. Yeah, on the London Underground, we have lots of escalators, but none of them work. I think the first escalator... Those are stairs. Yeah, well, exactly. This is the progressive enhancement story, right? Right. I think it was 1917 that they kind of... they ran the first escalator on the London Underground, and they've been trying to do that again ever since. Repeat that fluke. Exactly, yeah. And you feel like you're moving really fast when you stand on it, so... Did not know. Hmm. How's it going over there? Performance books. OK, good to know. So... We could abandon them. Oh, no. We could. Is there any chance we could get another quiz question in? Oh, we could do another quiz question. How about... Can we get a smile from Miles? Miles, hi. Could we do another quiz question while we're here? Is that a possibility? I mean, we've got lots of questions. Yeah, we've been having loads of fun writing these. I thought we were just going to have to keep talking nonsense. We might still have to. We might. It'd be exciting. Oh, Paul, let's have a look at some of these. What do you think we can... Should we go for this one? Yes. Yes, OK.  Oh, we've got another plug to go in. That's fine. OK. Feels good. What have people normally said? Is everyone enjoying themselves? No. Oh. I think that was a no. That was a very polite no, wasn't it? Are you enjoying yourselves? Right, here we go. This looks good in front of us. Right. Yes, OK. Right, so if we can get that on the screen, that'd be amazing. Can we get the quiz? Everybody heads a big web quiz. OK, here we go. Right, next question. Is it really... But it should be working. This continues to be the best day of my life. That's an active question. Interesting. Keep talking, Paul. Yes! Another question. I don't know why that was right. Here we go. Well, people should have already had that on their phones, I imagine. Oh, yes. How many times does the ECMAScript spec explicitly mention JavaScript? Is it zero? Is it one? Thirteen or ninety-three? Yeah, the ECMAScript spec, of course, being the thing that the JavaScript is based on. That is ActionScript and JScript. ActionScript. Yes, you're an Xbox developer. I am. Now, 53% on one of the answers, 36, 6 and 5. So two more popular answers there. Should we lock it in? We lock it in. Two, one. Zero. I'm thinking quite the low numbers, 50% on zero, 38%. Oh, the correct answer is... Oh, somebody's gone to the URL and gone. I was surprised. I thought it was going to be more than one. Yes. Yes. Shall we do the other related? Let's keep going. Let's go for... I quite like my JavaScript. Is there one like JavaScript or structuring? Because I do. Yeah, let's do that. Here we go. Next question. This is on destructuring one of the new ES6 features. What is the result of the following? Logs world? Logs undefined? Frozen error. Keep your answers in. Do you want to try to just copy and paste the text on there into the console? Yes. Yes. I might have seen one down there. You feel suitably ashamed? Yeah. Okay, so we've got some very confident answers. Oh, it's dipping. Dipping though. 44. 44. There's confidence going down on that middle one. Lock it in. Nice. Just by logging worlds, that's the most popular answer there. But it's just behind error. The answer, of course. Of course. Of course. I totally knew it before I put it into the console. It does throw an error. So this is it. You're not passing an object in. It tries to destructure that object that doesn't exist. Error. Error happens. Indeed. These questions kind of come as a pair. Let's do it. Shall we do the other one? Yes. Interesting. So interesting. You might recognize the curve. What is the result of the following? Logs world? Logs undefined? Both throws an error. Same answers as before. Interesting. Is it the same correct answer? That's the question. The clarity there in the middle. That's 15%. Is that thing? Did they give us two questions that both throw an error? What? It sounds like something they would do. It does, doesn't it? Yes. Let's lock it in. The most popular answer is logs undefined. Interesting. And the correct answer, once it makes its way onto the screen. Logs undefined. Smart audience. Good work. So what's actually happening here? Well, so the object has a default value of the object there, hello world. But because we provide a different object in, it doesn't use the default. So hello never gets set at all. We're going to go to Emily. Okie dokie. So we've got a slight change in the schedule there while we figure out some of these technical issues. You said schedule. I discovered it's schedule here, I believe. Yes.  No, it's schedule.  So our next speaker, here to talk about security, is the Queen of the North, I believe. Emily Stark. Emily Stark. I'm Emily. I'm not going to stall you anymore. So hopefully you're happy about that. Welcome. I hope you're enjoying the first day of Chrome Dev Summit. I'm an engineer on the Chrome security team. And my colleagues and I on the security team are on a mission to be honest with the people using our software about their connection security. And we need the help of you all, the developers in this room to do that. The first way that I'm going to ask you to help us out is to do a little thought exercise where you put yourself in the shoes of an average web user. So probably not a developer, maybe someone who is even new to computers or new to the web. And if you were this average web user, looking at this omnibox, which is what Chrome shows when you visit an insecure, plain HTTP site in Chrome today. If you were this average web user, what might this omnibox say to you? You can see it kind of has the host name of the site, and it has this sort of neutral informational icon, right? So if you were seeing this, what would this mean about the site that you're visiting? As an average web user, you probably wouldn't realize that an attacker sitting between the web browser, between your computer and the web server, can read any data that's passing back and forth between the two of you. So that could be sensitive data like passwords, credit cards, health content, all of this stuff. You probably don't want an attacker sitting between your computer and the web server to read. Or as an average web user looking at this omnibox, you probably wouldn't realize that even though the omnibox says example.com, that's not necessarily who you're actually talking to. Over insecure HTTP, you don't actually have that guarantee at all. You could be talking to any attacker who's impersonating example.com. And that's probably pretty unintuitive to the average web user who looks at the omnibox and sees example.com. And finally, this average web user probably wouldn't realize that any attacker sitting between your computer and the web server can modify or tamper with content that's going back and forth between them. That tampering could be to inject ads, perhaps overriding your legitimate ads. It could be to insert some fake or malicious content. It could even be to trick the user into downloading or installing malware. So if this was your site, with this attacker modifying or tampering with your content, this is obviously very bad for your users, right? They're probably getting a poor user experience. They might even be being tricked into downloading malware. And it's bad for your site. It's bad for your brand. It's bad for your revenue. You're not delivering the legitimate good user experience that you want to deliver. And these risks are real. They happen every single day in coffee shop Wi-Fi, internet service providers injecting ads, software like Firesheep that makes it really, really easy to passively sniff on unencrypted session cookies. These things happen. They're real. They're probably affecting your users. And the way to protect your users from that is to use HTTPS. These risks are why we on the Chrome security team are on this mission to fix this UI, which we don't think is being particularly honest or forthcoming about what it means to use in secure HTTP. What we plan to do in the future is not this sort of neutral presentation, but a presentation that actually delivers a warning to the user, the risks that they're taking by using in secure HTTP. So in this talk, I'm going to tell you about our mission to get to a place where we can use this warning UI to be honest with our users about their connection security and how and why you as developers should help us with that. I'm going to be telling you about some newly released metrics about the honest state of HTTPS usage in the world today. And those metrics will hopefully help motivate why and how you as developers should help us move the web to a place where it's HTTPS by default because it's good for you and your users, it's good for your site, and it's also good for the web as a whole. And finally, I'll be previewing some upcoming Chrome UI changes that illustrate our strategy, which is to gently prod developers like you into adopting HTTPS while simultaneously kind of using our users into the idea that HTTP is probably not what they want to be using. In the spirit of honesty, I'm going to start by telling you about a section that we added last week to the Google Transparency Report. The Google Transparency Report, if you haven't seen it before, is a collection of all sorts of interesting and useful data about Google and about the internet as a whole. And for most of this year, we've had a section on this transparency report that's devoted to HTTPS. Very interesting data, but up until now it's mostly focused on HTTPS usage at Google, so on Google services, Google traffic, and also on some of the top sites. Tracking this data has been pretty encouraging. Since we launched the transparency report, the HTTPS section of the transparency report in February, we've seen 12 more of the top sites adopt modern HTTPS. But this is not necessarily the full picture, right? Because what are the top sites? What does that actually mean for people who are using Chrome every day? That's why last week we released a new section in the transparency report that releases data about HTTPS usage as Chrome users see it. One of the milestones that we passed recently, as you can see here, is that on desktop platforms, Chrome users now load over 50% of their pages over HTTPS. This is a big milestone, and overall we're pretty happy about the trend here, which is that HTTPS usage, when we look at that as percent of pages that Chrome users load, slowly but steadily increasing. That's what we want to see. Obviously we want to see faster increase, but slow but steady, we'll take it. Another way to look at it is not the percent of pages that are loaded over HTTPS, but the percentage of time spent. And as you can see from this graph, this is an even more optimistic way to look at it, because Chrome users spend on desktop platforms about 75% or more of their time on HTTPS. We don't necessarily know why this is for sure, but one way you can think of it is that users probably spend more time on sites like Gmail or Facebook or you're super engaging for rest of web apps than they do when they're just Googling around for some information, like a link navigating away. So we think that users spend most of their browsing time on sort of heavy-duty apps that, for the most part, are top sites using HTTPS. I also want to make a quick note about Android usage, which you might have noticed in both of