 Hi, and welcome to the day two keynote. My name is Nicole. I'm a PM on the Chrome web platform team. And my name is Malte. I work on AMP and JavaScript infrastructure at Google. So actually, this is a little bit awkward today because we're the second keynote, and Ben and Deon already talked about effectively everything yesterday. So we thought we'd do something slightly different. So normally, at a Chrome Dev Summit keynote, we'd walk through all the new exciting APIs that the web platform makes available for you. And so we actually are going to do that but first we want to talk about something slightly different. We want to talk about web frameworks. Developers who build for the web often choose to use a framework. In the past, changes to the web platform didn't necessarily take frameworks into account, and changes to frameworks didn't necessarily take the web platform into account. We think both the web platform and frameworks benefit from a close collaboration, and so we're out to make that happen. Obviously, if you're building something simple, it makes sense to choose simple technologies. But as soon as an app is sufficiently complex, in most cases, developers choose to use a framework. A few months ago, I put out a very, very methodologically correct Twitter poll asking people why they choose to use frameworks and got back a whole bunch of answers. And this one in particular sort of resonated with a lot of people. You can't not use a framework. Your only real choice is to either use one that's open source documented, tested, supported, maintained, mature, and proven. And I think we'd all throw, you can stack overflow stuff about it into that one. Or the option B is you cobble together some garbage, unmaintainable stuff yourself. I've made a few of those, actually. Yeah, I might have made one or two of those in my day before. And given that, we just want to start by recognizing that frameworks are part of the web and that if you're using a framework, you are, in fact, using the platform. So let's go from there and kind of extrapolate to the further web stack that is based on that kind of insight. So on the bottom, obviously, you have the web primitive. So that would be the DOM, the Fetch API, service workers, stuff like that. Then above that, we have built-in modules. Built-in modules are pretty exciting. They're a new thing. It's the idea that we can build in a layered way for the web. They're high-level APIs that solve something like virtual scrolling or carousels. I think we all love to hate the carousel. But if we're truly honest, they're on almost every site in the known universe. So we can build something like a high-level API, like a virtual scroller. And then that drives out the low-level APIs that we need to make those experiences accessible, searchable, truly fast. Those low-level APIs can then be used by the entire ecosystem of virtual scrollers. That makes a big difference because it allows everyone to level up together. Right. So on one level up, we get the framework. So that would be like React, Angular, Polymer, or higher-level stuff like Next.js and SAPR that treat you to everything that you need to build an application. So obviously, these aren't standardized. They're not web standards. But most applications use one of these. And so we think of them as part of the platform. The next part is web components. And you're probably thinking, wait, that doesn't make any sense. Web components are a web primitive or a web standard. I'm not talking about the web components, the standards. I'm talking about your web components. Your date picker or, I don't know, tabs. Maybe your carousel. Maybe your carousel, sorry. Yeah, these are the web components that layer on top of your stack. Why it's important to put them there is because they're an important measure of interoperability between different parts of your system. Right. To kind of make a point, let's do a quick poll here. Who here in this room has built a React application? All right. That's most hands. So if you keep it up, keep it up, keep it up. If you're anywhere in your company, you also have an Angular, JQuery, Backbone, Polymer, anything like it. Both hands? Yeah. So if that's the case. I love your honesty. Wouldn't it be nice if you could use the date picker in both of those if you could have a design system that spans your entire application suite no matter what framework it's built in? So that's why we think that your leaf components, web components are really the right technology to build that. There is, however, a real problem with web development today. We're struggling to make stuff that's really fast and responsive and has buttery smooth animations. And I think we're struggling because in a bunch of ways, it's actually really hard. Not everybody struggles. There are examples of sites that achieve this. But at scale, what we observe is that our performance goals aren't being met. Right. And so what we're kind of observing is that in web dev today, we often have to make that choice between developer experience, how we feel as developers, and user experience, how users feel. And that shouldn't really be how things are. And the vast majority of cases, developer experience, combined can lead to great user experience. That's just not how it works today. But if we can achieve those things coming together, the web would be better for everyone. This is why we're so excited about frameworks. Yes, frameworks sometimes make web apps slower. That's a reality. But they're also our best hope to make them faster. Right, so that's a bold statement. It is a bold statement. To prove that this is actually happening, we thought it wouldn't be nice if we celebrated all the great improvements that framework has made through this year. Let's start over with React. They have done a bunch of foundational work. For example, they're working towards making code splitting something that's first class supported in the framework, which is really nice. And then they've done a lot of work to break up the rendering of huge dump trees into tiny chunks so that if you have a big update, it doesn't lock down your browser for many seconds. Everything's kind of done in small breaks. This is a theme you're going to hear us talk about a few times. Yeah. Angular made improvements too. The Angular CLI enabled performance budgets. This is great because how often do you not realize that you actually alienated a bunch of users by adding that one more library or NPM installing something that didn't install the whole bunch of other things. Angular also did a bunch of work to remove unnecessary polyfills. That's fantastic. We don't want polyfills for the most modern browsers. Speaking of which, Vue basically did the same thing with a thing called modern mode. So you only ship the modern code to modern browsers. And that's effectively the same idea. And that's why we're so excited about frameworks kind of bringing this best practice to all the users. Similarly with another one, just making pre-loading, prefetching something the framework does by default. Polymer did some good work this year, too. They're transitioning to LitElement for super small components. And they also got faster because, yay, Firefox ship native web component support. Cool. Let's talk about Svelte. They got a bullet point for already being super fast. Yeah, it's kind of hard to, with Svelte, it was like, well, they're so fast. What do we even say about this? But I think this was a great example. So they built a Hacker News app. And they did it in an idiomatic way. So not like using super ridiculous hacks, right? So everything in that app, HTML, CSS, JavaScript, together is under 20 kilobytes, which is just amazing. AMP did some good stuff, too. So this apparently is the only feature he shipped this year because now he's a manager. Yeah, I'm sorry. So he shipped feature policies against synchronous XHR for all ads. If you're going to ship one feature, this is a pretty darn good one. If you imagine, you get to put your own feature on the slide. He also reduced the JS size on the wire by 20% by enabling broadly compression algorithm. We love this kind of thing, right? Because how great is it that all you have to do is turn on a different kind of compression, and you get a 20% reduction in size on the wire? Right. Moving on to Amber, which removed jQuery from the default bundle, by the way. I have a jQuery t-shirt. Just leaving that out there. Making the bundle size 20% smaller, which is great. And they did it in a way that's backward-compatible so that people can slowly migrate to this. Yeah, it's pretty neat. They actually, as far as I understand, made it so that anyone could turn on and off old code using the same functionality, so that's pretty great. And then another theme here, implementing that incremental progressive rendering with batched rehydration, which, again, comes down to that chunking of work theme, which we're seeing here all the time. Great, so kind of to summarize this, we really want to get to a state where not only the super experts can make great web experiences, everyone should be able to do it. And frameworks are an integral part of making that happen. Today, we feel that we, and by we, I mean, browsers, framework, and tools have underinvested in tools that focus on combining great developer experience with a focus on user experience. We can make this happen as a community. By integrating the best practices, performance into frameworks, all the users of those frameworks automatically get all the benefits. And that's how we think we can achieve great outcomes for users at the scale of the web. To make this happen, we're announcing three things today. The first one is we are including frameworks in the Chrome intent-to-implement process. How many folks know about our intent-to-implement intent-to-ship stuff? A few, great, that's awesome. So we have basically two important checkpoints. We have more than that, but two very important checkpoints when we're going to ship a new feature. One is our intent to implement, and the other is our intent to ship. At both points, when we're about to build something and we're about to ship something, we want to get a lot of feedback. And so we go through this intent process in order to intentionally go in and draw in that feedback. Previously, we had listed web developers as folks that we wanted to get feedback from, but now we're actually explicitly adding frameworks to that intent-to-implement process. Right. And secondly, we want to put real dollars behind this. So we're starting with a budget of $200,000 to kickstart developing of performance-related features in frameworks. In particular, we make available a list of performance features that we'd love all frameworks to provide to the users by default. Folks who are working on a framework can ask for funding to do the actual work. We're kind of still working on the exact details, but if you're interested, check out this bit.ly link for more information. The third thing that we want to do is increase collaboration between frameworks and the Chrome team. It's funny to announce this today because it's actually something that we started in the summer, and we've been working with a bunch of frameworks for the past several months. But we are excited today to talk through some of what we've started already. Right. That brings us to our next section. It's very much under construction. You heard that in the intro today. What we're hearing about here, these aren't things that are shipping tomorrow. Some of them you can try out a little bit. Some of them are like really... Some behind a flag. Yeah, we're like really just thinking about them. So it's still very much time to give us your feedback, your use cases, your examples to kind of work out how they really work. The first one we want to talk about is display locking. We basically don't want to update the DOM inadvertently, and so this gives us a way to lock it. Before I joined Google, well, many times, I think this is one of the most requested features. But before I joined Google, the Polymer team and the Paint team had a bunch of conversations of a new primitive called display locking. The idea of display locking is that you can basically lock down a section of your DOM and we won't trigger render and other things on that bit of DOM until you unlock it and say, okay, it's ready to go. It's super subtle and it may not be something you interact with directly, but it's definitely something that frameworks need in order to eliminate unnecessary browser work. Now we're collaborating with the React team to nail down the API and we had an intent to implement out about a month ago. So if you have comments, we'd love to hear them. I have a question though. Is it related to that BG color? Because I'm using that every day, ready? Absolutely. Nice. Well, this is kind of awkward. Is it working? I don't know. It's kind of strange, right? To see a blank white screen in the middle of a presentation. Why do we think that's okay when web pages are loading? Sort of, ah, what's going on? Right, every time, every single time you load a new web page, the browser says, hmm, what's the good idea to do? Oh yeah, I'm gonna paint white and then it's gonna take a while, right? Why is that the case? So it shouldn't be the case. We should tell you that we totally scared the tech check people when we had a blank white screen during our tech check. All right, we really need page transitions on the web. You're probably familiar with stuff like this from the material design specification, right? Or one page morphs to the other and there's other ideas how to do this. Now this is something you would see in your application going from one state to another. But we also want this for normal navigations, right? Like, here's a great example. So this is something the image search team at Google is working on. It's kind of subtle, so. Yeah, we'll walk you through it. So this is their like image search result page and when you click one of the images, you go into this light box, right? Just to see the larger version of the image. So their goal was that more people click through to the underlying web page and so they wanted to make that really easy by just literally putting that web page at the bottom of the page, right? So that, as a user, all you have to do is put your finger on it and kind of draw it up, right? We're hoping that this greatly creates and increases the number of navigations actually happening, but this is something that you really just can't build on the web today. We'd love for you to be thinking like, if you didn't have to have that blank white screen, what would you build? What would you design? Because I think it's actually pretty exciting a space. Right, today you really have to choose between either a fancy transition or doing a real navigation with a browser that's on your page. And there isn't really a solution for the cross-origin case where you navigate to a different domain at all. And so that's why we're so excited about portals. What portals give you are advanced transitions between websites that are real navigations. SPAS, single-page apps, right? That's the way to do it today, but here you can, and this is what this example gift shows, this is a navigation from one web page to another and you can morph between them anyway you like, which seems like something we should have in 2018. It does, doesn't it? Yeah, I think sometimes we will choose a single-page app with all of its complexity when actually what they wanted was fancy transitions. Right, it can be really hard to do a single-page app. Cool. So I got a sporty new car and within a month I got a ticket. I was driving too fast. In Germany, hopefully. No, on the San Mateo bridge. Oops. I won't tell you how fast I was going, but I found out that my car has this really cool feature. I can turn something on so that it beeps any time I go over 80 miles per hour. That seems really good because there should be limits and this car does not feel like it's going fast when it's going actually pretty fast. There's also something you can turn on for a motor or a car, which is called a governor, which actually will not allow the car to go over a certain speed. Feature policies are sort of like that. You have a couple of options. You have enforce mode and you have report-only mode. You can turn a feature policy on for something like synchronous XHR and you can say, no, I don't want to allow that and it simply will not allow that to happen on your site at all anymore. Or you can turn on report-only mode and you get that beep, you know, hey, something's wrong, you should check it out. We're pretty excited about feature policies because they run in CI, you can run them in development, you can run a different set of feature policies on your third-party content, your ad content than you do on your regular page. So you've got a lot of flexibility around how you use it and we're excited to see what you want to do with it. What you can use today is a synchronous XHR feature policy. We collaborated with the AMP team and they've got it turned on for all ads in AMP, which is pretty exciting. That's basically, by the way, the worst feature of the web. You want to turn this up for your website, right? There's no good reason to have SyncHR. There's basically no conversation in which Malta does not bring up that you should turn on synchronous XHR. I'm so mad about it. Even at your barbecues. There are other policies that are available as well. So there are some exciting ones, but they're behind a flag. So you have to go and turn it on behind the flag in order to check it out. There are three I'd love for you to look at, unoptimized images, oversized images, and unsized media. Go see how they improve your performance, see whether you like it with enforce mode on or report-only mode. We would love more feedback. And don't upload pictures from a DSLR directly to the web. Yes. And you'll hear Jason talk more about this a little later today. Right. All right, next we want to talk about instant loading. So how we get from super fast to zero milliseconds to kind of show you what exactly we mean by that because instant is an overloaded word, right? There's instant apps which don't do instant stuff. So let's talk about this. Here's a film strip you might be familiar with from like web pages or called web page loads. This one loads in eight seconds, right? And obviously you could make that faster. But when we... And we spent years trying to like peak out every little second that we can out of the film strip, right? Right. But we want this. We want basically everything go away and only that last frame to render right away. So we have a solution for that, which is actually relatively obvious. We have to like load that web page before the user clicks. But now you might wonder why I put a bathroom stall on the screen, right? So US bathroom stall has a little gap which like this... Introduces a privacy problem, right? Does anyone know why this is the case? Anyway, so when you load some other web page before the user said they wanted to go there, that web page might be able to like read your cookies, set cookies, stuff like that. And that's not something user expects, right? So we need a solution for that. And the solution that has been under development for a while is called web packaging. What it kind of provides as one of its features is privacy-preserving instant loading for the web. I want to explain really quick how that works, but we'll have a talk later today that goes into like actual detail from people who are working on it, which is great. So the way web packaging works is that you're a document author and you have a TLS certificate that we're using for HTTPS, something like that. And you sign that content to be created by you and then anyone can deliver it on your behalf where the browser says, okay, this was originally signed with that TLS key, so I can say it came from like example.com, because that was the original party. And I want to kind of drill down on this anyone can deliver it. So you could have a different CDN, but you can deliver it over like BitTorrent or IPFS. Doesn't really matter. You can do basically HTTP over anything, which is really cool. Oh my god, look at this. We collaborated with the AMP team on this because they're one of the frameworks that we're working with. And we're pretty excited about the instant loading and how fast we're going to be able to bring content to users, but Malta, what about the URLs? Yeah, it doesn't have very good URLs. So they're startwithgoogle.com. And with web packaging, that problem goes away, right? Which is really cool. So that's why we excited about it, but, and this is the important part, it's a web standard, right? And so with web packaging, we can bring instant loading to all these frameworks. And this is not an exhaustive list, right? It doesn't really matter, right? This technology is completely technology except. It doesn't care about technology, right? So really, really cool. We can't wait for this to land on browsers. Web packaging also addresses one more problem that I think is really subtle. Eric Meyer treated this and wrote this blog post, which is really cool a while ago. Traveling to Africa and noticing that, you know, HTTPS, which is the greatest thing happened to the web in a while among many other greatest things, actually introduced a few problems. So if you, let's imagine you're a cell tower and you're not actually connected well to the internet, but you have LTE to everyone connected to you, right? It's great if you have an edge cache at that cell tower. Now with HTTP, that's something you can build. With HTTPS, it's something you can't build. So you always have to go to the origin to someone actually able to serve on that TLS certificate, right? And the great thing about web packaging is that it can bring back that feature, right? Because it's untangling delivery from TLS security, you can get that all great benefit of having edge caching for HTTP, but have it together with the security benefits of TLS. Also wanted to just really quickly say that web packaging is not related to Webpack. However, there is a bundling spec coming up, right? And so web packaging is actually going to bring bundling as a first class feature to the web platform, which I think is also way overdue. And so bundlers like Webpack can eventually use web packaging as the output format. You can actually try this today. There's a sub spec called Sign Exchange, which is available in Origin Trial. You can go to this URL and try it out. Let us know what you think. Yeah. Later today, you'll hear Kanoko and who else is speaking? Yes. So the next bit that we'd like to talk to you about is scheduling. So anytime developers build something sufficiently complex, they end up needing to manage a task queue, prioritize work, and be sure that everything is getting done on time. So we don't run out of time on our talk. That too. A typical app has competing deadlines, so keeping the user input responsive while rendering smoothly at 60 frames per second and doing the actual work of fetching, preparing, and rendering the UI. In talking to the React team a few months ago, we realized that a framework-based scheduler has serious downsides. It can't schedule third-party code. It has a lot of difficulty interleaving tasks with browser functions like rendering and garbage collection. In short, it has to fight other systems for resources. With help from React, Google Maps, AMP, Polymer, and Ember, as well as the web standards community, Shuby and Jason, who you're going to hear from later today, are designing a scheduler that will run in the browser. It's meant to have high and low-level APIs like Grand Central Dispatch, so borrowing some ideas there, and be able to interleave code from all different sources. They're working on things like how do you interleave garbage collection or code that's in a promise. What's exciting about this in particular is that when you break things down into small tasks, it's much more useful if you have a great way to schedule them. When you can schedule things, they're much more valuable if you've broken things down into small tasks. This is where frameworks and the browser can work well together to provide a much better user experience than we're capable of providing today. This is one of the things I'm most excited to PM right now, and I'm really excited for you to hear from Shuby and Jason later. Right. It's really a good example for how frameworks help, because actually using your taking your code and breaking it down into small chunks, that's really, really difficult. But as a framework layer, this is something that people shouldn't just take a long time doing, but then having it for everyone. I mean, I think you saw in the framework awards section earlier that three frameworks, at least, are working on breaking things down into really tiny rendering chunks. So this is pretty exciting. Right. Next, we're talking about Animation Workflat and Jankfri Parlex, by the way, ironically, in front of a janky animated GIF. So Animation Workflat. First, we need to talk about other animation APIs, because there are a few. There's the Web Animation API, which is great, and you should use it. And also, more importantly, it just landed in Safari Preview, so relatively soon we should have it in most browsers. CSS Animations are also awesome, and they're basically everywhere, so you can use them. And you should use these APIs. And Animation Workflat doesn't provide additional value, except in some very important circumstances, because these APIs are inherently time-based, which makes sense. Animations go from A to B over time. That's kind of what they do. However, there are some animations that aren't time-based, for example, this one, which animates Pac-Man based on scrolling left and right. And this is something that's really difficult to do on the web today in a jank-free fashion. And then, so the reason for this is that with Animation Workflat, on the other hand, where you don't get jank, is because that actual Workflat runs super close to the actual software that does the scrolling. And so you can do it even when the main thread does anything busy, which is really cool. My team actually has been working on getting this into what we call scrollbot animations. And it was just a drop in a replace and it makes everything so much smoother. Surma is talking about this later today in the talk about Houdini. And you'll have some really cool demos. Yeah. Almost every web app eventually needs something like an infinite list. It just happens, right? On other systems, on Android, on iOS, there are things like UI table view. On the web, you're sort of left to figure it out yourself. Now, many frameworks have really good implementations of a virtual list, an infinite scroller kind of situation. But the web platform primitives make certain behaviors impossible. For example, have you tried to use find in page if you're using an infinite list? I often find myself going back to search for a tweet that I made or someone else made some time ago. You can't search for things that aren't actually in the DOM right then. This is obviously going to have accessibility implications as well. With new low-level APIs that we're putting into place, like searchable and visible DOM, all of the sudden, these things become solvable and get addressed. You'll hear more about our collaborations with React, virtualized, Angular, and Twitter in Gray's talk a little later today. All right. So that kind of brings us to the end of our talk, just kind of summarizing. We've been talking about our vision for framework inclusive web platform future. Instant loading and page transitions are coming to the web, especially if your designer get thinking about what you're going to build with that, because it's going to be kind of cool. And then we talked about a set of new low-level APIs making it easier to build reliably fast web apps. And that's especially true if frameworks help web developers take advantage of them by default. Thank you very much. Thank you.