go, which module can you switch out to fix a problem that you're having. It's a really good way to structure your app in this way. There's a lot of separation of concerns when we talk about HTML, JavaScript, and CSS, or when we talk about components in a modern framework. So it's another version of that same story, I suppose. Another benefit that you get, and we have heard about this problem a couple of times, I think, yesterday and today, is that we often see big chunks of monolithic JavaScript to just run. Frameworks updating the virtual DOM and then the DOM or something like that. And with this pattern, you introduce a natural breaking point to ship a frame. Because every time you send a message, that kind of is a point where you say, okay, browser can intervene and ship a frame if we are out frame budget. Exactly.  And we'll come back to this as a sort of repeating refrain that we're going to get into a little bit more. But think about actors as they're not all the same. They have different requirements. Some actors will not need to have access to the main thread, for example, because of the kind of work they do. And as such, we might be able to run them in different locations, not on the main thread. As I say, we'll come back to that. But the idea here is maybe we just bought ourselves a little capacity for rush hour. Because as long as the messages get delivered to the actor, the actor will then do the same work a little bit before and will respond with the same message. So the entire app keeps behaving the same way no matter where it runs. And because of that location independence, we can lower the likelihood of long work impacting the main thread and making your app janky. Exactly. So, conceptually that's what it is, but I think maybe it just does, but I like seeing code. I think code helps. So we have we're not launching a product. We're not launching a framework or even a library. We just wanted to have a chat with you about architectures. And we've been using some actor based stuff for the last little while with our colleague Tim. And the three of us have just been putting some code together. So what we're going to do is we're going to just show you a little bit of the code that we've been using. We've been using it to build some of our apps. And we'll share that at the end. And you're very welcome to try it out. You're also very welcome to write your own. We don't really care if you use our version or someone else's version. It's more about the concept, about the architecture. Absolutely. But with this in mind, let's talk about a particular app. Something like a stopwatch app where you can pause, play that kind of thing.  So in our code, we have this actor based class. And that top function up there, hookup, is the first thing that you'd need to know. And the job of hookup is to kind of register an actor in the system so that we can talk to it later. So we can send it messages later on. Because ultimately, we won't know where this actor is in the system. And so we just need a, it's like a registry, where we can say, I'm going to tell you there's an actor and it's found under this name. It's basically the equivalent of what you might know from custom elements. There's custom elements.define and you say, this custom element is now known under this name and this does the exact same thing, but for actors. Cool. So then we have our two actors, a clock one and a UI one. And then in the bootstrap, we instantiate both our UI and hook it up. So it's available under UI as a string name. And it's also available with the clock. Like so. So now we can talk about how you might implement something like the clock itself. And in our case, when you've got something like this, it's almost like a pure data actor. It doesn't have any need to go near the DOM. It just wants to tick and pause and all those kinds of things.  You need a set interval and that's pretty much it. Is that time out? Sure. I have a thing against set interval. Can we find me after this? I'll explain why. Anyway, imagine this then. We're going to model this as a state machine. What an idea. We start with a paused state. Our clock is paused. We can transition to a running state. Every second we'll tick and we'll go to the tick state and that will take us back to the running state. And you can imagine being in this kind of tick-running-tick-running state like a clock, like a clock. Indeed. We could pause and we could reset and when we reset we go back to that. And there's a really nice pattern here that plays along well with the message passing of the actor model because all of these triggers as they're called in the state machine world could just be a message. You send a message to this state machine, it's being ingested and then a transition happens. Absolutely. So we found actually that there's a lot of implementations for state machines out there in the wild and that's not very unexpected. And we've kind of been using X-State written by David from Microsoft and it's working really well. It allows you to declare your state machine as a JSON object to just declare your states and then what the transitions are and then you kind of just pass this to this machine constructor and you get a state machine. Yeah, so our clock extends the actor base class and what we do is we instantiate our state machine. We say go to the initial state which happens to be that paused state. And then later on imagine that we receive a message and the base class has this onMessage callback which is, I got a message, what do I do? In this case, we would assume that the state would be changing inside of our state machine. So we use the state machine transition to get from wherever it was to wherever it needs to be. So the message is basically driving the clock. And we'll inspect what the new state value is. So if we find that our clock is running, we'll set a tick timeout for one second. If we tick, we increment our tick count and then our clock will send itself a message. Now, it could call its own functions, but we tend to be a little bit, we like it fair. And so what we do is we make sure the clock sends itself a message like every other actor would have to send it a message. You can imagine like a message queue that buffers all the message and the actor goes to one message, processes, then goes to the next message. And so if you just call your own function, you would kind of be cutting that line. So if you want to keep it fair, you would just be cutting it off. And it's not a matter of if you want to do it correctly or a computer. Sure. Yeah. Okay. Cancel the tick if you're paused. If there's one pending, when we reset, we'll reset the tick count and again send the clock will send itself a message to pause. And now let's talk about, oh no, talk about sending messages. That's next, yes. So the clock is going to have to send a state update to the user interface so that it can reflect the message. And then we can send it a message. And that's very important to note here, the handle, this UI variable that we have there, it is not the actor instance. You can't go in and change a member variable of that class. It is just an object with a send method and only that method because that's the only way you're allowed to interact with any of the other actors. Exactly. And so in this case, we're going to send a message to the user interface and the message is going to say what the time is and whether or not the clock is running. We found that TypeScript is really helpful at this point because those messages need to be well-formed and well-understood and there needs to be a data contract and we've just found from practical experience that TypeScript is a really good way of saying this object looks like this, this is a number, this is a string, this is another object and so on and so forth. So just take that as what it is and we found that useful. Let's talk about the UI a little bit. Interestingly, you can bring your own framework. Yeah, in this model, we don't really care what kind of framework you use. You can use React, you can use View, you can use Lit, you can use Svelte, whatever you feel comfortable with, whatever makes sense in your scenario. The interesting shift here is that the UI framework is not your base platform, not your entry point anymore. The center of the UI is not your platform, it's not your platform. The UI is just one participant of many in the system of actors. And if you find that it's not behaving well for whatever reason, you can swap it out. The only thing it has to do is listen to messages of a particular type, which is kind of cool. In our case, we're going to use Preact, which is great. So we're going to import Preact, UI extends the actor class and when we do that, we're going to send messages back. Absolutely. And to do that, it is a case of the, on the UI side, we find our clock actor, we do a look up on it, and we will send it a message. In this case, for this particular example, sending it a message to start, but there will be one for start or reset and so on. Now we get to talk about that location independence a teeny bit more. Because one of the questions that Sirma Tim and I ask is, why does the UI actor need access to the main thread? And this is kind of to do with the rush hour thing. Our general rule of thumb, and there are some caveats mentioned in a moment, but our general rule of thumb is that the UI actor is the one that really needs the DOM and therefore it's the one that ought to be on the main thread wherever possible. There's an exception. The exception here is that certain APIs, those for media security device capabilities and identity are only available to the user. So we're going to talk about that in a little bit of a bug. We've been talking to some Chrome engineers about exposing these kind of APIs in a worker and somewhere else, but that's just not the world we live in today. So for now, that's a restriction. And tools not rules. So you might be thinking, ah, I should move all my actors away from the main thread. We'll get to that. But the thing is, if you've got a little bit of a problem with the UI, there's a cost to the thread hop, and that might be more expensive than just sending a message and just keeping the actor alongside the UI actor. So basically, if you want to do that, just measure and see what the impact is. Exactly. So the location independence, for all that notwithstanding, imagine we were back here where we started with our four actors, and they're all on the main thread, which is probably a little bit different. So we're sort of saying you might want to look at it more like this, and you might be thinking, why did they say not main thread? Surely they just meant web workers. And we kind of did, because in most cases, when we build these apps, web workers do feature heavily. We do move quite a lot of our actors to web workers, especially if they're non-chatty. But not quite. So we actually think that it's possible to run an actor, for example, on the server side. And this is kind of an interesting jump to make, because it allows you to incorporate your back-end into the architecture of your entire app. It is just another actor in the system. And as a matter of fact, the game that you've been playing all day, and it totally had no bugs at all whatsoever, is actually written in this model. So every player that is playing is an actor. The admin panel that the MCs are working on is actually running on the server side. And this is another actor, and then the Firebase storage and shared actor that's running on the server side. Interestingly, the mechanism by which they chat using the hookup and lookup can be anything. It could be fetch, it could be a web socket. It really doesn't matter. So long as they can talk, these actors can talk, and they've got a way of sending messages to one other actor, and they can send messages to another actor. So that's one thing that we definitely did achieve, is that we are kind of making it less likely to have big chunks of uninterruptible JavaScript, and more little chunks where the browser can stop in between and ship a frame. So that's definitely one advantage that we have. The location independence, hopefully some of our actors can be run successfully away from the main thread. So that's one of the things that we have to do. A lot of work that can happen in an unexpected way if you're processing a big API response something that can happen in a worker and not affect your main thread from going into jank mode. There are some other benefits that Tim and I have noticed as well working in this particular pattern. One is better testing. The other thing that we have to do is send a message that I can call, and I can make sure that you do the right thing. So the testing seems to become a little bit easier. From the other side, you can mock another actor by just implementing the messages that that actor needs to receive, not do the actual work, but just send pre-recorded messages back. You get the clear separation of concerns. Which, again, it helps you in making sure that you don't have to do that. Which actor needs to be responsible for this part of the system? And you get the code splitting. Because you have actors that can be hooked up to the system at any point in time, it allows you to split them up and load them lazily. You can import them when you need them. That's good. And bring your own framework. If you want to use a particular thing, use it. Great. Now, there are some considerations in this world, in this setup that we've described. One is actor performance challenges. If you imagine your UI actor, imagine it decides to run long and just be not very yieldy, you still have that problem. It's no different to a process or an application in an operating system deciding it's going to hog the CPU. This is not going to go away. But we do think that the way that Jason and Shubby mentioned in the previous talk is a huge part of this story because it's a great way for individual actors to start breaking their work up into smaller chunks. You may also be sitting there going, I'm not sure I could actorize my blog. And we would agree. It's not necessarily for all use cases. This works really well when you've got apps and in particular apps where you think, actually, yeah, I can ring up some kind of owner for it. That's where it works really well. And there's definitely a different mental model to this. As I said, it kind of shifts the center of the universe away from the UI framework into many center pieces. All the actors just communicating. So it definitely took us a time to build an intuition for where do we draw the line? What becomes an actor? What is just part of an already existing actor? What kind of messages should we send? How do we do that? If you're playing around with this, it seems weird at first if you're playing around with this. It's a very different way of architecturing a web app. So that was the rush hour bit. That future faces of the VR, AR, and so on. We have some thoughts there too. Watch this. You were talking about actors before. I want to talk about cameras. The reason I want to talk about cameras is that the modern camera has two bits. The camera body, which is the thing that kind of holds the state, whether you're shooting in JPEG or RAW. It's like the business logic. It knows how to take the picture and how to store it and does all that. Whether you're shooting video, taking photos, whether you are autofocus, manual focus, you get the idea. Similar to like a web app, right? That's the state of what's going on. But you've got to be able to take something of a landscape. As long as we make sure that the mounts are compatible, which I guess in actual work means that they speak with the same messages to each other. Yes. So the messages that they sent are really important. They're sort of standardized, right? And everybody kind of plays to that same data contract. Other than that, you can do what you like.  Last video, I promise. Yeah. So, camera lenses. Why camera lenses? When we talked about this earlier, I think very naturally we would have all thought of the DOM. We would have thought of in the chess game, we would have thought of this version. But there's the freedom that you get from a UI actor, that it can, as long as it can speak the right messages, it can be implemented in different technologies. So you could have a different actor that does 3D. And now you get that. It just has to send the same messages to each other. Similarly, it needs to be able to do that. Send the right messages. And perhaps something like voice as well. Similar kind of story. So as a byproduct of the actor model, we've all of a sudden got these different swappable UI actors that we can take with us wherever we need to go. And you might say, well, actually all I need in this particular app is the XR and voice. Or maybe I want DOM and voice. And one DOM actor that implements the same app, but with a much less intense memory consumption version, like a low end version of your website. And once you detect that the device we're running on is actually kind of struggling to keep up, you can actually switch it out in the middle of the app and downgrade to the lower visual version. Or one with reduced motion or something like that. And technically this will be called multi-view or multimodal, which is something like that. And as a byproduct, we think the actor model enables you to do that pretty well. So if you're interested in looking at the hook-up and look up in the actor base class that we mentioned earlier, this would be the place to go if you want to take a snap of that. This is actually not only the actor base class, but it's actually a boilerplate. So it gets you started. It's roll-up configured where you can just build it, does the code splitting, the stomping ground that we've been using for the last little while. And we'd love you to take a look and have a chat with us and just tell us what you think. So in summary, we're actually quite excited that something from 45 years ago has kind of come full circle and is it seems to be the thing that respects... It's hiding in plain sight. From some other places in computing, we've kind of brought it over. Not in a purest way. We have our own take on these things. But it respects that single threadiness and it seems to help with rush hour and it also seems to enable us to go multimodal, which is really kind of exciting. And on that note, thanks. Thank you very much. Thank you, Simon. Paul, I've been told my co-MC from last year, Monica is in audience. Where is she? She might have just... Hi, Monica! Oh, good. Everybody say hi to Monica and talk about machine learning and art, okay? I'm really jet-lagged. Do you want to just take over?  It's fine. How do you feel that it took, like, not one but two white guys to replace one of you? I'm sure there's some social commentary there. All right. It is lunchtime. Excellent. Same as yesterday, lunch is out, like, over by the forum. Any specific dietary requirements, they're all catered for there as well. And then come back here at 2.30. See you then. Pinterest's mission is to help people discover things, collect them, organize them, and then find ways to apply them in your life. With more and more people on the go, the mobile web has become central at providing our discovery experience. But our mobile web experience in the past was basically an upsell for the native app. Which brought us to the realization that we needed to fix it. The technology was already in place for us to be able to do so. And so we brought a team together to rebuild the mobile web from scratch. Having a fast mobile web was crucial to the success of the project. We made sure that we split out what was sent down to the user to be only the crucial things to start and then everything else that wasn't immediately important sent down later on. We made sure to test out on average devices on 3G, just like our users would be using. And we could see the dramatic difference that there was on that initial time to interactivity. By using modern caching best practices and service worker, even if you're on a bad connection or have no connection we were able to preload the user interface for follow-up visits. Like the native app, our site was optimized for touch interactions. This immersive experience resulted in mobile web becoming our top platform for new signups. We wanted to make sure that users for our mobile web continued to use the product as time goes by and one of the most important technologies that's been added to browsers was the ability to add that site to your home screen. Pinterest is not just about the content, but about what you do with it. The browser is a discovery platform so making it easier for Pinterest to use our own discovery service is really a perfect fit. And action! This is designer versus developer that explores the challenges that we face in industry, such as the convey about its designer works on something developer takes it and developer screams. Creating software that's not frustrating is actually hard to do. If you put all the work in, no one should realize anything actually happened at all. How you go about doing that is a good question. You're basically trying to hack human perception as much as you can. If you make a developer guess how to design a site, we're going to guess really poorly. We stop at this data level and we don't go through this extra step to make some more art on top of it to make it extraordinary. Does it feel like you're breaking the web? There's no point in implementing a feature if no one's using it. That's it. You can find these and more on the Chrome developers YouTube channel. I feel like I'm being trolled by that music. No, it's going to happen until we all die. That's how I feel. Wake up in the middle of the night hearing. No, no, no, no. The worst bit is when you're backstage and you can hear just a little bit.  Head to my head. Anyway, lunch, awesome though it is, can make you feel a little bit sleepy. Yeah. So we thought we need a way to wake everyone up and I've seen some conferences do the thing. The exercise thing. Get everyone to stand up and jump up and down. No. No, we wouldn't do that to you. But we would do a quiz. We'll do a big web quiz. Yeah, let's get the screen up. I am super fond of this question. This is our favourite, isn't it? So there's a couple of changes here. We're going to give you four seconds per question, a little bit longer than usual. And it's also two points. They're all points because it is quite exciting. And I will explain the rules to you now. True or false? Off you go. So what are we looking at here then? Low confidence I think is what we're looking at here, buddy. Yes, we are, aren't we? What is that? An array, not an array, plus two equals 22 as a string? I don't know. Empty array? I don't know. Is finite zero as a string? Does na equal na? Sounds like it should. Is this array one again? Or is it different this time? The first one was a not array, wasn't it? Is na equal false? Now you see why you got four seconds. Number is finite, we had is finite zero, but we know that number is finite zero. You were going to tell me there's a different, aren't you? Coversion. Yes. What are they different? We'll find out. Oh, okay, fair enough. We've reached the end of that round. Let's have a look. Honestly, if you're programming driver's license, I would say certain people might need it revoked. We came out yesterday and we did say, hey, don't worry about these silly questions. Don't worry about if you're getting them wrong. I think that first one, really, it's a bit of a worrying sign, if I'm honest. Okay, so they are all false except just the object, I guess. Object is truthy, which is truthy. That makes... That is truthy. Hang on, what's going on with this array nonsense? What's this array plus two plus two? I have no idea. Excellent, let's move on to the next screen. So finite zero. I love it when it's just almost 50-50. It will be true. That's true. Zero is a finite number. It is finite by itself. It's happy to coerce the string to a number. Okay. I guess we saved that piece of knowledge for the next screen. Okay. It's not the same as nan. Good to know. Okay. It's also type of number, not a number. What? Yes, it is. So this time, because of the coercion, it's a number equals a string. It's true. Hang on, what's going on here? Is that true? I don't know. Are we going to double check that? No. No equals false is false. It's false, excellent. That one is right. And then the final set. So we've got number is finite here. So you're saying that should be false. Is this false? Because it won't coerce the string to a number and it'll look at it and go, that's not a number and it's not finite. So no. The not not false in strings, because it's false in a string, but it's true again. Not stringy true. Which is saying the word false. Sure. I'm not feeling any more awake than I did before lunch. But are you feeling deep sadness? Well, I always do. Even more so now. Should we take a little look at the leaderboard? Oh, I think we ought to. I just like the animations you've done on this screen more than anything. Right, who we've got here. Also some CSS blend modes. We've got two people featuring from the leaderboard yesterday. Liz has stepped up from, I believe, third to second. Will has been in first since the start. Good luck catching up. And Arrives in third place. Excellent stuff. Can they stay there for the finale? For the ultimate prizes? It's all up for grabs. Oh, okay. So we should get the next speakers on the stage. So here to talk about web packaging and portals. Let's have a big round of applause for Kaniko and Rudy. Hi, everyone. I'm Kaniko. I'm the tech lead of a loading project for the web platform in Chrome. And I'm Rudy. I'm the lead product manager for AMP at Google. This presentation is a developer preview of two upcoming APIs, web packaging and portals. With these APIs, we believe that you'll be able to take the web flow friction nature to the next level and create zero-friction user experiences. Thank you. Thank you. Thank you. All right. So here's a slide showing a slide. To be more precise, this is one of those old-school projector slides. In their day, slides like these were a useful way to communicate or held important memories for people. To view the slide's content, the projector needed to mechanically position it into place so that the light source would shine through it. And you'll probably remember how tedious it was to progress through each slide. This kind of makes me feel like how we think about the web today. The same feeling. Just like progressing through cylinder slides, when you browse the web today, you can feel all the navigations. Today, the web is used a lot on the go. Say in between meetings, in an elevator, or maybe you're on a poor connection. When I've got limited time focused on my phone before the next distraction comes along, spending five seconds or longer staring at a white screen, waiting for the content to come in, for the page to be interactive, that's incredibly noticeable. Many of you may have observed we use some exaggerated long transitions on our own slide so far in this talk. Don't worry. We're going to put it into that soon. Those were just one-second fades. We're going to do a little bit of reading and then waiting, reading and then waiting that we've kind of grown used to. We think it's time to do better. We have some ideas to help you create seamless zero-friction user experiences. That's what this talk is all about. So, I decided to see seamless user experience on the web. It's not new. In 2013, back in 2011, we launched a feature called Instant Search, which provided user experience. So, by rendering the search results, the user would most likely click on. However, the feature only worked in limited scenarios for various reasons, in particular, for privacy reasons. It only worked for the search results the user had already visited and for which we had high confidence of user interest. Then, in 2015, another example of such user experience was launched. So, in 2015, the user experience is going to go through what it took and where things are headed. So, as Kanuka said, advancing the state-of-the-art and page loading has always been of intense interest to us at Google and for Google Search. We point users to a whole lot of web pages and thinking about the totality of the experience that the user gets, we really wanted to feel as fast and as seamless as possible, even using the full power of the web platform that was available, but where we wanted to get was here and we felt that what we could achieve on a scalable way on the web kind of just got us up to here. So, we gave it a bunch of thought and came up with an architecture for instant loading that could work on today's web. It's still what we use today. First, there's the AMP JavaScript library. It helps to ensure that the experience is fast by default and this is enforced by a validation step that the site is getting updated. The next layer was thinking about how server response times can vary a lot globally and not every site is situated on great infrastructure. Also, as we've seen earlier, sticking huge images into pages intended for mobile viewing is still pretty common. So, for these reasons, we added the second layer of caching where we can ensure that the content is pushed to the edges of the network for faster delivery and we can do common sense optimizations. Truly, the best thing we can do to get load times down to zero milliseconds is to pre-render the content, use our psychic powers. As we just discussed, this was attempted in search before with instant search, however, you need to think really carefully about the privacy implications of such a design and we had trouble scaling it. The cache will actually help us complement this pre-rendering very well and Kanuku will explain more about that in a moment. Now, let's take a look at the URL of the AMP page. This is where we ended up and this is where we ended up. Most of what you're looking at here is what we call the AMP viewer. That's the page you're visiting. It's responsible for displaying the content, serve through the AMP cache for speed and privacy reasons. However, you'll notice by looking at the address bar that the URL is still saying Google.com in it. To help the user understand where the content they're viewing came from, the URL was achieved, but the design constraints that we faced and the workarounds that we had to build for them ended up being put on full display in the product experience and that wasn't great. We hear a bunch of feedback on this, maybe even from some of you. Earlier this year, we started down this path to make the URLs for AMP pages better and after having AMP in the wild for two years, we decided it was time to take all that we had learned and develop the necessary primitives so we could make all the content across the web be able to benefit from this kind of technology. So this means that for the cases where you click on a link in search and it's just a simple navigation, then we want the publisher's URL to be the one that shows up in the browser's address bar while still having the instant or nearly instant loading experience. So I already talked a lot about how AMP has been pushing the goal of highly optimized user experience. There was a lot of special handling required because of the gap in the web platform. We are now taking inspiration from past efforts like AMP and Instant Search and trying to eliminate this gap by extending the web platform. And by doing so, we also want to enable this zero-fiction user experience across all content on the web. We are working on multiple proposals to achieve this goal, but in this talk, we will introduce web packaging and portals. So let me start with web packaging. As the name implies, it's meant for packaging a piece of web content. We think we can enable various interesting use cases, but let me start first explain how it can help instant navigation, both for AMP and non-AMP content. So stepping back, we've long wanted to make web content load instantly and reliably. Here's why it's hard. When you publish something on the web, in the simple setting, you would have a server and your content would be a project there. Then someone brought your content, but the server might be overloaded and your content will load slowly. Change experience is not good. So what could we do to improve this? One way would be to fit your content. Suppose that your content is linked from a popular traffic source site. When a user visits site, it can trigger a prefetch when it thinks that the user is about to visit your content. Then, because the content is already in the user's cache, the navigation happens very fast. Unfortunately, the prefetched website can learn about the user's interest, even if they don't visit the website. One way to fix this would be for the referral site to add a cache here. Then the referral site could bootstrap your page load in a privacy-preserving manner because it could let the browser prefetch your content from this cache. This fix the privacy concern and the content loads instantly. So is this the holy grail? No, not yet. As Ruthie explained, this design allows you to bootstrap your content in full display in the product. The browser address shows the URL of the referral site instead of URLs because this is where the browser thinks the content is coming from. This is confusing to the users. The issue is that the web platform doesn't provide a proper way to let others bootstrap your page load.  This would let traffic sources bootstrap your page load and when the user navigates, it's just a regular page load from your servers, only much faster. So how can we achieve this? The browser needs a way to verify the two original resources that are served by a fast cache. This can be done by adding a proof of origin in the browser. So let's see the actual standard proposals. Webpackaging is not the name of a single proposal, but an umbrella concept for multiple spec proposals. The most important one is the sign exchange. It's basically a format that represents a single HTTP exchange or a pair of HTTP request response. Very simple. It's digitally signed so that the user can use it. There's another proposal building on top of signed exchange called bundled exchange. This is a bundle of exchanges that can represent multiple resources in one package, like a whole web page. We think bundled exchange will enable other interesting use cases while we start with signed exchange, since that's the key building block. And after a year of work, we will be able to implement the project. This is an experiment of the feature on Chrome 71, which is in beta now. You can play locally with it by enabling a flag or can join the experiment to enable it on your site. Please visit bit.ly to find out how. We'd love to get your feedback on this. That will help us improve this feature more in the future. This is an experiment of the feature on Chrome 71. You need to first acquire a certificate that can sign exchanges. And host it at a public URL. Such a certificate can be created at Digisat today. Once you do that, you can generate signed exchanges for your resources by using an open source tool. This process is fairly manual, but it also includes platforms like Google. We've gone ahead and enrolled Google. We'd now like to show you a demo of using signed exchanges for delivering AMP content from Google Search. To walk you through it, please join me in welcoming to the stage Sumo from 1-800 Flowers and Rustam from Cloudflare. Cool. Thanks, Rudy. AMP has provided a prominent pathway for user discovery of Google Search. We've done a great job of discovering speed to engage in thanks to an active developer community and thanks to a roll out of new web components. Web packaging further deepens the experience of providing a native UI while serving the benefits from the AMP cache. Today, we're excited to demo an example of web packaging live. Are you ready? Check it out. We're going to show you a demo of Google Search. You can see that Google Search is prominently featured. You know instantly that this is an AMP search unit. Click on it or tap on it. Instantly, as Rudy is mentioning, you see that there's no Google in the URL which is pretty key over here because now you instantly feel that you're natively on the website versus being on a website. You can see that you're actually on this case when you have flowers.com. Furthermore, having attribution so seamless adds to a much more confident realization for a lot of brands that now there will be absolutely wonderful attribution going from the SERP to the native site. And a big shout out really to the Google team and to the Google mobile consultants team. We've really been pushing the boundaries of UI, UX, enhancement and really making sure that the web is taking all the strides possible to go to the next level. Rustam, you want to go through how this works? Sure. Thanks, Jamal. Let's look under the covers and talk about how you would actually deploy something to support sign exchange. At the top here, in green, we have the request flow from application and proxy to your user's device. On the bottom, you have the request flow into the AMP cache. And in between, you have an AMP package. This prepares the documents for the cache and signs them to support signed exchange. Now, at Cloudflare, we sat down and thought about how to use our global programmable network to make this all simpler. And this is what we ended up with. We took all the logic necessary to use Cloudflare Worker. This sits at our edge and supports both the cryptographic operations, the packaging operations, and the logic necessary to arbitrate between the user and AMP cache request flows. So you might be asking, what's a worker? And simply put, it's V8 running on the edge. This allows you to write JavaScript targeting the service workers API, deploy it to our edge and have it running instantly in 155 locations. Supporting signed exchange is a great example of what workers is capable of. So in addition to releasing the code that supports this demo so you can build your own workers to try signed exchange, we also plan on building a full-fledged Cloudflare feature to support it at launch. Back to Rudy. Thank you, Sumo and Rustam. If you're publishing AMP content, we'd like to invite you to try out a developer preview of signed exchange AMP content in search using the web browser. You can learn more about creating packages and building an end-to-end flow like you just saw for your own AMP content. We've seen the benefits that signed exchanges bring to AMP publishers, but it's important not to forget that this will also benefit all pages on the web too. Now, I want to show an additional example, a regular cross-page navigation on the flow network, the content will load slowly on the page. The right side shows how it can be done with a prefetch with web packaging. You can see that the user is navigating to a page on a different site, instantly. The prefetch is down from the cache of the referral site, so therefore done in a privacy preserving manner. So, publishing how to use web packaging to realize privacy preserving instant navigation. It still feels like we're progressing through pages as this joint experience, not a nice seamless experience. And we've been wondering how we could improve this even further. And let me introduce our latest proposal, portal. So, let's see what we mean by navigation versus transition. Maybe it's not too surprising. Again, this shows a regular navigation. This loads slowly depending on connectivity and the flow. And the right side shows an example of a transition, as you can see. When the user taps on the article, a nice and smooth animation triggered, creating a sense of continuity. The navigation just happened without being felt. The navigation is so subtle that it's worth taking a closer look. As it can be seen from the address bar, the user starts their journey from a page on the page. And when the animation is finished, the user ends on another website, news.toro.jp. So it's a cross-site transition. Combining portal and sign exchange enables these types of user experience while preserving the user's privacy. You might not be interested in it, but portal is now limited to cross-website navigation. Let's take a look at how it can improve the user experience. I would like to thank Hatena Young Jump webcomics, our partners in Japan, who we've worked with to create this early exploration for their reading manga on the go website called Tonalina Young Jump. So let's see the user experience without portal. When you reach the end of the chapter, you see an instance of it. As you can see, it takes time to load the next chapter. That's because the website is using multiple-page architecture, and it needs to load a new page for each chapter. Now, let's see how that could look like with portal. At the end of the chapter, we can preload the next chapter and make the transition seamless. Pretty cool, right? The beauty of this is that you can achieve this smooth user experience without having to run the page. So, what are the portals? Portals are like iframes. You can create one as an embedded element of a page using portal tag. At this point, it looks pretty much the same as an iframe, and then navigate to an element by calling an activate API. When that API is called, the element is detached from the page and becomes the new top level version. You can also add animation to smooth out the transition. So, what are the differences between portals and iframes? The biggest difference is that portals can be navigated into. Another interesting difference is that portals are always created as top-level version context, while they can still be embedded in a page like iframes. Let's recap the benefits. Portals enable seamless page transitions like what you get with single page apps, but without having to react to your site, and even across different origins. So, you can just build your website using multiple pages, and can connect them with portals. So, here's the example called snippet of portals. You can create a portal as an HTML element, and then can append it to the page to have it embedded. Then when the user touches the embedded portal, you can add a nice animation and activate the API to make the actual transition. That's it. Exciting, isn't it? And you probably want to know the current status. We have an explainer on the GitHub. Visit between portals to learn more. Chrome implementation is in progress. We are aiming for an origin trial next year, and eagerly awaiting your feedback that will help us find this proposal. So, that's basically all from us about low friction to zero friction, but I have one more topic, bundled exchanges. So, remember that we hinted that bundled exchanges earlier. They allow multiple resources to be bundled in one package, and you might be wondering if about the current status of development. So, while the Chrome team has started building a prototype to build this, we think this could enable interesting use case scenarios like offline PWA installation and much more. Here's an example of a newsreader PWA. This is based on TOYDEM readup built by one of our awesome development folks, and now runs on a custom Chrome build to use bundled exchanges. The app allows the user to read news articles in a reliable way by letting the service worker download and save the articles as bundled if the news sites provide them so that the user can later read the saved articles from multiple sites even while offline. Note that the articles are still shown as coming from the original news sites, and the sites keep maintaining the control over them. Here's another example. As you may know, loading a large number of resources costly and bundling them in one big JavaScript file using bundled exchanges is a very popular technique. We did an experiment to see if bundled exchanges can be used there, which could allow the browser to process and cache individual resources in the bundle without executing the JavaScript. And one of the results looked like this while still preliminary. It looks promising. We think there's some potential, and we want to know what you think. Let's go back to the main topic of this talk. We talked about two new proposals for zero-friction user experiences. First, web packaging enables privacy-preserving instant navigations, and second, portals enable seamless transitions between pages or sites. Combined together, two enable zero-friction page transitions on top of any web pages, even across origins. Here's a look at our roadmap. Appliance to ship signed exchanges in the middle of 2019 and also to start an origin trial for partners sometime around then as well. For Google search, we're really excited about both signed exchanges and portals as a path to building more zero-friction user experiences across the whole web. Following the footsteps of the demo you just saw earlier in AMP, we'd like to launch support for AMP signed exchanges next year. We're also actively working on how non-AMP pages can adopt these same technologies for user experiences. We believe that we'll eventually just have highly optimized content on the web, regardless of whether it's AMP or not, with all the standard work we're doing today. And we've been engaging various partners as well as other browser vendors because we want to refine what we have, and we want to make sure that it will help them and the developers like you achieve highly optimized user experiences. For instance, such as Google, Google, content publishers and web developers at 1800 flowers, CDNs and certificate authorities such as Digisat and Cloudflare, as well as folks working on the decentralized web at protocol labs. We hugely rely on your feedback and are eagerly awaiting to hear what you think. Here are the important links that we referenced and that you can check out to learn more about. You can also come to the Ask Chrome area in the next break and we'll be there to answer your questions. We're really excited about the future of the web and enabling the kinds of experiences that we showed today, and we'll appreciate your help in joining us to move these technologies forward. Thank you. Thanks. Big web quiz time. Yes. Get your phone or laptop out. Right. Who's heard of the window? Yep. Document. You heard of document? Cool. This one is also known as window or document. Yeah. Yeah. You ready? Ready? Not yet. I'll give you a few seconds. Do the little done. Getting ready done. Before your entertainment. Huh? All right. Starting the round. Ooh. Title. Window. Dot window. Dot what? Is window on window or is window on document? Is document on window or is document on document? Hmm. Implementation? Title. Does title belong to the window? Ooh. Is secure context? Hmm. Well, the confidence is fluctuating a lot. Not beginner. No, no, no. It's changing a lot. Wow. Webkit is full screen. Sure. Sure. Has focus. Does a window get a focus or document? A few seconds. And low confidence. I'm not surprised because I don't think I know half of these either. I don't know. Right. There's a lot of chattering in the room. Yeah. How to make yourself unpopular as an MC. Ask really horrible questions. Okay. Title. Document. Window is on window. I think we did this yesterday because you can have window. Window. I will do that for hours. Probably not on request. Document. Of course it is. Why wouldn't it be? Is secure context. Everybody is very split. I'm sure of that one. Okay. Interesting. It's window.navigate. Yes, that makes sense. Good. And device pixel ratio. I'm on the side of the people who said window. Having written a lot of canvas code. Yes. Webkit is full screen. It's on document. Isn't Webkit the window though? No, the window doesn't go full screen. The document does. Yes, that makes sense. Oh, the web. Right. I always get this one. I always have to search mvn. Maybe it's because I do terrible code. I know it's on window. Window.getComputedStyle Document.all Is that a live node list? I think it might be a live node list. Honestly, I mean window or document. Who doesn't ask themselves that every single day? Everybody in this room. That's the answer to that question. Right, our next speaker. You've seen him quite a lot already. I know, right? Again. I want to be on stage. First name, the. Ladies and gentlemen, Das Zorma. Hello, everybody. Yes, it's me again. Prepare for more bugs. I'm trying to get the clicker working. But it's not. There we go. Apparently, my name is Zorma. Good. I'm excited to be here. You reached a point where with Houdini, I can talk about actual APIs because they're starting to land. And that's kind of really exciting. But as with any talk, I kind of have to start with what Houdini is. On my Twitter, I often see confusion. There's a software called Houdini. Apparently a magician that was called Houdini. So I kind of want to clear up what Houdini really is about. So every browser has more or less four major stages in the rendering pipeline. It starts with styles where the browser collects all the styles in the document and then figures out which element is affected by which of these styles. And now we know with the height, and if it's flexbox or grid, which style is on which element, we can do layout. We can basically calculate how big an element is and align them on the page and get boxes on the page. They're so empty and transparent because in the next stage, we can take that layout page and paint it. Just draw it. And we can draw it all on the page. Sometimes elements get on their own piece of paper, which is called a layer. And once we're done painting, respecting things like background color or border color, we can give all of that, all these pieces of paper to the compositor and kind of put them together into the page that you will see on your screen. And if something was on its own layer, we can move the pieces of paper around and that's how animations are made. I mean, that's obviously kind of a shortcut, but you can kind of see where I'm coming from. So bringing it back to the question, what really is Houdini? Well, Houdini is a standards effort in the CSS working group in the W3C to expose hooks into these major stages of the layout phase to the developer, to you. So you have more control, not only over the visuals, but to write better polyfills and have more control over how your page just appears to the user. It is hard because these four stages are different in every browser. Sometimes they're even parallel or not even that clearly separated, but we're working with all the browsers to make sure everybody can implement these APIs. Houdini can be super intimidating at first because under the Houdini umbrella, there's a lot of APIs and you don't really immediately know what to do with what, but they actually kind of form a hierarchy. So you have four high-level APIs, four major APIs that basically represent those four major stages of the rendering pipeline, and then you have a couple of lower-level APIs that build the underpinning the basis for Houdini and that make these higher-level APIs possible in the first place. The workloads are really interesting. Worklets are kind of the Swiss Army knife within Houdini for performance, and so I want to make sure I take a second to explain these because we're going to use them for the rest of the talk, and more importantly, I want to distinguish them from workers because lots of people confuse these two, and I can't blame them because they sound very similar, and in fact, they actually have a lot of overlap, but there is a couple of very important differences that I want to explain to you, and I have to talk about the event loop. This is an event loop, and if you don't know much about the event loop, that's absolutely fine. Everything that you need to know, I will explain to you today, but if you want to know more, I really recommend watching Jake's talk about the event loop, which you can probably find on YouTube if you just type in his name and event loop, and actually I'm using a lot of his visuals in this talk. So this is an event loop. It's a loop, and it processes events, and it's called an event loop. Whenever an event happens, the JavaScript engine checks if there's a handler for this event in your code base and then takes the code for that handler and queues it up, and every turn the event loop takes something out of the queue and runs it, and then in the next turn it takes the next thing out of the queue and runs it, and that's obviously super simplified, and there's much more nuance to this entire thing, but that's kind of how an event loop works. And in this world, a worker would look like this. It's a completely separate event loop. It's an isolated scope, it has its own handlers, its own events, and they have nothing to do with each other. They might be able to put a task into the other loops queue with post message, but that's pretty much it. And there is considerable cost to spinning up and maintaining an event loop, and that's why you can't just spin up a thousand workers and call it a day, because that's actually quite costly. Worklets are different. They're also isolated JavaScript codes with their own scope, but worklets don't have an event loop. Instead, they kind of attach to already existing event loops, and that makes them a lot cheaper to create and maintain. You can even attach multiple worklets to an already existing event loop, and because most worklets are specified to be stateless, we can even migrate them at the same time. So if it makes more sense for your code to run in sync with another event loop, we can just take it off and take it to the next event loop where it makes more sense. So this will come in really handy later on, but that's basically the big difference between those two, and now that we have worklets in our back pocket, we can finally talk about the very first Houdini API which is for the paint worklets. This is more like an order of availability, if that makes sense, but for the paint worklets, the API is called the CSS paint API, and as I said, all elements have to be painted sooner or later to be able to appear on screen. And so far, you have been able to use CSS to customize how your elements appear on screen, but only with those ways that CSS exposes. So for example, if you want to do rounded corners, it's kind of great, but it also turns out that there's different ways to make a box seem like it has rounded corners, and if you want to use any of these other ways, you're kind of screwed nowadays, because what do you do? So for example, there's a so-called squarkle, which mathematically speaking is closer to a circle and a square, and it doesn't change curvature abruptly at all, so it has a kind of different aesthetic look, which could be kind of nice. So if you wanted to have this thing like, hey, what do you do? You can maybe do an SVG background image, which is not really a border. You could maybe use a canvas or nine slice image, I don't know, but with Houdini you can actually teach CSS how to draw the exact look that you want to have on your page. So how does this work? Step one with all workloads is that you have to load a JavaScript file into the workload that the browser gives to you. You have the CSS namespace, and all the workloads that Houdini brings to the browser are going to be in the CSS namespace sooner or later. So in this case, it's called paintworklet, and every workload has an add-module call with which you can load a JavaScript file into that workload. Let's take a look inside this file. In that file, we want to teach CSS how to paint something new with JavaScript, but first it needs a name. So there is a registerPaint function, and it takes a class, and you can basically associate a name with that class. And every paint class, in this case I'm using my paint, we need to define a paint call. And this paint call gets a context which is almost identical to the canvas contact that you're hopefully familiar with. A geometry object which tells you how much width and height the element has that you're supposed to paint, and a properties object which allows you to read the styles of the object that you're painting. And now what I'm doing here is basically I'm setting my full style to hot pink, and just draw the biggest possible circle in the middle of the element. Not very useful, but in the way useful for me to show you what is actually going on. So now that we have defined how to draw this appearance, how do we tell the browser to actually use this new appearance? So we do that in CSS, so in this case I'm just setting a new style, and you can use paintworklets everywhere that CSS expects an image. So I'm going to take that ground image not to an URL, but to a paint and use the name that I use and register paint in here. So here I use paint, my paint. And this is actually if it works. No. This is not good. I told you, prepare for my bugs. No, the entire laptop froze. No. Okay, maybe it's coming back to life. I'm going to try something. I achieved something today. All right.  What do you do in this kind of situation? All right. I might be able to remedy this. So just, I can see, maybe you can follow along. Hey. We're trying to kill this. All right, give me two seconds. We are hopefully back up in a couple of minutes. This is like good old supercharged with life debugging on stage. I'm really hoping that this was really just the browser having a hiccup more than anything else. I am not sure this is going to work. I'm really sorry about this. That might be the only, only chance I have, honestly. Let's do this. Let's do a reboot. I mean, this entire thing is just not responsive. So it's not much I can do. I have to. I'm not going to open. This thing is not responsive at all. So I'm actually going to do a reboot. What we could try, I have it in here as well, right? Hmm. All right. Basically, give me a couple of minutes, okay? All right. We're doing it the hard way. I'm already thinking in my head which content I can cut to still stay in time.  Power was out. This is exactly the kind of experience I was hoping to give you at a Chrome Dev Summit.  All right. We're almost there. Now, I'm going to make really sure that this power plug stays in. This is like a speed run. I always want to participate in a speed run but not without me knowing it. It's booting up. You just can't see it yet. So we're getting there. I know. I have a point. Why should I walk there? I'm trying to set my laptop. I'm setting up my laptop. You dance. Please boot up faster. Is it on? Did you make sure it's charged? We're never going to let you forget it. Never going to let you forget this. I know. This is not how I expected this afternoon to go. It's amazing. With friends like these... I mean... Almost. Keep going. Do you need more support? Do you have a dance to the music in your head? I actually dance at my desk. You do. I don't sit down at my desk. It helps my back to stand.  Because everyone around you is like, what is he doing? I'm debugging. Just so you know, that's how it's done. I was told there was a problem. Can you dance? This is your framework. That's why I'm worried. Your framework is actually doing quite well. Brilliant. That's all I care about. Is it open running? My favourite thing that's happened in the last couple of days in terms of things going wrong was when the big web quiz went wrong for you to yesterday and the answers were coming up weird. Because I was watching that backstage on the live stream. But the live stream is about 30 seconds behind. So I was sat watching it and the answers were coming up wrong and you said, oh no, this doesn't look right. This doesn't look right. And then behind me a voice came and just said, what's going on? And I turned around and it was you. And then I was on the screen and it was you. And for one moment I thought, Paul's cloned himself. That seems natural. That's fine. It is a good way. You're working backstage and seeing yourself on live stream. That's a really interesting question on the big web quiz. I wonder how they'll answer it. So what did happen? Is it running yet? Almost. Is he recompiling the kernel? What's good about this is because we have an amazing team backstage. The editors of this will just be like, either that or they'll cut to me dancing. And then they'll come back to you and people will be like, I don't know what happened. I hope that's the edit we put up that would be way more enjoyable than this. I have another story. So the prize that we printed, I ordered it from online form and I couldn't check out. And I was just like, why don't you let me select the query card? There was JavaScript. Really? They were using Backbone. Have we just tried? There's a follow up to this. They had a 1-800 the total free number. So I called them. I need to give out on Tuesday. This was last Friday. And they were like, that's no problem. We can give it to you. Please tell me your account numbers and all of that. And then there comes that visual. Yes. Some might think that we didn't plan the content of that poster very well. It looks like it's been just saying maybe badly designed. But actually, it is exquisitely designed to be awful. That was our intent. This lady, poor lady, I'm seeing misspelling outside of the plating area. Are you sure? Well, you are welcome, my friend. Thank you. Ladies and gentlemen, Das Zoma. You've got seven minutes left. Thank you. You were roughly at the squircle. You were roughly at the squircle.  So I'm actually What did you do? What did you do? Nothing. Absolutely nothing. Jake, that's your framework. So fix that. This is Houdini. This is nothing to do with me. Oh, just like the cake. Yeah. Oh, look, look, look. Is that a good thing? It's moving. Is there any chance you could switch out to say videos? I have a couple of videos. That's true. So what actually happened? Did you restart and then Chrome updated? I don't know. Maybe. Because remember when we were in the office and I said, yeah, what you should do, right? If you were doing an experimental build, what would you do tonight? I mean what I could do. I'm just saying I told you so. That is precisely what he needs right now. Yeah, exactly. I'm going to try something. It's not going to be ideal, but hopefully it will do the trick. Well, I'm on the edge of my metaphorical seat. Yeah, this is good. How much time do I still have to fill with this so that nobody knows I actually didn't prepare a talk? Hmm. I feel like at this point I'm just going to re-record the talk and put it just out as a video. That's great. What's your plan? I'm interested. Stable Chrome. So the demo is not going to work. I have most of them as videos. That seems like a good backup plan. You could have gone without first time around, really. I know, right? I only have five minutes left, so that's good. You're using my slave framework, right? I am. Enable experimental web platform features. That's a good one. Wow, amazing. The number of stories you get out of this one, mate. Yeah. Never going to let you forget it. Everybody warned you for not to use Jake's framework. My framework is not to blame here. It's fine. I'm actually wondering if it's still the battery issue, because it discharged because the power wasn't quite plugged in. Oh, that was what it was. The diary. Unexpected things at the Chrome Dev Summit today. Okay. So what are we waiting on now? The beach ball of death. I'm going to put it on screen so everybody can see it. It's beautiful, isn't it? Hey. I'm going to get my laptop in case we need to do a big web quiz question. I have my phone. We can do it from here. Do you want to do a big... We'll have it as a backup. You've noticed I've had my notes every time. I know you look like you've got a clipboard. I can't make without my notes. I'm going to judge everybody. What questions do we got? What can we do that we've definitely checked the answers for? All of them. I mean, the CMS. Oh, the CMS would be the next one. We've definitely checked that one. I think my laptops are gone, honestly. What? My laptop is gone. Oh, mate. This is, like, the worst... I told you. That's the word of encouragement that Salmanis right now. I mean, at this point, the only thing I can legitimately do is, like, go out, try to fix it. Should we do a quiz question? You've got until the end of that quiz question. Should we call it? Yeah, put it on. I'll try. Should we switch to quiz? Yeah. Hey, look at the quiz. Hey!  Oh, imagine. Hey, look at that. CMSs. Yeah. CMSs known to have funny names. They are. And actually, researching this round was, frankly, hilarious. Yes. I mean, not quite as hilarious as this. Anyway, um, let's start the round. Well, should we introduce what the idea is? You're going to pick the ones which are real and which are fake, right? That's what you're going to do. And since, like, every developer in their career does this at some point and gives this a name, this is a really difficult round. I like easy-peasy content, squeezy. Yeah, that's probably one. Magnolia goes getting a high score. Oh. The far cry. Oh, CMS. Who put that one? Feeling content. Oh, that's a good one. Ultimate content managerizer. I think that's a wrestler. Yeah. Oh, that was a quick round. Very confident about Magnolia. Reveal some answers. Let's have a look. Yeah. I'm really disappointed that easy-peasy content, squeezy, is not a CMS. You know what? Now that you say that, somebody is, like, publishing MPM module right now. Brilliant. I will gladly use it if it's a good... Hang on. Magnolia must be the popular one, right? I've not used this content management system in yours. Is Magnolia a popular one? Is it a popular one? I think so. These are well-known ones. That would be why you've got 92%. Yeah, I assume so. Okay. In the next batch, Jake CMS. Most people don't think you are a CMS, buddy. Am I a CMS? I don't know. Should we find out? I should press the button. Go on, I'll press the button. Go on then. Hang on. Is the failure spreading? No. Okay. I mean, there is a common factor. Wait, wait, wait. Far cry? Far cry is an actual CMS. What kind of content are we talking? Because the far cry I'm familiar with is a different kind of content management system. You're basically managing people from being alive to dead. Right? Or the name based on the person who developed it, because, you know, writing content management system is just like... Is that right? Is there a joined history between the two? It's hard. I think it's probably an homage. All right. And then finally, Alchemy. Tiddly wiki. 60% think it's real. Do you know what I think of that 61% who think it's real? I think they're right. Yeah. Despite its name, I had a giggle about that one backstage, Tiddly wiki. I would call it that. But ultimate content managerizer. Also, like easy peasy content squeezy. Not real. In fact, fake. Someone get that, NPM. Was that when you made up? How is it? Dead, Jim. My laptop is legit broken now. So you were saying to me, like, because at Google every few years we're able to get a new laptop, and you were boasting like, I've only got to get this laptop to last until April, and I get a new one. Yeah, you've got no laptop for a few months, mate. That's it. Yeah. I'm without laptop passed. Houdini broke my laptop. So if you want to try Houdini, there are no flags in Chrome. Aw. Because they're already waiting. We might as well. I think we should. Our next speakers are Chris Wilson. First of all, can we give a round of applause to Sarma, though? Absolutely. All of my worst talk failures have happened at Google events, and none of them have been that horrific. But you know now, if they ever happened, you can be like, but at least it was Sarma's thing that happened.  Oh, thank God that wasn't live-streamed. Right. He'll be okay. Our next speakers are Chris Wilson and John Pallett. Ladies and gentlemen, Chris and John. He discharged my laptop. I've not just sent it back yet. What was that? Stay away from my laptop, Sarma. I think Sarma's never been so happy to see me. So I am Chris Wilson. I'm here with my colleague John Pallett, who will be out in a minute, and we're here to talk about the next great platform, the immersive web. And this is actually not running off my laptop, so hopefully I won't have any problems. At least they won't be mine. Now, we talk about this word immersive a lot, and I kind of wanted to define what I meant by the immersive web. And at this point, I think pretty much everyone has heard of virtual reality at least. So I'm going to close this up. Who saw Ready Player One? It's actually a really small percentage. You should go see it. It's a good movie. It's good entertainment. So it's totally just like that. Well, not really. But virtual reality is all about immersing yourself in a completely alternate reality. Putting what I refer to as the reality blinders on, completely replacing everything you can see and usually hear, and immersing yourself in this totally different world. Like visualizing a data set. It can be a virtual workspace. My kids like to play this game where I put on a VR headset and they see how close to me they can dance before I notice that they're there, which usually it's pretty close.  The sea of cubicles isn't there anymore.  And any of these devices end up using a combination of head tracking, screen display, optics and controllers to make you feel like you're present in a totally different world. Now at Google, we've been working on exposing this to the web for really quite a long time on all these devices from high-end desktop headsets on Windows to a polyfill that supports WebVR on any smartphone in Cardboard. Yes, even Safari on iPhones. And in fact, you may not even have a VR headset. You might not even have this 29 cents worth of Cardboard. WebXR and the XR polyfill can actually view VR worlds just on a mobile device using the accelerometer and orientation API so you can look around a 3D scene. And this lets users look around your 3D world even if they don't want to drop their phone into a headset. Now, in addition to bringing VR to the web, we also, like my team actually works on bringing the web into VR at least on Daydream devices. Starting with Chrome 67, you can actually launch a VR version of Chrome inside the Daydream home screen, and we put a lot of work into making browsing the traditional 2D web a really great experience. But of course, the really cool part is when the browser in VR can be used to browse immersive worlds, like you can hop back and forth between the 2D web and VR content that's hosted directly on the web. So this gives you a really great easy experience and really actually totally immersive.  Now, having a browser inside the VR world is so useful. It turns out 83% of Daydream users also regularly use the browser in VR. This was kind of something we added on after the fact. Daydream shipped without a browser and now this is a regular occurrence for most of them. This shows how important the content from the web is even when you're just living inside a VR world. But enough about virtual reality for a second. I want to talk about when you don't want those reality blinders on. I actually like to interact with my kids. I want to be able to see them and not have them dance in front of me. And the most exciting extension of the computing platform to me is a concept of augmented reality, not just overlaying AR stickers and animated characters or being able to drop virtual objects into your reality. The key to understanding AR's potential is that it's really about the concept of your computer getting to see getting to see a world around you interpret parts of it, find surfaces in the future, recognize objects and then augment that reality with virtual bits of user experience. Instead of trying to totally replace your reality we really want computers to just convincingly blend virtual and real experiences. Now for AR there are some headsets like the HoloLens, the Magic Leap One there are projection systems to display on real world systems or real world surfaces but most users will probably first experience AR like I did using a camera pass-through experience on a mobile device showing things like AR stickers. And the cool thing is if you think of the things the web is really really good at the long tail of software content products you expect from the web, the experiences that users will probably happily click on but they wouldn't necessarily install on their devices. The massive success of the web as a commerce platform is a huge huge benefit. You can start to see how enabling developers to build immersive experiences that are delivered in this really ephemeral fashion is a fantastic idea. You don't have to install an app to see how that couch is going to look in your living room. You don't have to install an app to view an immersive video trailer. The ephemerality of the web makes the ability to do these immersive experiences a fantastic match. And our mission, John's and mine is really to enable web developers to break that plane, like break out of the flat design world that we've been living in for so long to enable these truly immersive experiences. And to enable that we really need to start with the baseline. We need to be able to connect immersive displays and render to them. And that's where the WebXR device API comes in. This replaces the old WebVR API, evolves those concepts to expose not just VR, but also AR functionality. And in true extensible web platform layering, this is really the underpinning only. Like this lets us connect to those devices, render displays, understand which way they're pointed, get to interact with controllers, that kind of stuff.  Google, Mozilla, Microsoft, Samsung, Amazon, Oculus, a whole bunch of others as well have been working on this for a while. And this has all been developed by the way in the W3C. In fact we have a brand new immersive web working group. I personally co-chair this with my colleague Ada Rose Cannon sitting right down here in the front. I just had to make her blush. From Samsung, and we're tasked with like taking this spec to an actual final status. And this is why we created a working group, because we feel it's super important to actually land this now, and not just keep talking about how cool it could be in the future. This really shows the maturing of this API, because it's moving closer and closer to becoming a final standard. And of course we also continue to incubate new ideas in the immersive web with a community group. Now if you want to experiment with WebXR API today, you can enable it with Chrome's flags, with the about flags. If you want to try out AR scenarios you have to enable the second flag that should be going away soon because we've done some new mode work in the spec to make that work too. We have a currently running origin trial too, if you want to try to deploy this out to normal users. And of course if you're willing to accept the responsibility of making changes, as the spec and our implementation change. Now finally, I've mentioned the WebXR Polyfill a couple of times, and this is something I wanted to give a little more detail about. This is a Polyfill JavaScript library that's maintained by the community group. It helps developers in a couple of different ways. First, it offers a JavaScript only implementation that works for VR scenarios in any mobile browser using orientation events. So even mobile Safari with cardboard devices or flat displays you can actually get a WebXR implementation just through JavaScript. Secondly, if a browser does implement the older WebVR API, like Firefox did this and Microsoft Edge did this, it can actually build XR on top of that and you get the hardware speed up of their former WebVR implementation. So you can instantly make your WebXR content accessible to a much wider range of users with just one script. Now, with that I want to bring out my colleague, John, who's going to drill down into the augmented reality possibilities in a bit more detail. Thanks, John. Thanks, Chris. So let's talk a little bit more about augmented reality or AR. As Chris mentioned, augmented reality is largely about being able to overlay information over top of the real world.  And the reason for this is that there are hundreds of millions of phones and tablets out there right now that support augmented reality and the number is growing. And most of those devices have web browsers, which means there is a big opportunity for web developers here. And the lowest hanging fruit really is the ability to add a new experience to an existing 2D webpage. So it doesn't require an entirely new site, you can add AR capability to an existing 2D website. There have been a number of partners that have been experimenting with this, using the WebXR device API and turning on the hit test flag that Chris mentioned. They're doing this in Chrome Dev and in Canary. And there's one example, Plater, which is an augmented reality platform that lets businesses put virtual objects in the real world. They've done a couple of demos and there's some interesting ideas here. On the left you can see that users can learn about a product by getting information in context on the product itself, rather than having to go through data sheets. And it actually saves shipping demo units to businesses that are thinking about buying machinery or heavy equipment. On the right you can see that looking at objects from different angles has a lot of value, in this case for fashion and generally for shopping, but also for education where students can explore the object or artifact that they're learning about. Now this doesn't all have to be an augmented reality. You could do both of these using a 3D model on your website, but if you can put it into the real world, you get a better sense of context as well as scale. Now what's interesting though is that from a user user experience perspective there are a lot of interesting things to learn about augmented reality, particularly how it fits on the Web. And it's a good reason to start experimenting with it now if you're thinking about adding it. So by way of example, West Elm, who sells home decor and furniture, did some in-store testing. And what they did was they went to one of their stores and they picked four shoppers at random and they showed them a prototype shopping website that incorporated augmented reality. Now this isn't a huge study, it's four shoppers, but they had some interesting findings and they gave us permission to share them. So the first thing that they learned is with these customers the terms AR or augmented reality it's not really a common vocabulary. Basic terminology like view in your room is a better way of telling users what to do. But even then, without a visual showing what's going to happen, that text can really get lost with everything else that is visual on the site. So what they're looking at now is ways to add both an icon and text so that the user has a call to action, they know what to do. One approach might be to have a rotating 3D model so that the user understands hey, this is more than just another image on the page. The next thing they learned is that users get confused without clear directions. You can see here that there's a delay while the user is trying to figure out what to do. Do I tap? Do I move my phone around? What is this circle on the floor? I've never seen this before. You have to actually guide users to the path of success here. And West Elm is researching clear directions as well as things like progress bars and loading indicators so that users don't get lost and they can see how to get to the point that they're already placing furniture or an object into the real world. After that, once participants successfully placed an object, the most common request was the ability to move it or spin it or even remove it from the scene. The original placement wasn't always where they wanted it to. It wasn't always clear to users how they could do that in this case. Another thing that they heard from their test subjects as well was that getting validation that the size of the virtual object matched the real world would also be helpful because if you're shopping for furniture, you want to make sure that it fits into the space that you have. So from that perspective, showing some real world dimensions with the model could help. And finally, there was some feedback on how real the assets look. And now this study was particularly unique because West Elm was doing it in store and so they had the opportunity to put the virtual object right next to the physical object and get real shopper feedback. Generally speaking, the feedback on realism here was only 10. And you can see clearly that there are differences between the two. So West Elm is looking at how to handle typical lighting scenarios and also make sure that the shadows underneath the object are a little more pronounced and more detailed. So the key message here really is that there's a whole lot of things that you can learn. There's a lot of streamlining going on here and fundamentally augmented reality on the web has some differences from apps where somebody might be installing an augmented reality app and so they're quite those challenges a very I think a telling finding from this study was that three of the four participants said they would absolutely 10 out of 10 use AR once they knew what that term meant to do furniture shopping. Now if you're like me and you grew up with commercials talking about three out of four dentists recommend this toothpaste you probably all wondered what does that fourth dentist think? Does it rot teeth? And the answer here is actually maybe. So three people absolutely one person maybe I personally visualized that as these are people shopping for home decor and they say would you use this and they're like maybe I'm here to buy a couch but I don't actually think that's how it went but the point here is that three people said absolutely and pulled from random three people said absolutely it's a strong signal and it's also consistent with what we've heard from partners and users who see value and be able to visualize 3D objects ideally in the real world. So if you're thinking about experimenting this and you're thinking about adding this to your website let's talk a little bit about how you can build things. Chris mentioned the flags you can enable a little bit earlier in the presentation but let's talk about how you actually add the immersive experience. So you could write WebGL code directly and if you're doing augmented reality that would be over top of the camera feed that's one way you can do it generally we recommend using a library to help. For example 3.js is a helper library for 3D graphics on the web and it takes care of a lot of the heavy lifting for 3D geometry management and rendering and it makes it so you don't have to work with WebGL directly. So let's look at an example of how 3D and WebXR can work together we're not going to cover the whole process of creating a WebXR session and doing all that we are going to look at how a virtual object can be placed into a real world scene and we're going to do that with a narrow use case in this case putting a reticle onto a real world surface for those who haven't heard that term before a reticle is an indicator in this case as it moves around and it's typically a user interface construct so that the user knows what they can do you saw some of this in the West Elm Screenshots earlier so what we're going to do first in this case is take the mesh for the reticle which in our case is a flat circle and we'll add it to the 3D scene it's worth noting we like the reticle to be about half a meter wide and so it's worth noting that the WebXR device API locks the coordinate system of the real world to the virtual world what that means is that one in WebGL or the virtual space or in 3, one unit is one meter in the real world, 10 units is 10 meters so in this case if our mesh is half a unit wide it means it will appear as half a meter in the real world next what we're going to want to do is actually render the reticle over the camera on real world geometry but to do that we need to know where the real world geometry is the WebXR device API includes the capability to do a hit test which is firing a ray into the real world and getting intersection points with real world surfaces so for example taking a ray from my eye down into the stage and then getting the intersection point of where I'm looking on the stage but also the normal facing up so I know where the surface is and what direction it's facing now three in order to do that you need a ray and a good example of some of the things three can help you with is a ray caster function for the ray that you're going to fire into the scene from the camera so we've already got that here and what we're going to do is pass that into the hit test API with WebXR and then what we'll do is we'll take the return value we'll actually possibly get a list of things because it might be more than one object behind the first hit we'll take the first one the closest and we'll convert the position that we got into a 3.js matrix and then we'll use that to set the position of the reticle the reticle is now positioned so that it will render directly over the real world object that was detected from that ray now it's worth reiterating that this works because the virtual coordinate system matches the real world one and obviously I skipped over a lot of steps here but the point really is that you can combine frameworks like 3.js with WebXR and it's fairly straightforward if you know 3D programming basics but some of you might not know 3D programming basics and the fact is that if you've tried to add a 3D model to your site you probably know already it's not super easy 3D models can be pretty complex both to read and to display we saw that even in the West Elm example we saw that there are user experience considerations if you're starting from scratch you have to think about how do I want to rotate objects allow people to move them around and so forth and then there's also responsive design if you want this to work on mobile and desktop you need it to be able to even if you're just doing a simple model you have to know how to handle resizing do you need to display a poster image on mobile to prevent the download of the 3D geometry until the user actually wants it for newer technology like augmented reality ideally you'd be able to take advantage and progressively enhance use some of the capabilities on different platforms even if they're not available in all browsers and as WebXR comes out and starts moving to stable it's one more thing to learn it's one more thing to add just know that if you've experimented with this before and you found it a little bit tricky you're not alone so to that end the team has been looking at this problem and we recently made public an early version of a 3D model viewer Web Component this is really really early but it does some things today to make life a little bit easier and the reason we released it early was to get your feedback to give you some context for this Web Component there's three things we're trying to do the first is we want you to be able to add to having to learn 3D programming or writing 3D code the second is we want it to work well and responsibly across browsers and across different device form factors with progressive enhancement to take advantage of capabilities on browsers where they're available and then the third goal is that as new API ships such as the WebXR device API we want the component to start taking advantage of them so that you don't have to keep up to date with all of the changes that are coming out and it's going to be super early but we've made some progress and so I want to give you a sense of what the component can do today let's run through a few examples and this is the first one the simplest use case which is a static GLTF model for those who haven't heard GLTF before it is a 3D file format and it is a required component of this model viewer because it's a format that will allow us to work across all of the different browsers here you can see that if we add a couple of attributes we can bring the model to life and we can add a layer on color and we set it to auto rotate with the controls attribute we also can allow the user to spin it around and move it and take a look at what's going on but they didn't look at it from the back or the front we've also added a poster image capability and you can delay the loading of the model so you're not consuming data on mobile if that's what you want to do and the attributes are also dynamic so if you add a little script which switches the poster image back and forth you can animate it a little bit but if you add another image it's actually a 3D model that they could click on it works in that way similar to an image tag the component also handles some forms of responsive design so you can see here that it will scale up for desktop and it will scale down for mobile and it will manage the staging and the lighting and the rendering of the model properly it can also manage multiple instances on the same page so it will take care of WebGL from that perspective and it uses Intersection Observer to make sure it's not burning battery and you can't actually see the model finally the team is experimenting right now with some of the more progressive enhancement capabilities in this case you can see they're experimenting with the WebXR API and incorporating that so that you can add more attributes to turn on AR and do that across different devices again it is just really early the team is still working on more features for user interface and responsive design features to make it as easy as possible to add a 3D model to a web page looking for there's a lot we can do on realism augmented reality use cases interactivity the whole reason we made this public is that we'd love you to try it out and we'd like to get your feedback in the GitHub so if this is something you're interested in please do go to the GitHub take a look try it out and then let us know what you think we're done so we covered today a little bit about the WebXR device API we talked about 3JS and we touched briefly on this the model viewer web component if you're interested in more this is a slide to take a picture of the links are all on the screen if you're watching this at home you can rewind and you can check it out on YouTube later I imagine as well and with that thank you very much we thank you for your time so we said at the start of day 2 that day 2 would be experimental you're already laughing that it would be experimental as some time experiments fail what we'd like to do is we'd like to give him a one shot just the one shot because what we're going to do is we're going to roll into the break a little bit there'll still be a little bit of a break and we'll pick it up and be back in as we plan to but we're just going to give him one chance to finish up that talk because it's amazing Houdini's amazing I mean you two don't know this but just literally before we came on stage I went to Summer and said is everything is it looking like it's going to be okay I'm not joking no I don't believe you are joking is that getting better well that sounds good I'm audible so that's winning shall we shall we I know you're all behind him give him a massive round of applause ladies and gents it's Summer so the squircle right as I was saying what do you do if you want to draw a squircle we're still on the same page you totally know I was going with this alright come on let's do this I've got 15 minutes we load the squircle we load the file we had that we had this one we draw a circle in the middle and I want to do the big reveal where we use the paint function for the background image instead of just a normal SVG image I'm going to press the button we have a pink circle I'm so happy by the way everyone thank you so much for the kind messages on Twitter and your support here in the room it could have been so much worse thank you very much what I'm doing here is as I said I set the background image on a text area so this is a text area where I'm animating within height don't do this at home kids never animate within height but you can see the circle is pink and in the middle so you might be asking what is the advantage of using Houdini's paint API what this talk is about over using a normal canvas so there's a couple of things I want to talk about the first one is auto repaint meaning that the browser can figure out when it actually needs to run your code to do these painting operations I'm going to talk about this a little bit later in the talk it is auto sized if you've ever worked with the html canvas you know that the number of pixels on an html canvas is completely independent from the number of pixels the canvas has on the screen which is super painful to work with and in this case you don't have to worry about it because it is automatically set to the correct size it is of main thread meaning the code that you write to do the paint operation doesn't run on the main thread and that's a lie currently in Chrome we do run it on the main thread but as I said the workloads can be migrated so the second we have the infrastructure in place to run this kind of code somewhere else it will just happen and that means you don't use any of your main thread budget making sure your page is buttery smooth no DOM overhead and this one is actually very underrated often I see effects on the web that use a couple of DOM elements or any kind of assembly of different styles to achieve a certain visual effect with this you're just using a virtual canvas so not even one DOM element to achieve this effect and that can really add up on low end phones so for example this is one of the no no wait this is actually not that bad we got this we got this this is just an aw snap we can work around this is this full screen I can look up here all right sure why not hang on we almost got this I'm going to move this over here I'm going to move back and we're going to go to here all right so this I'm literally I'm not giving up for me this just means I'm going to skip that slide so what I'm going to do is I'm going to go out of full screen and moving this to a different slide we're going to back into full screen and we're going to go to this one my point that I was trying to make was that we found that on low end devices implementing these kind of effects like this wonderful effect that Una implemented is actually more efficient in custom and the paint workload than using a million DOM elements so that's why this is actually a performance primitive to make your app run buttery smooth even on the low end devices this is another fact that Una wrote that I think is really nice and this is kind of point a nice example to show how the browser can decide when to paint and when not to paint so in the paint class you can declare your dependencies you can say these are the CSS properties that I rely on and then any of these properties change will the code have to run otherwise it won't and so in this case you have a couple of custom properties saying I want to have this number of stars and this hue and this different sizes kind of thing and then in this case I just do a keyframe animation on the hue and you end up with this effect and it's actually efficient in the sense it doesn't run just a RAV every frame but only repaints when the animation actually tells you it is necessary and so in this case you have a couple of things that you can do you can do this with a simple clock that many people might write with SVG or with a canvas some people would again probably bend over backwards and try to make this happen with a DOM and just a couple of DOM elements but if you look closely you can see that the hand actually has a trail and that suddenly makes it a lot harder to do with SVG or with a DOM and maybe canvas would be more appropriate for the background color or the color of the hand the thickness of the hand the thickness of the circle at the end or the length you can show or not show the individual stops on the clock, you could do all of these things at once but it gets really stressful to look at so I wouldn't do that but it's just a clock and once again this trail is just a CSS transition so the browser knows while the transition is going on I need to repaint this every frame but the second the trail is done and you can see the performance win so far we've been using CSS Paint for background images and we've gotten pretty far I think if you still remember what I was talking about a couple of hours ago it feels like but you can use it anywhere with CSS Expectation Image so for example you could also use it for a mask image or a border image so in the land of border image you could make this kind of organic look where the border looks kind of hand drawn and if you want that kind of look it makes it really easy to achieve that effect this is probably very important progressive enhancement you can detect support for Paint Worklet in both JavaScript and in CSS one note about the add syntax for add supports it detects support for Paint Worklet not for one specific Paint Worklet so even if the name like in this case something doesn't actually exist as a Paint Worklet it will still get evaluated which is kind of handy for this talk I want to introduce the three-pix stability index which is supposed to be a little notion of how stable an API is based on the story of the three-pix and the wolf who tries to blow their house down so in this case in the CSS Paint API the spec is a candidate recommendation which is basically W3C speak for it's stable it's shipped to stable in Chrome Safari announced that they have it in development right now and with that I will call it brick stability at the bottom by the way is supposed to be a brick emoji but the brick emoji just got standardized in June of this year so none of the fonts have it yet but luckily it still kind of looks like a brick if you want to know more about this API I'm going to shamelessly self-block the article that I wrote which you can find here if you have any questions hit me up anytime and with that out the way we finally have talked about the first Houdini API I'm going to go on to the next one and see if the browser will handle this should I risk hiding the URL bar I will do it good the next one compositing as I said the compositor main job is to do animations with the papers that move around so as such the animation is called the animation workload API so let's talk about that a bit if you currently think about animations on the web you have three choices it's more like two and a half choices you have CSS transitions which allow you to transition the CSS property to a new value you have CSS keyframe animations which are a declarative timeline API which is more powerful and can do some kind of looping and you have the web animations API which is the imperative version that allows you to nest the timelines and all kinds of things but the problem is that it's really badly supported it's behind the flag in Safari Chrome has an implementation but it's missing a lot of features Edge doesn't have it at all so it really isn't usually a good choice but even if it was there are often scenarios where what web animations API offers is not enough and this is where animation workload API would come in so what you see here is a normal web animations API animation it would usually web animations API is thought about in the .animate call this is the same thing just a little bit more elaborate it's also part of the API and a workload animation is actually very very similar so for example I would just use a workload animation and because we are associating this animation with a workload we need to once again provide a workload name other than that it stays the same so we have a keyframe effect that we target an element with and we have two keyframes that we want to use within two seconds then now we have an animation workload on the CSS namespace and can call add module and now within our animation file we can use JavaScript we have an animate callback where we get the current time and the effect of the animation and now it's our job to set the local time of the effect depending on the current time if we do it like this where we don't think about it it's literally a pass-through and it will behave just like a normal web animation API but this is JavaScript so you can basically implement arbitrarily complex time mappings now what does this actually mean I'm not going to go into all the details of this API but just going to give you a little taste of it so if you want to know more about this you can look at this in the description and you can see yourself like another article I wrote which you can find here and again read it and give me feedback I would very much welcome that but what do you use animation workload for so for example I think a year ago or two years ago Safari proposed the spring timing function and it's implemented in Safari I don't think any other browser has implemented it so far so I'm going to give you an example of an animation workload that would come in handy so in this case we can for example write a bounce animator because if you think about it if you animate an element from A to B you can either just move it from A to B but you could also move from A to B and a little bit back and a little bit less back and it will look kind of like a bounce and that's exactly what we're going to do so we have a constructor where we take some options in this case there's going to be an option for example for bounciness which makes sense how bouncy is it supposed to look but in this case we're going to use a bounce function and we're going to determine where in between these two keyframes we want to end up so the bounce function I used I implemented with some really dodgy and hand-wavy physics but in the end you can just think about it like implementing this kind of graph between two keyframes so if we do that and we run that you can see that it's now actually a bounce and keep in mind that this is literally just two keyframes and we're just spending time so to speak and it actually runs on the main thread it actually runs on the compositor thread meaning that even if the main thread is super busy it will make sure that this animation runs exactly at the device's frame rate frame perfect and make sure that your animations look really really smooth so so far we have done this, we have done an animation but if you look at this I explicitly wrote out document timeline even though it's an optional argument the point is that with animation workload you could get time from somewhere else you could, for example, think of something like a scroll timeline or you could even conceive of something like an input timeline we are talking about input timeline but I have nothing to show here but I can show you scroll timeline so here you see a pacman that I've linked to a scroller at the bottom so what you see is I can basically scroll the scroller at the bottom and the animation will jump to the position where I am within the scroller and so it kind of gives you an animation scroller and this is kind of fun but not that useful but you can conceive of more useful users for the full scroll linked effects where I have three independent animations the follow button, my name and my avatar are all scroll linked effects that can assume their position within the animation depending on how far I scroll the parallax effect would be another very popular choice to use with this and it's much easier to implement than it currently is on the web now in combination with CSS scripts CSS scroll snap points that we just implemented in Chrome you can now have a lot of synergy here where you have really smooth transitions between different sections of your app and you see like an indicator in top and the images kind of zoom into view and now for me the really interesting thing is that animation rocket is the same thing as the paint rocket was for rounded corners if you don't like how scroll snap points work animation rocket is low level enough for you to implement your own version so it really future-proofs the web for whatever people will come up with in the future let's talk about the three picks the ability index for this API which we have gone through many many iterations on animation rocket but always in collaboration with Apple with Microsoft and with Mozilla and we are now at a point we feel fairly confident that all the browsers are at least on board on a conceptual level with what we come up with I would give this a word stability as I said we feel pretty confident about it but now it's really time for us to see what you feel about it so it is in canary you can play with it now we are going to an origin trial in Chrome 71 so if you want to test out in production and we would love it if you do please sign up here as I said the article should give you all the insight that you need to get started if not please contact me I'm very eager to help out so that we can get some real data I have I don't know how many how much time I have left at this point I'm just going to go for it because I can talk a little bit about Layout API so the Layout API I'm going to start with the three picks ability index because it's complete straw we literally refactored this API two weeks ago at TPAC so there is like a half finished implementation in canary and you should play with it but don't expect the code to still run next week but there is so much potential that I really want to give you like a little insight into this so with the custom Layout API or the Layout Worklets you can basically define your own display values so I'm just going to have a main element a couple of divs in there and that's it all the other magic will happen in the Worklets so now we have a Layout Worklets on the CSS namespace I'm going to add the module and in there we have a Layout Callback I'm not going to explain all the parameters because A I don't understand them all but the layout is pretty complex but I'm going to keep this one simple so we can get a feel for it so what I'm going to do is I'm just going to loop over all the children on my child nodes that are on my custom layout elements I'm going to lay them out in empty space basically asking how big would you be if you had no constraints and then I'm just going to give them a random offset basically giving them a random position within the rectangle that I occupy and then I return this list to the browser saying I did my layout now please go forth and paint me and that's exactly what the browser will do so if you look at this you can see a couple of rectangles and every couple seconds I add or remove a rectangle to force a re-layout and they get a truly random position which is also truly useless but you can see that this is actual the layout phase of the browser this runs during the layout phase of the browser something that was completely closed off to developers so far and to give a little more of a useful example I also implemented a masonry layout so here I'm just loading random images from unsplash with different aspect ratios and the masonry algorithm if you will takes care of assembling these in three columns and the number of columns is once again just the custom properties which I can increase and it will kind of scale up and give you this really nice masonry look which so far you would always have to do with position absolute magic and main thread JavaScript and the actual layout which I think is really exciting if you're interested in the code because I don't have an article for layout work like yet mostly because by the time I would be done with an article I would be out of date again please go to this repository that I maintain where I have samples for all the work that I talked about today and you can fork them and play around with them or I would be so happy if you contributed to them I kind of want to build a collection with popular effects which I think would be really useful if you want to keep up with the development of Houdini I made ishoudinireadyget.com where you can see all the browsers which Houdini APIs they support which ones are in development which ones they at least want to implement in time there is links to the articles, to demos, to the specs hopefully I can make this like the one stop shop that I need to keep up with Houdini and I can't believe that I made it to my last slide so now come and take a bow I think you should come and take a bow I just gave my talk they are the awesome ones thank you so much claps all around now it's time for a break is it still? good, you didn't completely take all the time we are here at 4.30 so go and have a break I think we could all take a break I need one, absolutely see you then when you are developing your web app with a local development server a build system, caching headers and a servers worker it gets hard to tell if a stale version is being served from the server or is just lingering in one of the caches or maybe the build system hasn't even kicked in yet one small trick to easily figure out Curl is a command line tool that makes the HTTP request and shows you the response of the server but you don't need to learn all the options that Curl has DevTools has learned them for you if you right click on your request in the DevTools network tab you can select copy copy as Curl your clipboard now contains a Curl command that exactly mimics the request that Chrome has sent off including user agent, cookies, compression and all the other HTTP request headers paste it into your console and you will see the response the server sends without any caches or servers workers in place an additional tip is to use the dash i flag so Curl prints out the response headers as well if a response is not what you expected your server or your build system is the culprit if a response is correct you need to check your caches or your server worker terminal tricks gotta love them see you next time I think so does it trigger layout well before you start do you want to just very quickly do the what style what layout is I'll explain so style calculations will be something where the browser calculates the style which will be something like what height it thinks it wants to give something when it has to look at the whole cascade and see what styles apply to the individual layout would be where it's figuring out the geometry of the elements how wide how high and all that kind of stuff and if one pushes one out of the way and all that kind of stuff painting would be where you actually fill in the pixels and then compositing is where you put the various layers of your page together we have a whole section on developers.google.com slash web slash I think it's rendering performance but you should go and read about it I wrote it a while ago but it's okay but this question oh sorry yes this question it's about does it do the geometry thing does it trigger layout you ready let's go now box shadow if you change box shadow does that trigger layout about outline containment can never remember the difference between outline and border I guess just one round the other there we are perspective that's a 3D transform one background image forms talk about those quite a lot when I'm talking about performance text to the line display, display flex, display block display inline inline block display table display and then the layout alright sorry all the display modes we're just going through my head then did you ever use display run-in what? yeah display run-in something I don't believe you right shall we find out whether they trigger layout box shadow no it doesn't it just changes the shadow but it doesn't actually change the height of the element it doesn't trigger any layout outline is the same it's like border which we'll come to in a moment I suppose except that it's a paint thing so it adds an outline but it actually doesn't change the size border actually changes the size of the element containment yes as soon as you put containment on it will change the actual essentially trigger layout to figure out what it needs to contain and the same with height yes well done for everybody who got the one on height perspective isn't it shall I reveal them perspective doesn't but it can change where the element appears yes but it's only done in a compositing phase so we'll do 3D transforms as a compositing step and that's what perspective changes now there's an interesting one about transform it can sometimes trigger layout oh but most of the time it's a no so that's why it's a no but actually it can if you transform something off to the right or the bottom of the screen and we add scroll bars on just so you know that's a full on no isn't it for cursor and I'm going to say I agree with that one yep and they are absolutely correct so the difference between outline and border is border is actually going to change the size of the element yes indeed and display you're quite right if you do display flex the display in line we have to figure out the geometry effect of that so there you go okay should we go away and introduce the next speakers I feel we should introduce the next speakers I'm Thomas and I'm the product manager for WebAssembly my name is Alex and I'm a software engineer on Chrome OS and today we're going to talk to you about WebAssembly we're going to start off by briefly describing what WebAssembly is and what you can use it for then I want to show off some of the amazing new features that the WebAssembly team has been working on to deliver to you in this last year then I'll showcase some of the amazing applications that have managed to build with WebAssembly and our shipping and production alright so first off what is WebAssembly actually WebAssembly is a new language for the web and offers an alternative to JavaScript for expressing logic on the web platform it's important to note though that WebAssembly is in no way a replacement for JavaScript rather it's designed to fill the gaps that exist in JavaScript today specifically WebAssembly is designed as a compilation target meaning that you write in higher level languages such as C++ and then compile into WebAssembly WebAssembly is also designed to deliver reliable and maximized performance which is something that can be difficult to get out of JavaScript most exciting though is the fact that WebAssembly is now shipping in all four major browsers making it the first new language to be fully supported in every major browser since JavaScript was created more than five years ago alright so what can you actually do with this well as I already mentioned because WebAssembly offers maximized and reliable performance you can now expand the set of things that you can feasibly do in the browser things like video editing complex application codex digital signal processing and many many more performance demanding use cases can now be supported on the web secondly WebAssembly offers amazing portability you can port not only your own applications and libraries but also the wealth of open source C++ libraries and applications that have been written lastly and potentially most exciting to many of you is the promise for more flexibility when writing for the web since the web's inception JavaScript has been the only fully supported way to execute code on the web and now with WebAssembly you have more choice alright so now that we all know what WebAssembly is I want to jump in and show off some of the new features that we've been adding in just the last year first off is source maps you likely all know how important source maps are when you're working with something like TypeScript or Babel but it's even more important when you're trying to debug your WebAssembly code source maps let you turn something that looks like this into something just slightly more friendly like this with source maps you can see the specific line of code where an error has occurred you can also set break points and have the program actually pause at the appropriate moment one of the big feature requests that we've heard from users is for better performance when you're starting up your application so that your module can actually get going faster and for that we've created streaming compilation in the past when you wanted to compile a module you had to wait for the entire module to be loaded off of the network and only then could you move on and actually compile it now with streaming compilation so you can start compiling each piece of your module immediately even before the other parts have finished downloading to show you what that actually looks like here's a simple example where we call the fetch function fetch for a WebAssembly Fibonacci module and then we just pass that fetch promise directly into WebAssembly that instantiates streaming and it takes care of all of the underlying bits and pieces for you to deliver this experience we did some profiling at different network speeds to see the impact of this we found that all the way up until 50 megabits per second network speed the network was actually the primary bottleneck and that the compilation was done as soon as the module was loaded it wasn't until you hit the 100 megabits per second speeds that you actually needed additional time past the time it took to download the module in order to fully compile and get it going to make start-up time even faster the team built and launched an entire new compiler that we called the lift-off compiler this lift-off compiler takes the WebAssembly bytecode that comes down off of the wire and then starts executing it immediately the WebAssembly module is then taken off the main thread and optimized further by the turbofan optimizing compiler when turbofan is done optimizing the WebAssembly code it's then hot swapped in directly without any need for explicit developer action Unity did some benchmarking on the effects that lift-off had on a benchmark where they tried to load a very large game they found that it went from taking seven seconds to load the game to less than one second which makes all of the difference when you're waiting to get into a game experience probably the biggest feature that seems to be working on this year is WebAssembly threads WebAssembly threads lets you run fast highly parallelized code for the first time across multiple browsers including existing libraries and applications that use threaded code such as P-threads to the Web this is such a big feature that I'm actually going to leave most of the explanation to Alex later on but before I get into that I want to show off some of the cool new applications that have already been building and launching with WebAssembly this last year first off is SketchUp SketchUp is a 3D modeling software that you can learn and start using really quickly unlike traditional computer aided design most people can learn SketchUp almost right away SketchUp lets people draw in perspective and then push pull things into 3D in no time people can draw and redesign a living room plan out a do-it-yourself project or create and export a model for 3D printing this app is a lot of fun and you should all check it out which you can do right now instantly just by going to app.sketchup.com SketchUp has been around for a desktop application but the team's strategy has always been to expand and broaden the spread of people who can use 3D modeling and by making it simple and easy to use and accessible to everyone delivering the app over the Web was a critical step in that strategy and the team knew that they wanted to use the same code base for their desktop as their desktop applications because rewriting their entire application in JavaScript was just simply not an option the team's approach was to use the WebAssembly and Emscript and Compiler to compile their core 3D modeler and bring it to the Web the initial port took two engineers only three months to bring to the Web which is pretty phenomenal when you realize just how drastically it expanded the reach of their application the early focus for SketchUp has always been on the next generation of 3D modelers and today SketchUp is already one of the most popular apps on the G Suite for Education Marketplace at the same time the app has opened up a subscription model for SketchUp and in just over six months the team has increased its paying customer base by 10% SketchUp has also seen consistent growth in session time returning visitor percentage and active users moving on the next application that I want to mention is Google Earth I'm happy to say that Google Earth has successfully gotten their application to ported to WebAssembly including the newly added support for WebAssembly threads the best part is that they actually got this threaded build working in both Chrome and Firefox making Google Earth the first WebAssembly multi-threaded application to be running in multiple browsers Google Earth did some benchmarking comparing their single threaded version to their multi-threaded version they found that the frame weight almost doubled when they went to their threaded version and the amount of jank slash drop frames also reduced by more than half alright so the last big company and launch that I want to mention is Soundation Soundation is a web-based music studio that enables anyone to make music online with a wide selection of instruments loops, samples and effects no additional hardware or installation or storage is required everything is accessible instantly and everywhere Soundation's mission is to facilitate musical creativity in the world and they do this by offering a powerful accessible and affordable service to the growing demographic of casual producers as an online web app that is able to streamline the ability for producers to connect with peers get feedback, enter competitions and even get record deals Soundation is using a wide variety of advanced web features to deliver this smooth experience and the first of these is audio worklets launched in Chrome 66 the audio worklet brings fast performance and extensible audio processing to the web platform it can be used in conjunction with other cutting edge web technologies or a buffer Soundation is also one of the world's first adopters of WebAssembly threads and they use these threads to achieve fast parallelized processing to seamlessly mix songs so let's have a look at their architecture and see if we can learn anything on the JavaScript side of the world they have their application UI that application UI then talks to an audio mixing engine this audio mixing engine then spawns off multiple different worker threads in WebAssembly these worker threads can talk to the same piece of shared or a buffer memory this shared or a buffer memory is then passed on to the mixing thread which further passes it to the audio worklet which produces the final result here's a visualization showing the performance improvements on rendering a song as they added multiple threads adding just a single additional thread doubled their performance and by the time they added five threads they had more than tripled the performance of their application so that's a great visualization showing the performance improvements that thread can bring but since this is Soundation I thought we would instead try and listen to it so here is us trying to render a song in Soundation in the single threaded version of WebAssembly and fair warning this is not going to be an entirely pleasant experience so as you can imagine this is not the experience that you want when you're trying to create beautiful music but luckily Soundation succeeded in launching with WebAssembly threads that sounds just a little bit better so as you can see not only is this a much more pleasant experience but the CPU also has additional cycle for other work alright so I want to close off my segment by just talking about some of the amazing community projects that we've seen people working on out there and the first of these that I want to mention is the awesome work that's been done by the Mozilla team and the Rust community to bring Rust to the web through WebAssembly they have an awesome set of tools and materials to help you get started and you can check those out at rustwasm.github.io speaking of languages we've also seen more than 30 different projects trying to bring other languages to the web through WebAssembly these languages include ones like Perl Python, Ruby, Kotlin, OCaml, Go, PHP and the .NET framework many of these languages require a garbage collection which isn't currently something that's supported in WebAssembly though we are working on it these languages come to the web by actually taking their garbage collection system and other runtime bits and compiling that itself down to WebAssembly and then shipping everything down to the application page this is a great strategy for getting started and experimenting with some of these languages on the web but because of some of their performance and memory characteristics these aren't currently suited for production applications the fully supported languages today are C, C++ and Rust but everything else should still be considered experimental and there are so many more amazing community projects that I don't have time to do justice we've seen people porting Game Boy emulators GNU libraries digital signal processing and even entire operating system like Microsoft Windows 2000 now available in a browser tab which is if not a exactly pleasant experience definitely interesting you can check out all of these demos and much more at the forum at the demo setup for you to check out and with that I want to hand it back off to Alex to talk to you more about WebAssembly threads and how to use some of these features thank you Thomas one of the kind of big things at the conference here when we talk about the browser we talk about using the platform and quite often people think of the platform as the software stack that's inside the browser but I like to think of it a little bit different I like to think about the hardware the platform that's actually in your machine so here is like an artist's rendition of the inside of a desktop microprocessor this is what you see today if you take the plastic off the top so at the top we have the green bit which is interfaces to the PCI bus it used to be called the North Bridge on the left and right you have memory interfaces these little yellow boxes or integrated memory controllers and you see all these blue tiles here and what they are is cores so each of those is a CPU core in its own right so this may be a desktop microprocessor but even in your pocket if you have an iPhone or advanced Android phone you will have something like 6-8 cores in there ready to be used to do good computing work so when you write a normal web application you are looking at something like this you have one core running so you have all this silicon doing nothing so y