 Good afternoon. I'm Chris Wilson. I'm a developer advocate on the web team here at Google. Joining me is my colleague Francois, also from the web team. First I want to apologize for all the crowding and the long lines. We're working it out. We'll be much, much better next year. And for the web track particularly, it all goes uphill from here. We have three great talks in a row on the web track in the amphitheater right after this talk. So rush right over there afterwards. And we have a nice big room here. So we're here today to show you some recent advances in the web platform, some current work that's going on and sketch out a bit of what's next for the web. I'm going to cover a ton of ground. I'm going to talk really fast. I'm very sorry. But you're going to see short links to additional references on almost every slide in here. So there's lots more to cover. Lots more information you can get. And I want to start by saying first and foremost, in case you haven't been paying attention, progressive web apps are amazing. I've personally been working on the web platform for over two decades, 23 years ago as of a few weeks ago. And now is the first time I can happily say my dreams getting realized. You can build really awesome engaging user experiences using only the pure web platform. You can and should build on this stuff, build on service workers and manifest and everything today. We have a great stream of talks, starting with Rahul's talk. And that will teach you how to build amazing progressive web apps. However, that is not what this talk is about. I like to think of progressive web apps as what's now for the web. And we're here to talk about what I like to call the new shiny, the bleeding edge of web platform features. These are features in APIs that may not be shipping yet. They may not work across browsers. They may not work across different devices. They may need you to flip on some experimental flags. I'm going to dive reasonably deeply into some of them. Some of them I'm just going to whet your appetite for. I also want to say there are a few new shiny features not covered in this talk. Specifically these, credential management web payments, Houdini features in CSS, web assembly and some other ECMAScript stuff, web components, ShadowDom, DevTools. We have great talks on these later today and tomorrow. Or catch them on video, of course. But I'm not going to cover them here. So with that in mind, I want to first focus on some of the web platforms recent advances in developer ergonomics and performance. And ergonomics is kind of a big fuzzy word in this context. So this is basically features that make your job as a developer easier by making common tasks easier or quicker. In many cases, enabling developers to do deeper performance analysis or performance improvements. And I want to start by recognizing some of the stuff we've already shipped here. Some of the stuff that's already out there in common practice. Like promises. So I would hope promises aren't new to any web developers here. Promises are really just a way of creating a consistent pattern for asynchronous APIs. Rather than the confusing mess of ever so slightly different callback mechanisms we used to have. Or heaven forbid, in some cases, synchronous APIs that blocked. And we need to change the mindset of web development to be non-blocking. So promises are now common practice in new web API design. We've recast htmlmediaelement.play to return a promise, for example. Something that's been out there for a while. But now it returns a promise because you can use this common pattern. Also, a bunch of the upcoming APIs we're going to talk about here. Web Bluetooth and Web USB and Web MIDI. They all use promises as part of the API. As well as the Fetch API. And who here is a web developer who has not yet used the Fetch API? Okay. So I'm talking to you. Fetch really just lets you make network requests. It's very similar to XMLHTTP request. Also called XHR because XMLHTTP request I can say about twice without stumbling on it. The main difference is that Fetch uses promises, which enables a simpler and cleaner API. You can kind of understand what this code does without even really understanding anything more about Fetch. It avoids the callback hell and all the complex API of XHR. And it directly integrates JSON and other data types. XHR kind of grafted them on after the fact. So this code is pretty straightforward. This is what it looks like in XHR. It's a little bit messier. You know, it's not too bad. But I am skipping the whole ready state monitoring that you usually have to do with XHR, which is pretty messy. And the real beauty of Fetch shows up when you combine it with arrow functions from ES6. Because then it gets this clean and this looks super. Out of curiosity, how many of you use arrow function syntax regularly already? Okay. That's good to know. We're trying to figure out how adopted arrow functions are and how we can just talk about them. But the challenge with this, by the way, the challenge with this usage of Fetch right here is that that JSON call is still atomic. We still need to get all the data. We need to fetch it all before we can pass it off and parse it as JSON. So there's an effort underway to really unlock the power of Fetch and a number of other APIs called Streams. Now Streams is a fundamental building block. There's a bunch of different applications of streaming. A thorough explanation of all of streaming and how it works would take pretty much all the time we have left. But suffice to say that my colleague, Jake Archibald, he said back in January that Streams would be the thing of the year for 2016. Now Jake may be a little bit excitable. I'm not quite as pumped as he is about the ability of Streams to transform the word cloud into the word but in every document. But he is absolutely right that Streams are a critical piece of building performant progressive web apps. Because the point of Streams is to enable progressive piping. And the really critically important piece which we're still working on getting fully deployed is being able to construct new Streams and then progressively stream data through processing and rendering. You can process data as you're still fetching the rest of it. And then progressively render it. This is especially important when you're building an app shell architecture because you're frequently fetching data from multiple places. And you need to combine those progressively. Today, usually you're gonna wait till all the resources come in, munch them together and then pass it off to an HTML parse. And that's not very progressive. You'll actually have to wait till everything comes in. You'll hear a lot more about app shell architecture in the progressive web app sessions. But Jake cooked up a little video demo that I wanted to look at. And this video shows a comparison of Jake's offline Wikipedia web app being rendered on the server on the far left. And then a naive service worker client in the middle, then some hacks to make it faster. And then a fully streamed progressive web app architecture on the far right. So let's play the video. And it's worth noting the server render actually is the slowest to get an initial render on the screen. It's nearly eight times slower than any of the other ones. But it's actually faster than any of the non streamed ones at getting the final render on the screen. And this is because the non streamed app shell architectures have to wait until all the data sources have been fetched before it can combine them all and send them to the parser. So this is going to be critical for high performance progressive web apps. And in fact, for some types of apps, app shell architectures may cost you a little bit of performance today. So I want to continue the performance theme. I want to talk about some other exciting features we've been building to help you build high performance applications. The first one of these is called request idle callback. Now many sites and I'm sure a lot of your sites have tons of script to execute. Not all of this script is associated with getting stuff on the screen for the user. For example, if you send analytics data while the user is scrolling the page, your web app is probably going to jank visually. Obviously you're going to have a poor user experience in that case. So request idle callback lets you tell the system, hey, I've got this task. Run it when you've got some time. Make use of those idle gaps in this performance timeline. In the same way that adopting request animation frame, let us schedule animations properly and maximize our chances of hitting 60 frames a second, request idle callback works together with request animation frame. It lets us schedule non-rendering work when there's free time for it. So it's really pretty easy. Just make sure you keep your tasks fine grained. Obviously if you have 100 millisecond task to run, it's going to be kind of a problem. And then call request idle callback whenever you have those tasks to be done and let it take care of it. There are some ways to make sure that your script does actually run in a reasonable amount of time. If you have long-running tasks, you probably really want to move those into web workers just like now. But both Facebook and Netflix are actually using request idle callback today to make use of idle time to do non-critical processing tasks. I had to get a cat picture in so this is the cat picture part. Another major initiative in continuing this mission to eliminate jank is a feature called passive event listeners. I love this one because it ends up being so incredibly simple to do. This is a new DOM feature shipping in Chrome 51 that enables developers to opt in to better scroll performance. Smooth scrolling performance, obviously, it's critical for a good experience on the web, particularly on touch devices. And all modern browsers have a threaded scrolling feature that lets them basically render this scroll separately even when there's expensive JavaScript running in the main UI thread. The problem, though, is that optimization gets defeated if you have touch or wheel handlers, event handlers, because they might prevent the scroll completely by calling prevent default. We don't know if it's going to call prevent default during the event handler. So we have to wait until the expensive JavaScript gets done. So passive event listeners let you tell the system that you're not going to mess with the default scrolling behavior. All you're saying is I'm not going to call prevent default. So scrolling doesn't have to block on that event. And it turns out this is far and away the most common case. In fact, in Chrome for Android, 80% of the touch events that get called that ended up blocking scrolling don't actually prevent scrolling. They don't call prevent default. So 10% of those events end up adding at least 100 milliseconds of jank to the start of scrolling. And in 1% of the events, it adds at least half a second of jank. So let's take a quick look at how dramatic this changes. This demo, let's go ahead and play the video. This is a CNN page with the touch events annotated as passive on the right-hand side. On the left-hand side, it's just the normal page. There's no other changes. And notice how it doesn't really affect the experience at all, except the one on the left keeps janking every once in a while. And it pauses. So you get a lot smoother experience. And CNN didn't actually have to prevent scrolling. They didn't ever call prevent default. So unfortunately, the default scroll handler, if you have an event handler, is often janky. And this is easily preventable jank. Let's go ahead and go, there we go. So how easily preventable? This is it. All you have to do when you set up your touch and wheel handlers is just add a passive true option to say that they're never going to call prevent default. That's all you need to do. So pull out your laptops, get your code. I'll wait. That's cool. All right, maybe not. I really do have a lot to get through. So I'm not really going to wait. But Intersection Observer is the next powerful feature. This one you actually have to work at a bit. But Intersection Observer basically just enables you to understand the visibility and position of DOM elements. You can easily observe when elements come into view. You could do this before, but not very efficiently. There are a lot of problems with it. It was generally a little flaky. So let's look at the code to do this. You basically just set up some element that you want to observe. Create an Intersection Observer object with a callback that checks for intersections. And then when you're ready to interact, tell the Intersection Observer what it is. And then you have an element to observe. Whenever intersections change, it gets called. Your event handler gets called. This, by the way, is pretty much straight out of the code sample that we have online. Sorry. That we have online that's linked at the bottom here. And I have now locked my screen. And I want to switch over to the demo machine. This is a demo that another user created. It's an infinite scroller that works by observing an element near the bottom and inserts more elements. So you can see on the scroll bar on the right, it'll suddenly, when I get to the end, it just keeps going because it's adding more and more and more and more and more and more elements super fast. That's the coolest thing is it's really, really fast. There's a delay as it simulates a network pull of this data. But this feature, actually, when you combine it with data caching via service worker, it's going to be so incredibly hot for doing infinite scrolling of photos and things like that. Let's flip back to the slides. And I did want to mention, by the way, another feature very briefly, link rel preload. The shipped in Chrome 50 lets you, surprise, surprise, preload resources. We had link rel prefetch, but that was really for the next navigate, not the current page. So preload is destined for the current navigation. It lets you, it has an as attribute that lets you set the right resource priority. So say this is an image or a script or whatever. And because it works well with reuse, it can also be used to load but not execute JavaScript. Okay. This is a reminder for me to breathe at this point. So I don't run out of time. I hope you're still with me. We're not even remotely done at this point. But next up, HTTP client hints. Now this is moving to a little bit of a different area. These are HTTP headers that enable content negotiation. But based on the user's device or environment, just like the accept header, let browsers say what type of format they prefer, client hints let clients indicate what kind of specific preferences they have about appropriate data like how big images should be, for example. So the client hints that we support are device pixel ratio, super handy for mobile devices, preferred width for resource, the viewport width, sometimes you scale based on that. And there's also a new one, the save data client hint request. Uh-oh. My clicks got crazy. The save data client hint request which lets servers know that users have a preference for reduced data usage. So either they have high transfer costs like per byte payment or they have a slow connection speed or something like that. So you can say, hey, I want you to use a lower bandwidth version. So this basically, this is something built into the browser. You don't do this in your client code. But on the server, you can respond with one of these headers to one of these headers by passing back different versions, giving it a more appropriate version of the resource. If you know that it's a low device pixel ratio, probably send a lower resolution image and so on. Also in Chrome 50, we finally support TubeLob on the Canvas element. This has been a super long time coming, like I think somebody said six years, but I didn't check back to make sure. This is great news, though, for anybody who generates images on the client side, because if you want to upload these to your server or store them in index DB or anywhere else for future use, you don't have to manipulate a base 64 encoded string that you get from 2Data URL. You can now work directly with the encoded binary data. You can even draw image blobs to another Canvas context with a great new API, the create image bitmap API, also landing in Chrome 50, because decoding images for use with a Canvas, of course, is pretty common. The problem is that decoding images is also pretty CPU intensive, and you always want to get everything that's CPU intensive off the main thread. So image bitmaps let you manage these images without having to do that step between base 64 encoding the data. That way you can pass things back and forth across threads, draw it in a Canvas in the main thread, just like you would any other image element, Canvas video, whatever. And this lets you really optimize your image loading across threads. Another great way to avoid jank. Now, speaking of images, I know I'm going super fast here. I don't want to dive too deeply into the details of all the work across the media stack, because we've done tons of it across WebRTC and everywhere else, and you might expect some of those of you who know me might expect that I'm going to get up here and talk about all the Web Audio features, because I love Web Audio. But I'm not. I'm going to resist the temptation. There are three media features that I want to mention. And the first one is so incredibly boring I didn't even put an image on the slide, because this isn't really a feature. This is actually a Chrome code change. Chrome now has a unified media pipeline that goes across desktop and mobile, and we don't pass off so much to the Android media stack. This unification means we have more consistency across platforms for features like caching, decoding, and encoding, and it makes developing and debugging across these platforms a whole lot easier since it works the same. But the second and much more interesting media feature that I do want to mention is the Media Recorder API. Now, Media Recorder makes it easy, in fact pretty much trivial, to not only capture video and audio, which we could already do, but encode it and save it, like get it as an encoded version of itself. And for all those people who have been pinging me on Stack Overflow for years with Web Audio questions about how do I get an mp3 file to upload to the server, this is how you do it, Media Recorder. So let's take a quick look at the demo. There we go. There's actually sound now, too, but so this is obviously a really simple demo. Let's flip back to the main screen again to the slides, I mean. Thank you. The important part of this demo, though, is this is the main part of the code from it. This is what does the heavy lifting. All you have to do here is create this Media Recorder object with the right options to say this is the type of encoding, this is whether I want video or video and audio or whatever. And then as data comes in, there's an on data available call back, and all you have to do is handle it. And for most types, all you really do is stuff those blobs together. And at the end you just say, okay, give me one blob. And that's your data file that's encoded already for you. You can save it to disk, you can upload it to a server, whatever, you're done. The final media API I want to mention is media sessions. And media sessions is really about integrating with the app's platform media focus. So custom platform media controls or media keys like the play button on my laptop, those things are now exposed to the web. Some of these features are implicit, like media playing notifications. Some of them are explicit APIs you can write to. If you're developing any kind of media playback API or media playback app, go take a look. All right. I want to recognize a few CSS features, CSS variables, first of all, more accurately known I guess as CSS custom properties, landed in Chrome 59. These are great for reducing repetition in your CSS, also for easy theme switching. And if you build a lot of simple sites, not a lot of DOM nodes, no widgets, you don't really, you're not going to care about this feature, just tune out for 20 seconds or so. On the other hand, if you build a lot of complex sites with lots of widgets, use third-party widgets for example. CSS containment helps you optimize the performance by containing the effects of those rules. And you can also use containment to protect your site from getting its performance affected by third-party widgets. Next up, CSS font loading. Font loading was first implemented in Chrome 35, so quite a while ago, but the font face set in interface, which just came in with Chrome 48, lets you check individual font faces and their download status. So all in all, you can really dig into how fonts are actually getting loaded and utilized by the web engine. And at this point, you're thinking, I'm just going to get progressively shorter and faster at dumping features at you and just tell you go look it up. So I'm going to take a quick break from ergonomic features and talking about those. Switch gears, and before I talk about new bedrock capabilities, I want to talk a bit about how the Chrome team has changed their approach to moving the web platform forward over the past year or two. First and foremost, I hope you get Google really does love the web. At Google, everyone I work with absolutely loves the web. And one of the most important messages I hope you walk away from this with is that we believe we have a mission of moving the web forward. And when I say the web, I don't mean the Chrome web. We really want the web as a whole to be awesome. And we don't believe that our job is done until features ship interoperably across modern browsers. Because if they don't ship across all browsers, you don't really get to use them all the time. And as an example, we're not super bullish on the idea of vendor prefixing anymore because that ends up building a single vendor web, which isn't great. Today, we have a four pronged approach to being responsible at how we move the web forward. First and foremost, of course, we have different channels. I think probably everybody knows something about the channels. We have a stable channel that's what average users use all the way to the Canary channel, which is basically the latest and highly experimental features all crammed in. But secondly, we put experimental features behind experimental flags. So if you want to use web Bluetooth, which Pence was going to talk about, you're going to have to go turn it on in Chrome flags. It's not going to just show up even in Canary. Third, we're actually building new infrastructure. This is a new thing. We haven't really talked a ton about this in public, although we have mentioned it before. This feature called origin trials, which is a way of taking some of those experimental features and letting a web developer test it out in the wild briefly via a key that they have to ask for. So it's specific for them. But it is in stable builds. Like it's a feature that's going to get turned on for an average user. However, like you can get broad feedback then, like you can see what happens when an average user uses this feature. But it shuts off after a given point in time. So none of these last forever. They're pretty short term. And additionally, if too many people are using this feature, it automatically shuts off too. Because we don't want these features to get baked into the web platform. We don't want people thinking, hey, this is just part of the web now when they're not. And then finally, we have a core policy of incubating all of our substantial new features. We do this through a W3C community group that I personally co-chair, the web incubator community group. My co-chairs call this the YCG. I personally prefer Wicked, but you know whatever. This is designed to be a lightweight way to make and discuss standards proposals. Like have a semi-organized fashion around it, but you know, not spend all our time planning charters and things, but still properly managing intellectual property and getting all that contribution up front. So all of our new substantial features go through this community group. Okay, and finally, by the way, part of keeping the web platform healthy is removing APIs that are no longer necessary. When they get replaced by new APIs or their experiments that just didn't work out, we should pull them out. So this is actually just the deprecations from the last three releases of Chrome. We're looking at removing bigger features too, like request auto-complete or even HTML5 app cache, but we do have policies about how we can remove them, so don't worry we're not going to yank things out that people are still using. So let's talk about new capabilities that we're adding to the web platform. Before we talk about truly cutting-edge, you know, stuff that is really experimental, since I am on stage, I'm going to seize the moment. I'm going to demonstrate the success of my personal pet feature, and somebody out here I'm sure knows what it is, because somebody asked me about it earlier right before we went on stage. Make sure I'm set up here. Web MIDI. So I can tell a few of you know what MIDI is. MIDI is a more than 30-year-old standard for connecting keyboards and synthesizers, music instruments, keyboard controllers like this one, to computers in each other, and a couple years ago when I first started playing with web audio I said, hey, I really want to control this from my keyboard controller, so I put together a standard, worked in the W3C and we shipped it in Chrome last year. Firefox incidentally just started their code review for their implementation, which is awesome, and since last year a lot of music vendors have jumped on board and started using the web platform to deliver their experiences. Yamaha shipped their reface series of synthesizers with their Soundmondo web app as a way of doing editor library and services. My new innovation circuit groove box. You dump new samples on it by plugging it into the web. You don't have to install software. And the coolest thing though, the absolute coolest thing that I've seen was last year, came from an artist. And let's go ahead and switch to the demo. So, Madion is a French EDM artist. He dropped an album about a year ago, a little over, and he put up this web audio based remix board on his website. Let's make sure we have audio on here. All right. So this basically let his fans, and I am one by the way, I actually really like his album. It lets his fans remix sounds from the tracks on his album. It's like a pre-laid out grid of stuff you can play. But the We Make Awesome guys that he worked with on this, they decided to take a next step and they hooked it up to this. This is a Novation Launchpad. It's one of the most common electronic music production tools. I own two of them. And if you've heard of Ableton Live, this is kind of like a minimalist pre-loaded version of this. And I can control this entire app from this device. Let's switch over to the camera. Let's see if I've got this lined up so you can see it. All right. I really just always wanted to do that. So go ahead and switch back to the slides. I can do that for hours, but I probably shouldn't move along. So my point here, though, is not just, hey, look at how awesome this is or, you know, whatever, because that I could say too. But my point here is that hardware device access unlocks some tremendous potential. Just like enabling accelerometer support, really unlocks some amazing user experiences in mobile devices early on. That's true with other new hardware capabilities, too. We want to continue to unlock those capabilities. So I want to dive into some more experimental features and bring up Francois to talk about Web Bluetooth. Thank you, Chris. My show of hands, how many of you are familiar with Bluetooth low energy technology? Okay, that's going to be fun. So I'm based in Paris, friends, hence the accent. And I'm quite fortunate these days to work on a new Web API that will allow a website to discover and interact with Bluetooth devices in JavaScript. But first, why Bluetooth? I mean, why Bluetooth? The word Bluetooth actually comes from the Danish king, Aral Blatton, aka Aral Bluetooth. So I'm not going to lie here. We don't really know if you had Bluetooth or not, but what I can tell you is that at the end of the 10th century, they were not perfectly clean either. Only enough in the Nordic runes, the edge from Aral and the B from Blatton once merged, consisting the official Bluetooth logo. Whatever, Bluetooth has grown a lot in 20 years along its different version. The latest major one, the version 4, which is like six years old now, introduced a brand new technology called Bluetooth Low Energy, or BLE. So we are not talking about headset, mask, or car stereo system anymore. Unlike other technologies such as Wi-Fi and Internet, which have continuously increased the transfer rate of a diversion, BLE took a radically different approach here. Third, let's try to design a technology that could easily be integrated into thousands of devices that are not yet connected, and that costs almost nothing. It turns out that when you're trying to reduce the cost of manufacturing and maintenance of a device, you are looking directly to its energy consumption. Basically, if you want to create a device that consumes very little nowadays, you will probably use something like a CR2032 battery. Okay, I'm sure I'm going to teach you something, Chris, today. Do you know what means 2032? 20 is actually the 20 millimeter diameter of a balance cell, while 32 is a 3.2 millimeter height. Just to give you a rough idea, the energy provided by this kind of battery allows your body to function for about 20 seconds. It's not that huge, huh? This explains the transfer rate, which are significantly lower in this new version of Bluetooth. Do not worry though, it's not that bad. BLE is primarily targeted for connected objects for which need for speed is low and the autonomy crucial. Okay, then more time. Chris is currently holding in his hand a device, a BLE device actually called the Playball Candle, and this does exactly what you think it does. So can we switch to the computer? Yep. So I'm going to click on the connect button here. Playball Candle is just here. I click on the connect button and now I can just change the color to red, blue, green, and even set my favorite effect, the rainbow one. That's the rainbow. It's okay. It's just a candle. By the way, the Bluetooth Special Interest Group predicts that within two years, nearly 96% of all phones and tablets will have BLE. It's going to be everywhere. Can we go back to the slides? Now, before I show you the web Bluetooth API works, let's review together very briefly some basic concepts of how it works with Bluetooth. So there are two distinct rules in BLE, the central and the peripheral. The device known as central is the one that will search for nearby devices in order to initiate a dialogue. It can be your phone or your laptop and the peripheral is the one that will continuously broadcast its presence to anyone who will listen. It can be a heart rate sensor, a beacon, or a fridge. Once connected, the peripheral will usually stop broadcasting its presence and then the central can start to interact with the GAT server of the peripheral, which contain all the services exposed in the peripheral. There are Bluetooth standardized service such as the battery service, the heart rate service, but you can of course create your own. Finally, each service contains one or several characteristics that have their own properties. You can read the value from a characteristic, like the battery level, or you can write a value to a characteristic and even be notified when a value changes. I will explain this later. So just in short, it's not that complicated. So how does that look like in JavaScript? My web application will play the central role and the device I'm trying to connect to will be the peripheral. So first I want to discover nearby Bluetooth devices. And for that, I will call navigator.bluetooth.requestDevice, which will show me a model picker in which I can pick a device from a list of Bluetooth devices. Keep in mind that this list is filtered with the filter ski of the option object that is anything but optional. The goal here is to prevent the list to contain too many devices. In this example, for instance, I'm looking for a device that advertise the battery service. I did not mention it before, but when you broadcast your presence, you can also add some additional data. So since the battery service is a Bluetooth standardized service, I can simply use the string battery underscore service. In short, once the user has selected a device and clicked the per button, you now have access to a Bluetooth device object that contains device them and the accessible services. There are two important things here to note. First, this function can only be called if the user interact with the web page first. In this case, a click on the button is enough. Secondly, it only works on HTTPS secure pages. Do not worry though, it works perfectly fine on localhost as you develop. What we want now is connect to the GAT server mentioned before, and for that I will simply call device.GAT.Connect and get the GAT server instance when the peripheral is actually connected. And now let's read the battery level of a Bluetooth device. Once I get the battery level characteristic from the battery service, I can now call the read value method to get a data view JavaScript object which contains the remaining battery percentage of the device. Writing to a Bluetooth characteristic is as easy as eroding it. This time, let's use the heart rate control point characteristic to reset the value of the energy expanded field to zero on a heart rate monitor device. What I'm doing here is calling write value with a byte of one. I promise there is no magic here, it's all explained in the official Bluetooth documentation. And now to be notified when the heart rate measurement characteristic change on the device, I only need to add the appropriate even listener to this characteristic and start notification. Then every time its value changes, the B function will be called with a new value. Demo time. Let me show you what I mean by notification. I'm currently wearing a BLE heart rate sensor which measure my heart rate in real time. I'm usually between 16 and 80. But since you are all looking at me right now, I expect this to be a little bit higher. So can we switch? Please. I will click on this little heart, find my heart rate sensor and connect. So let's see. Ooh. Now to prove you that it's really mine, I will do some push-ups and hopefully it will be higher. Okay, let's try. It might go down. It's going to be hard actually because... Okay. One, two, three, four. Is it going up? I stopped moving. I'm sorry, I can't do more. It started a lot lower when you were practicing this. And the demo broke. See? Okay, I'm not the only one having fun with Bluetooth devices. A colleague of mine, Leon, has plenty of Bluetooth toys at home. For which he has created several web applications on his Chromebook. Anchor Drive, for instance, is a racing game in which you control a car via Bluetooth. He also created a web application for a BLE printer. As soon as the famous BB-8 was out, he bought it and wrote a web application for that. A few weeks after that, another developer, Dan Jenkins, hacked Leon's demo to make the BB-8 dance and change color to the Imperial March by using the WebU APIs. More recently, he found a BLE-led device called DoDi at Fry's and couldn't resist to hack it. Finally, he thought, let's insert a Bluetooth propeller into a stuffed grumpy hat, attach some balloon to it, make it fly and control it from a web app. Because why not? If like me, you like to understand how Bluetooth things work, I recommend you install their official Android apps and enable the developer option in the Android settings that allows you to capture all Bluetooth packets. From there, it is as simple as analyzing packets. Google and Opera are, as we speak, implementing this experimental web API in their respective browser. We are hopeful that other browser vendors will follow and eventually adopt this API when it goes through W3C. But the real question is, can you play with it today? And the answer is yes. It is available behind the experimental flag web Bluetooth in Chrome OS, Chrome for Android Marshmallow and Chrome for Linux. If you're a lollipop, you can see a fun with Chromium build. And regarding macOS 6 and Windows support, we are working on it, like really. So here are two things that will help you, hopefully. Get started with Web Bluetooth is a simple web app that will generate all the JavaScript boilerplate code to start interacting with a Bluetooth device. Enter a device name, service, a characteristic, define the properties, and you're good to go. If you're already a Bluetooth developer, then I suggest you give a try to the Web Bluetooth developer studio plugin. It will also generate the Web Bluetooth JavaScript code for your Bluetooth device. It is still early days, but I think you're gonna like it. Okay, so here we are. Website can now control Bluetooth devices just like native apps. Bravo! Okay, calm down. There is a big difference here. A web application, I can share it with a simple link that anyone can open in a browser. It may sound stupid slash obvious, what I just said, but this is the power of the web. Today, to interact with a Bluetooth device for the first time, here's what I have to do. Go to a store, accept the terms and conditions, authenticate myself, search for the app, install it, accept the permission, launch it, scan for nearby devices, and only then I can start to interact with the device. Wouldn't it be great if I could just keep the last step? That's exactly one mission of the open source project called the physical web. Make interacting with smart devices as simple and fast as possible. Okay, so how does it work for real? I will be brief here as the physical web session already happened this morning. But again, this is very simple. Each Bluetooth device will continuously broadcast in addition to its presence, a URL. So now, as long as Bluetooth is enabled on your phone, you will get to see in your notification bar some URLs filtered by your web service which are broadcasted by nearby Bluetooth devices. Think about a burst that can tell you it's next stop, a parking meter that lets you pay when you adjust your phone in the cloud, or even just a dark color broadcasting its under contact information. It is already available to all of you on Chrome for iOS and Chrome for Android. So now let's step back a little bit and think about the integration with the web Bluetooth API. Imagine if the website broadcasted by the Bluetooth device would allow me to interact directly with it from my phone. At no time I'd have to install an application from a store. A simple click on this physical web notification would be enough for me to get to interact with the device. This is the power of the physical web. The web Bluetooth is about to implement this feature with an upcoming object called referring device. This will allow you to access directly in JavaScript to the Bluetooth device that broadcasted the URL when user clicked on the physical web notification. So let's wrap up. I realize this might sound overwhelming so I recommend you simply google web Bluetooth samples at the end of the day. We'll find all samples, articles, specifications and demos. And we even have two code labs you can follow in the code lab area. One will take you through all the steps to create a web app to control the playbook candle and another one to learn more about the polymer elements dedicated to web Bluetooth. And with that I will give it back to Chris. Thank you Francois. So we are pretty much out of time. One final hardware API I want to mention that we're exploring is web USB. Now don't let the title scare you. The idea is not to let the web get access to every USB device in your computer or device. That would be a little crazy. Web USB is about enabling specific new devices that have their firmware available to be accessed by the web, that actually say I want to be accessed by this domain. So this is really more about enabling a new class of devices than enabling current devices to get access by the web. I want to wrap up. There is tons more going on on the web that we couldn't cover here. Web VR is awesome. Presentation API, motion paths and CSS. So much good stuff. There's even stuff that we haven't really even totally started designing yet. Persistent storage, web intents to let web apps actually handle other data and do something interesting with it. But we are out of time. I hope you're as excited as we are about the future of the web platform. Watch developers.google.com slash web for more and I'm going to personally be running over to Rahul's presentation in the amphitheater right now and hang out there for a while. But we do have mobile office hours this afternoon from five to six. And I think Francois and I will both be there if you have any questions. Thank you.