 So little do they know I don't think I've actually worked out the bonuses yet. So it's fine Everyone my name is Paul Kinlan. It's great to see you all here. I've had a really great two days actually. Is everyone had a good two days? Everyone's been super awesome I'd really liked the conversations that are going on over lunch over the breaks as well Like there was a question before about kind of web serial and stuff I saw That's a big one a lot of people are asking for and it's kind of cool that you can go up to the Chrome engineers Actually pitch them for it. So I think that's pretty cool. But anyway, I'm here to talk about the what comes next I don't know how long I'll take. It'll be all right. I think we'll get out pretty soon. It should be pretty cool The like the thing I was gonna say was that this part of the talk and I need to stand before this in fact This part of the talk was it was supposed to be just after Jake's talk and Jake was supposed to talk about all the practical Things right the things that we want to see from the future the web in terms of like the Infrastructural elements, you know the improvements the service worker the improvements the network stack with fetch and background sink All these types of things and then I get to talk about all the kind of the show busy things, right? Like web VR and all that type of stuff. So like this was me experimenting with it in like I think 2009 2010 or something And it didn't work in the slightest. So I just whatever It was kind of it was kind of fun to play around. I thought I got gyroscope. I've got canvas. I'll be kind of cool Nothing worked. I'm terrible But anyway, one of the things I'd like to talk about and I was trying to think about how we frame this talk is that If you think about like back to two years ago, Alec Russell was talking about one of the or a year ago Alec Russell was talking about like distribution is the hardest problem in software, right? And the web for us is actually a great way of actually Distributing our software because you just click on the link and go to the places And if you've got any experience helping your grandparents or if you ever worked in like an ink like in a big enterprise Like you'll get these types of experiences where you have to go through and you have to go install the applications and you Go and download them and it's just such a nightmare And it's like who works in is anyone worked in enterprise deployment at all and a couple of people like it's an absolute nightmare You build big pieces of software to deliver to enterprises Then you have to go on site and have massive teams to go out and build all this infrastructure And one of the things that I liked and when I used to work for experience in years and years ago We moved from this type of model into kind of the web type of model and for us that was great right we could just go to the user and saw the the customer and say go to this URL and Log in with your account details, and you'll get this experience It was a really great model for everyone But the interesting thing was like we knew at the time it was like way less capable the browser You know although you had active X and a bunch of other stuff The browser didn't do a lot of the things that you'd expect a native application to do or a native experience at that point But we traded that off Like we just said the model for delivering this software out to users and all the like the enterprises and Any user that's out there is like it's way better than the model that has existed in the past And I tried to think about this model of like distribution, right? So in the 1970s you'd buy an Apple machine and you'd build it and have to construct it yourself and take it home And then you have to program the software that was on it and then later in the 80s You could go to the store and buy the software there And by the 90s the web came in right and like that's the start of the change Right we like you could build webpages that were based on CGI at this point with a little bit of JavaScript Occasionally and then actually start to build interactive experiences where you know immediately you got a lot of value from like the web I think that's quite powerful But at the same time like native platforms are starting to catch up right native platforms Especially at the time around like like specifically the iPhone came out is that you know obviously we waited a little bit longer But for native applications to come through this but like at that point in time We got to the bit where the web is great everyone likes the distribution model of the web We need to solve this for the platforms that we're shipping at the moment and obviously things have changed like app stores come along And in the future like chat applications and other kind of different social media Or not social media, but like different types of experiences will enable people to distribute software more effectively And I think and I want the web to play a massive role and kind of make Like be everywhere in all these platforms and be the key reason why you'd actually deploy on the like deploy Software because the web is a great model But the way I try to think about this again was the reason why a lot of people And at least when you speak to a lot of developers why they moved to the native platforms and went with like native kind of say native hardware or native APIs was It's kind of weird right like when the iPhone first launched the web was the way that you delivered the software Right everyone said like this is the way you're going to build applications They introduced a whole bunch of new APIs that were media queries local storage web sequel Appcache, you know, there's a whole bunch of different API's that got launched to support the ability to deploy kind of comprehensive software on the web Through mobile devices, but then everyone was like, yeah, that's cool But we want like these native API's we want this kind of ability to have a distribution platform Like and then that took off and at the time the web was just like We'll catch up at some point and kind of like continued on for a long time without that much change right? We thought we had all the primitives on the platform to be able to deliver a comprel Like a comprehensive and compel an experience, but like it wasn't until kind of I guess all these numbers by the way About 2012 like we didn't actually have I think 2013 was when Chrome came to Android at this point But we didn't have like a compellingly competitive mobile browser ecosystem at the time And we weren't pushing out all the kind of the features that we needed We knew we needed to solve payments We knew we need to solve all these other pieces But we didn't really have the kind of the emphasis behind it to do it at the time So I was thinking about like what is the game plan for the web and like Right, so the whole thing about this is You ever seen a presentation by Paul Lewis where he draws like these are most amazing pictures that he has custom slides Every single thing was like I'm gonna do better than that. I'm better than Paul Lewis So I bought an iPad and a pen and that is all I could do So anyway, the whole idea behind this was that I was thinking about like what is the mobile game plan? And at the time and like for the last three or four years Oh, maybe three years at least anyway, like it's kind of everyone's like incentive to say we just need to catch up with native Right, we need to have a whole bunch of these features where we know that native is doing it It's obviously it's very hard to kind of get this all going with the specification groups and you know Other browsers kind of collaborating, but you can start to see a trend, right? You can start to see more kind of involvement across the ecosystem say, yeah, we what's this one? We need to geolocation JavaScripts came through straight away, but you know, we didn't have access to the camera So we've got get user media. We got all these other different API is coming through We're not kind of completely compatible across the entire browser ecosystem on them at the moment But we have the ability to try and solve those problems and I think it's interesting that we are reaching more of kind of the native Parity at the moment, which is kind of cool. So Actually, I've lost the slide. I was on sorry. So this is the kind of the graph that I've got is like Like we've got all these new API is coming in. I think it's quite compelling that, you know We've started to see a massive change in the industry, but there is still a lot more to think about So we've got things like you obviously like geolocation is one big one We've recently moved out to the kind of HTTPS only It annoyed a lot of people that we made that change, but we think it's the right thing to do for your user security Actually, we've got cameras, which is kind of cool Like the interesting thing about cameras and I'll talk about cameras in a minute Is like we do have access to the ability to do inline camera access We also have the ability to fall back as well So if you have like a native camera application like an iOS, you can choose to choose that again Limited only to HTTPS and this is a common theme across all the new APIs coming through to the platform It's that they have to be on HTTPS. We think they're powerful We want you to use them, but they have to be secure and you know users have to be able to trust that, you know Trust the trust them at that point and again an extension for the camera microphone again Same restrictions. You have to be on HTTPS has to be user user Granted permission from there We had the battery status again. This is a little bit contentious It's been removed from some browsers at the moment But the idea is you can understand whether you know people can access the hard like people are actually trying to power the device So you can maybe give a different experience if the user is low on power You can say hey, we're not gonna do all the kind of fancy animations I don't think people are actually using that API this way at the moment I don't think many people are using that API, but like that's what it's there for at the time We have permissions on the platform so you can actually build compelling Experiences in terms of like we know that you've got access to geolocation I'm not going to try and prompt for geolocation straight away So you can understand the state of the permission model that the users accepted like there's a lot more things to add into this But you can start to provide more compelling experiences And this is especially important when you're kind of building full-screen applications as well We have network information a lot of developers, especially when we've been out to India of asking say We want to understand the type of the network that the user is on so we can adapt the experience I don't think we're actually using this to our full advantage at the moment We've got things like a thing called downlink max which basically says hey We know that the user is on a at least a 2g connection or at least you know They can have the speed of the 2g connection, you know, you might want to do something with it And again, I don't think that many people are using it right now But you can start to think about how you can adapt your user interface and your experience to the needs of the user based on the Types of network that they're on I think it's quite compelling. You know got auto fill It's kind of boring really hard to get people excited about auto fill But we know that it improves the overall experience of the web like for users We're trying to fill in data. Everyone hates keyboards fill in forms We really encourage people to use auto fill, but no one really does but like that will change over time I think Because we know it has a measured and improved benefit for users at that point then obviously we saw the credential management API yesterday I think that was actually really cool, right like you can get one tap sign in have it synchronized across all your devices That type of experience is a really great experience Especially when you're thinking about kind of cross device crossform factor conversion at that point and then obviously the payment request API It'd be great to see whether this comes through and you know how it's kind of supported across multiple platforms But my whole bit about this is that I rethink and I think Zach said this yesterday is that you can start to think about Amazingly compelling guest checkout flows once you know that the browser supports the credit card information or the payment kind of Has the payment information that you can provide across platforms or at least cross the you across the device Then once you know that you potentially got that you can start to think about well I don't actually need to sign the user in to be able to get them to make a payment I can just take the payment and then ship them the deep ship them the product after the back of that Which I think is powerful and obviously push notifications Everyone's been talking about push notifications for a little while now We know that this actually has a material impact on people's kind of engagement and revenue and you know re-interaction and everything And it's great for on the special mobile it works from the browser closed You know I'm not going to talk about this too much today But like this is one of those powerful API's where we don't need to build a full-on progressive web application to actually start to take benefit or make Like receive the benefit of actually seeing this API or using this API at least and obviously we've got offline support Right, we've been talking about kind of building these offline based experiences for a long time now We we've got the kind of the tools on the platform across most of the most of the platforms And even if you want to if you want to fall back to our cash We don't encourage it you can actually start to think about how you build these experiences And it's not just about offline full offline support It's about kind of thinking about resilience of your application in terms of like kind of an adverse network at that point So I think it's pretty powerful and finally we get like this whole idea of install ability You get to the point where if you meet all the criteria if we think your application should be installed or could be installed Then you know you'll let the user say hey we can install this and it will be on the user's device Working like a kind of a native application would at that point and we think that's pretty powerful We think it's pretty good But the thing is I just it's just a big list of API's right like we're just talking about these different kind of API's one after One after one we know that the next API that we need to build is the most critical API that we need to solve And I think that's the thing that I'm trying to say here is like We did a whole bunch of API's that we kind of thought we're kind of cool to start off with getting camera access great But it wasn't until the last maybe two years we've had to say well actually we want to build these resilient applications that act like great in this In the face of adverse networks and actually get the point where we need service workers We need to make them installable we need to know that users want to get re-engaged them through push notifications It's been a lot more tactical about how we actually start to implement those API's which I think is a good thing But it's like kind of it's hard to actually see that strategy kind of playing out I the thing that I want to get to this point though is like It could still get to the point of like everything is just a random API that we start to build like it could be that like I'm not pointing out the web serial API We know that there's use cases for things like the web serial API But we have to think tactically about how those how we bring those like API to the web because there are some really important things We need to get done And the thing is like we don't want every single API to be like hey native has got this I'm actually going to talk about some of these ones. I'm kind of a Conducting myself a little bit. We know that like the native platforms have got this We're not going to implement this directly We should think about how we want to kind of have them in the context of the web and the context of the web is the thing that I'm kind of interested about and We were thinking about it on the Chrome team a while and they don't really like people using this this acronym at least because it's an acronym and like if you've ever been to a Chrome dev summit you get rail you get amp you get PW The world is full of acronyms at the moment But the reason why I like this one is slice is that it at least codifies some of the reasons Why I think the web is important the benefits the web that other platforms don't necessarily have So slice is kind of simple you secure the idea is that we've got an overly restrictive Permissions model and a security model where everything sandbox you know in the past we've had some issues But the idea behind this is you don't automatically get access to everything on the user device You know you have to kind of do it kind of you want access to the camera You have to ask the user for access to the camera like those types of things So it's secure. It's sandbox You can't just go and pull out data from another website that the user might have been to like the whole The web ecosystem is kind of conscious about security and I think that's a very kind of cool thing for our side of things The web is linkable. It's really hard to find a set of links of the last two days, which haven't been Interesting I suppose But the idea behind it is like we have these links once we have the links We can do really interesting things of them like we can build these types of sites We can build indexes we can build news like news. Why combine calm because because it's a link We can go to it and we can do things with it And then once you think about the things that you do with it like index ability, right? That's the heart of Google for our point point of view is like it's indexable We can go and archive and organize and aggregate the world's information provide I don't know. Does anyone else know what the do you know what the our mission statement is? Sorry, I'm pushing point to my boss here. No, cool That's the one but like that's the whole point right is like we can go out discover the data It's an easy possible manner. I'm sorry about that by the way It's an easy possible manner we can start to understand and then we can do interesting things because it was indexable and because it was linkable And then the idea behind it is like that the next bit is like and we know this from kind of the whole start the Ajax era Was it's composable? We can take you know take like JavaScript from somewhere we can take an iframe I know pulled in like the iframe thing before but we can start to mash together and build interest in applications just off the fact that Other interesting applications and components exist on the web I think that's incredibly powerful and then I think like the whole idea behind the femurality. This is The Guardians mobile at the we were out in one of the breakouts before Guardians mobile labs experiment of like ill deliver you news Via notifications you go in you install it You forget about the web page You never have to go back to the web page to start experience in these applications Like it like normally the web lives and dies when the browser tab closes service worker changes that a little bit But like these types of experiences we can build where we say like I'm gonna use it once and in this case I was using it this wasn't for brexit, but like it was on for brexit and we got to it I fell asleep I got all my notifications and I saw kind of brexit play out via notifications once I'd kind of cried a little bit and then Like closed everything it was closed It was gone and never received another notification again And I think that's a very powerful model for the web is we don't have to think about these experiences where you have to Install it and start to use it just to get some experience out of it Like you can live and die with kind of how you want to but the thing is like slice is just a model Right, it's it doesn't cover all the other benefits that we know of the web, right? It's accessible should be available for everyone to work on and use Irrespective of kind of like whether they can actually see it where they can hear the kind of the experiences from it or even actually interact with it It's installable like it's updatable. It's deployable like it's composable like there's lots of even more I've said composable once before but like there's lots of different kind of properties that we know the web to be that Actually, just don't make this acronym make a lot of sense like if you think about it We've got this idea of like huge amounts of different properties like but this is the thing Actually, I was speaking to one of the PMs the other day Like I've got this massive ecosystem, right and the thing I liked about the way he was phrasing this like it's a massive ecosystem You can pull in from all these other tools from around the around the web You know lots of other web developers are building on it if one of those kind of industries goes away It's fine, right because more people kind of come back in and likewise. There's no one owner for it as well So you get to the point where Excuse me you get to the point where there's no one owner for the web. It means you're not behind a gatekeeper You've not kind of controlled ultimately By their whims at that point we can go out deploy it and as long as you give the person the link They can access that link. They can start to experience your experiences. I think that's incredibly powerful So for me one of the things I was trying to think about is like if it's not just about a feature race What is it about? Well, we've done been doing a lot of work I think over the last two days We've seen some of it by Rick Byers and everyone as well is we want to smooth out the platform We do definitely want to reduce the feature gap But we want to do it in a way that enables brand new styles of content and new like new levels of interaction That we're never going to see from any other platform Unless it's the web. So one of the things I was thinking about the smooth line out of the platform This is the second image. I drew with the iPad. I Was actually quite proud of it. Everyone else hates it But the idea is like you have this like kind of level of lumpiness, right? Like the web is not even not every single browser implements every single feature and as web developers we quite frequently find that really really frustrating But the interesting thing for us is like there are really big things and some of these big things I'm going to talk about today like things like Bluetooth or ES6 like you know that it's not there But you can kind of see it right so you can kind of ignore it and go around it and say when that becomes ubiquitous I'm going to start to use it But then there's like the really frustrating things like things like flexbox where there was two different Implementations of flexbox and it's really hard to work out which individual browser support which individual version of flexbox and which syntax Like those types of frustrations really kind of well they frustrate developers means that you can't build great experiences for your users That are responsive and accessible for everyone So one of the things that we've been trying to do is like smooth out some of those rough edges And then the first one and it's the one of the most recent is like position sticky is like one of the ones Developers have always wanted right they've wanted the ability to say anchor an element to the top of the viewport And we had it in Chrome and everyone's like that is great, right? Apple have got it Chrome's got it I think Firefox had at the time and we were like yeah, it doesn't stop that performance So we're gonna remove it by removing it at that point. I mean it might have been the right thing to do ultimately You know we got to the point where It wasn't compatible right so people couldn't use it you couldn't rely on it So you couldn't build the types of experience as that, you know It like this is not a great experience of where you might want to use it But you couldn't do it without JavaScript at that point You either have to include it or not include it and for developers that is actually a really frustrating part of the experience for them And then we get this idea of things like Intersection observer right we know that the web is slow when you scroll and you're trying to kind of keep something in the View or know when something has gone into the view now This isn't necessary about bringing like ubiquity to the platform because I think Chrome is the only one that implements Intersection of intersection observer at the moment But the idea behind intersection observer is like we want to kind of provide a level playing field for performance as well So you can start to understand when elements come into the viewport and when they leave the viewport So that then you can do your kind of your room or you know Whatever you want to do with your whether it's ads or whether it's some of the types of logic as well Which I think is really cool because then when you start to think about the next part of the future And like this is one of those ones where like this is really hard to actually see in terms of the code And there's not a lot of detail in this. I stole this from Paul Lewis's Polymer talk, which is actually was a really good polymer summit talk, which is a really good talk But the idea behind it is like custom elements for a long time have been kind of talked about They've been deployed in some browsers We didn't deploy it completely because we had a v0 and now a v1 I think now now is the point on the web where like developers have been really frustrated that they couldn't do these types of Experiences it was completely That's my uneven is the easiest way of saying it at the moment And it's great to see that you know, this has come to a lot more browsers at the moment Definitely in Chrome the latest versions of Safari definitely had template syntax And now they've got custom elements as well in the shadow DOM So like that whole part of the ecosystem is all starting to play out And it's great to see that a lot of the browser vendors are all starting to work together on We know that these are the important APIs that need to get done Developers have been saying that we need to get these APIs completed and finally we're starting to kind of get around a picture And on that subject is another one is like we as on the Chrome team We made this decision to not support pointer events I think about two or three years ago we had said we don't want to introduce multiple pointer models and multiple interaction models to the web We don't think developers want it Microsoft's like, you know developers do want it You know, we've got this experience They want to have one unified model of interaction interacting with things like touch or interacting with things like the mouse pointer They don't want to have to deal with all the different ways of doing it and so developers shouted a lot and Rick Byers who was on yesterday was one of the engineers who started to kind of implement that and flesh that out and now Pointer events is in Chrome So we're trying to start to bring more compatibility to the web to like level out that part of the playing field So it for you as a developer it makes it ten times easy to work out whether you what you should support and how you should support it So I think that's pretty interesting and then also like Darren mentioned this in the keynote yesterday is that Like we've been pushing progressive web apps for a long long time, right? And we've been so I'll say about the last year and a half maybe a year Now the whole idea behind it is we want your applications if you want them to and the user wants them to to act and feel like A native like experience like if it's if it's installed on the device It should appear everywhere and if you've actually ever installed one of these like yes, you can get it on the home screen You can launch it and it's in the tab switcher, but that's when they kind of the illusion breaks down after that, right? Like we've got a nice model But it's a massive uncanny valley at the point of like these aren't actually native applications on the system They don't leave like you live in the app view And there's a whole bunch of other kind of edge cases that every single developer is implemented a progressive web app Either with push notifications or not has been complaining about so what Darren was saying is like we actually want these Experiences to look and feel like they're native and so this is the flow that we've got I think This is the add-to-home screen flow normally or not the add-to-home screen flow normally This is the the new kind of install flow So we've taken the whole idea of add-to-home screen Which essentially was a bookmark on the home screen with a special parameter that chrome new how to launch the screen Into a fully kind of native model So the application is downloaded installed. It's still a progressive web application at the time pulled everything's pulled from the web It's not anything kind of packaged up and everything, but it's a native application on the user system at that point I think that is incredibly powerful now You can experiment with this today and I'll show you how to do it in a minute But the idea behind it is like we want to experiment with this It's a flow that we think is gonna work, but we do need a lot more feedback But once you actually get these applications installed is really good So one of the kind of things that we've seen is that we've got the like developers wanted the on users at least as well Wanted their applications to appear in after and other elements of the system you are as well So it now appears in after you can actually go and inspect Like the like the storage model of it as well So you can see the storage storage will be allocated to the application Not just the chrome or the webs like the like chrome as a whole and then you can do a bunch of other stuff as well So you can force install force stop it uninstall it You know you get access to the like the battery profile and a bunch of other stuff So your application is ultimately accountable versus just being accountable to the browser at that point We also get deep integration with links So if you own like in this case air horner calm and the user clicks on the link to air horner calm Rather than go into the website You'll go directly into your native application at that point or your progressive installed web application at that point And I think that's pretty cool because all you have to do is update the manifest to actually say how it should actually be intercepted on the user system and likewise for notifications like you click on a notification like the Boogs that we had on the system where like you click on the notification and it go to the actual web app versus the thing That was installed on the home screen, which essentially are the same thing We just didn't know we couldn't launch the application at all because we didn't know it was installed on the home screen at That point so we kind of leveled out that part of the playing field So it's a lot more compelling a lot more natively integrated at that point Hey, thank you The other thing as well as we do continue to respect the launch information as well and the interesting thing about the launch information is that obviously when you click on the home screen or you click on the link or you Click on the notification You do want it to launch in portrait or like if it's a game you might want to launch in landscape those types like that type of thing We've been we've had a lot of trouble actually making sure that was synchronized across the entire device The cool thing for me at least anyway is that the biggest thing is that we can keep the application name and launch profile in the manifest Open in all that information up to date as well So the good thing is like if you update your manifest right now because it's just a bookmark We don't know whether your application is updated We don't know that you've changed your name or the icons change a little bit those types of things We now have the ability to actually say we know it's changed We know that the user's got it installed and we can update it across the device as well Which I think is actually pretty powerful and the great thing is like if you're already building a native or a progressive native web application That's not the word to say is it if you think you're building a progressive web application Like you don't really have to do anything you have an optional scope attribute and that's pretty much it the scope attribute just says This is the URL string that if the user clicks on it will be open We'll cause my native app or my web keeps a native application my progressive web app to open up. I think that's really cool So it's experimental today If you just go to Chrome flags and search for enable improved add to home screen You'll be able to get it and you know, it's it's actually really interesting But the thing I would say is we do want a lot of feedback around this because we want to make sure that the model works for users Works for developers and we can go more from there But I did say that was kind of smoothed out the platform I think a lot of the things that we've been talking about is just making developers lives a little bit easier I do want to talk briefly about kind of decreasing the feature gap because this is where for me some of the show busy things come in but the interesting thing about the Like this is that we we're in this weird tension where there's a lot of new APIs come into the platform Some of them are not completely specified at that point like in the past You go through Chrome flags and you enable it to test the API But that's actually really hard for doing kind of in this case Alex Russell was saying doing science on the web at scale Like if you want to know that an API works with all your user base and how it works and how users interact with it You somehow have to get that out onto a stable channel somewhere But if it gets out into the stable channel and then developers start finding it like the old kind of say web Kit prefixes, but the old prefix model like that causes a lot of problems in the long term for developers And we don't want that to kind of happen We want to be responsible about how new features and new APIs are designed but tested at scale So I definitely encourage everyone to look at Alex Russell's post on this because it gives a lot of insight about how we're thinking about this model But the the name and Alex alluded to this in the panel session is origin trials Now the idea behind origin trials is that we sit there and go well We think that this API is going to be important like in case of web Bluetooth or web USB or persistent stores that true worked on We know that this is like an important piece like of the overall kind of API ecosystem It's not fully spec specified just yet, but we want to get it tested out. You have to sign up for the API There's there's basically a link that you can go to on any of these pages You sign up the API you drop it inside your web page in this case It's a meta tag and then the whole thing is designed to kind of I don't want to say fail But it's kind of it's designed to only run for a certain amount of time So this is like as a developer you know that you're opting into this experience You know that at some point the API will change it might change significantly It might actually get pulled out once we know that we don't actually want to ship or developers and users don't want this to see This shipped on the web But the point is that these origin trials Allow you to have that flexibility to experiment with the API give us a lot of feedback And then we can actually help kind of help the specification process move along a little bit more effectively And one API that I want to talk about that is behind an origin trial It's quite close to my heart is the web sharing API Like I used to work on the web intense API and the whole idea behind that model was to say the user should be in Control of the applications that they use to perform common tasks So if you want to edit an image you would use the image edit an application That was on your site or inside your native application or inside your device at that moment the problem with it was it was too broad We learned a lot about building ecosystems and building API is where you know It's an undefined scope and undefined kind of range about how big this should be We got a lot of feedback from developers like well I don't want to edit and I don't want to save I'll do an edit and save intent at the same time Like it got to a point where we couldn't feasibly deploy this API at scale So one of the thing was we said we should go back to the drawing board and design smaller chunks But we should try and solve the sharing intent We should try and solve the different kind of aspects of What we were trying to like the original vision was going to do but do it in isolated sense So this is the sharing to app or this is story. This is the web share API at the moment It's an origin trial inside Chrome. You have to subscribe up to it. We're testing out We want a lot of feedback around this, but it's a simple API cool It's alright in it. It works pretty well But the idea behind it is you just share some data and then that will be passed to the underlying kind of sharing information like in the case of Android It will just do a Faro basically ascending tent and then the application pick will pick up and then you'll be able to share the data to it Like it's got some problems still we need to flesh out images and a bunch of other things But the capability is there We've got the ability to test this on sites with every single user who say visits my rather low traction block at the moment But I think it's a powerful API But that's going from web to native right and what we're saying is we want the web to be across all that like the user's ecosystem So in this case we want the and this isn't actually ready yet We're still trying to wear this up But like the web tag API the idea is like your web application should appear in the native picker now We're trying to do this by the web app manifest and then also the service worker as well But like this is one of those things where the intent is clear right? We want to make sure web applications if the user installs them act this first class citizens on the web I think it's pretty powerful There's also a whole bunch of media improvements as well And this is where things get kind of a little bit more interesting at least the whole media team of them working on this idea of you know Developers don't have to do everything like we can provide a lot of integrated experiences with them like with the user's device So the first thing that we did and this was about a year ago was anything that you did if you had like a connected Who's got an Android where device? It's more than I thought actually it's cool cool. So if you'll play if you'll play Normally normally no one puts the hands up, but if you're playing If you're playing some media you'll be able to kind of that notification will get generated on the user's device Passed across to your to your watch and then you control it from there The developer doesn't have to do anything and that's actually pretty cool You get this kind of thing for free again kind of just making the platform a little bit richer for web developers We've also got the ability to do things like background play so you can take You can take it like a movie file or an audio file Close it like close it down or close your turn your phone off to go to the home screens go dark And then you can just like still control the web experience I think that's actually quite powerful Like you can start to think about podcast applications and music applications Which you can just run like in the background continuously still but have the ability to control them from the web and from the user's device And then if you move a little bit further on some of the rest of the work that the media team are doing And this is one of my fakes like I did a little Demo is one which I think I quite like but anyway the idea is like capture stream Right, you want to record something from a canvas and actually record it into a movie file, right? Like a lot of people have been doing this to try and generate Like animated GIFs and a bunch of other stuff and movies like there is a dedicated API now canvas dot capture stream It's an X it's in behind Chrome flags at the moment I should know it's on it's in canary normal. Anyway, you basically get the canvas You say I want to capture it 25 frames second and in this case, I'm just gonna attach it to a video element It's probably not the best use case to do anything with that video element But it's a stream you can put it onto something that can read streams And once you can put it onto something to read streams is you can do things like well I'm gonna put it on a web RTC connection and I'm gonna send it out to someone, you know in Australia And we're gonna kind of they're gonna be able to see what I'm doing on the screen like inside my kind of webGL 3d Game which I think is pretty powerful, right? Like it's very hard to do these types of experiences Like on any other platform on the web now with three or four lines of code And you can start to stream your experiences with your kind of friends and family And one of the things I do like is that you can then think about well, I've got the stream I actually want to record it and actually kind of save it because I can persist at the disk So this is using the media recorder API which takes the stream from the camera at this point And then when the data kind of comes through you append it to a blob And then you just start recording and then once it's completed you get the blob and in this case This is the demo that I wrote. It's a little bookmark I wrote finds a canvas on the page Download records it stops after 10 seconds and then downloads it as a webmpile to your hard drive at that point Like it's 20 lines of code and you can get this experience where I've not actually seen this type of thing on the web before Record a webGL game kind of throw up to YouTube, but it's pretty cool and pretty powerful. I think at that point But once you kind of have the camera like the camera and this is the thing that most people don't know is like you You have the streams coming in you got webRTC you can send a video stream now You can send a canvas directly to the user One thing that everyone says like we can do a lot with the kind of the user's camera right now We've got get user media which gets that stream from the camera. That's like a camera app But we only found this out maybe about six months ago if you actually capture a frame from the get user media API It's only like a 1080p. It's not like a raw full dump of the entire kind of camera frame at that point now The thing is we've got the Image capture API it again It's in canary at the moment But the idea is you can pull in to get using media stream say I want to take a photo And it will give you the photo like the blob of the photo at that point So if you've got a 21 megapixel camera in theory, you'll get a 21 megapixel image Which I think is pretty powerful the more important thing is that you actually get to understand the settings and capabilities of the camera We haven't had this before right we can take the media stream and say what can I what can this camera do? Well, I can zoom in you can control the ISO you can auto focus you can do all these other things with it We now get that piece of information You know we can get that back and once you can get that information the next thing to do is can I do something with it? Well, the answer is yes roughly and it's like the idea behind this is you if you know that the range for zoom is that you Can say well, I want to do a double zoom and the idea here is that you know You will obviously do the zoom and this is the video at least anyway I was trying to record the slides and it didn't quite work, but the idea is You have the camera you change the properties and it updates in real time And then when you take a photo it'll use those properties as well again I think that's pretty powerful We can build kind of full-on camera applications not that we need to but we can have build full-on camera applications on the web And I think that's pretty powerful and then one of the other ones and this is this came in last night So this is one of those ones where I was speaking to one of the engineers on this Miguel and he was like poor I've got this API for you. Can you talk about tomorrow? I said, what's the API? Because I'm gonna run over time and I've run way over time now ready He said I can detect faces got an object detection API in the future. They'll do QR codes You'll do barcodes right now. It does faces. I was like, nah, that's not true And you show me this is the code right you basically do face detector You detect the faces with the image that you've just captured from the image capture API And then you can start you can pass it to the underlying kind of system behind the scenes And then it will find the faces and you get the information that comes off the back And I think that's actually pretty powerful right is like I built a QR code scanner A couple of years ago and to get it running at 60 frames a second It's an absolute nightmare to do and if I have one API that lets me do that Like that is actually really great thing for me at that point So that kind of brings me on to the next bit is like we have this idea of sensors behind the scenes in terms of like face It's face detector sensors not really a sensor But it's a thing that is there that pulls out data from the underlying device now The generic sensor API is an interesting one because the idea behind the generic sensor API it basically provides a common I need to get this right but like a common abstraction for how to access hardware Consistently inside the browser that the browser vendors have a way of saying we've got all these different API like a gyroscope We've got accelerometer. We've got all these different ones like how do I kind of access them consistently in a relatively sane and Like equal way across all the different sensors This has been kind of in you know in edit mode for about a year and a half I think about a year and a half It's only recently that we've started to actually put this inside the browser and it's on There we go This is the I'm really proud of that demo because I was like that's gonna annoy so many people But the idea behind it is you can have a sensor that is like what the ambient light sensor in this case it landed in Chrome In canary do the day and the idea behind it is it just reads the light values from the image sensor or in whatever kind of sense that you've got which can actually detect light levels at that point you Initiate the ambient light or you get a hold of the ambient light sensor You put a handler on it for on change And then you start it and then it will deliver changes as it may be a specified frequency if you want You know regularly to your on change handler You just put your application logic in there and you can kind of do whatever you want the interesting thing about this API is that you Can also pull as well So if you don't want to have like an on change handler always firing But you only want to do it kind of synchronized to a frame you can actually say well What is the data from this sensor or what is the value of the sensor and it will turn the last last value? And I think that's quite interesting ambient light I don't know how much use there is you might put a dark mode inside your application Or you might do something super annoying But it gets a little bit more interesting when you think about like a compass right a compass needs actually I didn't realize this I just thought it was like the alpha component of the orientation it actually needs multiple sensors to be able to build a compelling compass for the web and Kenneth from Intel gave me this demo, which I'm grateful. I think he's up there. There he is. Hello But the idea behind is it there's multiple sensors. You need the accelerometer and the gyroscope To actually start to think about like how you can actually kind of get the proper compass values and at this point like it's quite simple you start both the sensors up and then you kind of get the changes then you kind of You sort of store the changes in some global state and then you update when you when you need to render at that point It's just quite simple at the logic behind this is quite like it was harder than I thought it was using quaternions a whole bunch of other stuff But like that whole point is like you've got two or three sensors on the device You can start to do really interesting compelling things with them once you start to get that data through and not necessarily You have to rely on a browser vendor making the compass API at that point just to actually solve those problems And I think that's actually pretty cool Should I just talk about the wrong slide? I didn't play the video. I'm sorry about that so That's kind of like the newer API is coming through I think some of them are pretty cool like some of them are very hardware driven at that point And the one thing I do want to try and get across at least is that I I want these web APIs to kind of I say mimic native That's the wrong way of saying I want all the capabilities of the native platforms to be very be available to web developers But I don't want us to kind of like lose our soul at the point of saying that we must have the exact parity with those APIs There are very webby things that we can do that no other platform can do and like that's one of the things I think is pretty cool, especially on the whole ephemeral aspect right is like for very short lightweight experiences You know whether it might be a marketing campaign that a lot of people get asked to build or just even things like the election users Like you don't want to have to build a native application deploy it through the stores You just want someone to go to a URL and start interacting with the experience and then when something happens be able to respond to it I think it's a very powerful thing to do And I think if you look at things like the physical web as anyone interacted with any of the physical web beacons today That's cool. Quite a few people like we had polymon kind of on there Physical web broadcast the URL your phone picks it up or any device that can actually pick up the kind of the beacon signature at that point It understands what the URL is being broadcast Present you with some metadata in the user interface, and then you can click on it and start to interact with that experience That's super lightweight like no one's ever going to build or install an application Which is just to let it interact with the TV just say say for a conference and those types of things like the lightweight kind of Like ephemeral nature of these experiences, especially through physical web are really powerful But the really interesting thing for me is like yes We can discover like a beacon which is kind of cool that points to a web experience But actually sometimes we want to take the the web experience like the like the URL that's been presented And it actually to a physical device right like whether I know they were talking about internet things before But like this is where you can start to see that kind of the tie-in with web Bluetooth and web Bluetooth again We talked about this last year, but it's at this point now again where it's an origin truck I think it's an origin trial. Is it still an origin trial? Yeah, it's still an origin trial man I thought we it's an origin trial, so you have to enable it and kind of Excuse me, you have to enable it and kind of if you're going to use it which is cool It's fine the API still might change at this point, but you can start to build really compelling experiences You can have a hard piece of hardware. This is the plague plague handle Vincent has been walking around Around the venue a couple times with with the actual play bulbs and we've had a code lab as well Where you can go and start to play with it, but the idea behind it is You know you don't need a native application to start to interact with that experience It literally links to a website which then connects through to the beacon and then you can start or not the beacon The the the Bluetooth device and you can start to interact with it with it, and then you can walk away You know you don't have to install this is a added to the home screen progress a web app Like once you've interacted with it, you don't have to install it again and use it I think that's incredibly powerful super lightweight experiences that we can do a lot with And it's kind of interesting right like I'm not going to go too much into the whole Bluetooth space But like because I if you're not going to build things with Bluetooth Probably don't have to understand it too much, but like you have this idea of like The the BLE beacon or the BLE device broadcast in a whole bunch of attributes those attributes Well, yeah broadcast a whole bunch of attributes as get through the get server You have this idea of services like your device can have multiple kind of like super capabilities Like it could be a battery service It could be in this case like the candle service at that point you connect to the service And then you can get different attributes off the back of it So a service might have multiple attributes like in this case the battery service You probably only want to ever read the battery level But you can kind of get that and start to read from the data And then you can also get prompted for changes to those data And it's actually a really simple or relatively simple API once you understand Like how to actually start interacting with the device And you know like what data you need to send it and how you should connect to it It's relatively simple and it gets even simpler when you start to think about the a single weight syntax as well But you're not having to chain promises together and to the next the next the next it's actually pretty simple But in this case the discovery phase is you just basically call navigator.dobluetooth.requestdevice Tell the type of service that you want to connect to and then you'll get prompted to say well We know that there's the device here. Do you want to access it once you have get access you can physically connect You get the access to the service you call you try and get access to the service in this case This is for a heart rate monitor. You say I want the heart rate the heart rate service And then you can say well, I've got the service I need to get regular data from it at that point So I'm going to get the heart rate measurement and in this case I want to be notified whenever the heart rate measurement changes And I think that's a very kind of relatively easy flow just start getting some lightweight interactions with the device at that point it gets a little bit more complex when you think about things like web USB and web USB is It's an interesting API and again This is a demo from Kenneth, but the idea is that any like a web page could connect to a USB device Right, so this is kind of interesting. So you send it some data through slow type of Press send and it appears on the device So you've connected to the device and you've sent some data to it But the interesting thing is like the first thing that people say is like I don't want a web page access in my USB devices and there's a very great Like medium document by Raleigh Grant who's the engineer on this project who is basically describing the security model of web USB and whole get into the whole point is like not every single site or no Not every single site will be able to get access to any USB device Specifically only whitelisted sites by the device So the device has to say this site can access my like can actually connect to the device And then only when the users actually opted in and granted it will the catcher connection be made So the idea is that you can get the USB based experiences You can plug it in and like the owner of the the owner of the piece of hardware will be able to say Yes, like I'm gonna build the web based user interface for this experience a lot of other random sites won't be able to do that I think that's a quite a powerful security model for the web at this point and again The API is very similar to the to the Bluetooth API rather than Bluetooth connect request device that you do the same thing But with USB you as the hardware vendor know your vendor ID and all that type of stuff So you can connect to it the user grants access you get the call back through and then it actually gets really complex Right. I remember a couple of years ago. We tried to make an Xbox connect thing for Chrome apps And it gets really really complex what you have to deal with the types of control methods and the data transfer If you're into USB or hardware, you'll probably understand this I don't particularly understand this because I'm not kind of built hardware interactions But you do get to choose like the control method and the data transport Mechanisms as well So you get a lot of control over the device at that point And then we also kind of start to think about the new types of experiences like those two experiences in theory You've been quite lightweight, right? You can have the device or a thing around you You can connect to it start experiencing with it leave and then you that's fine, right? You've not installed a new device the web VR experience I think is an interesting space to be in because it is quite I'm gonna say immature isn't the wrong word, but it's quite nascent at the moment things are changing Everyone's trying to explore what to do in the space of web VR like who's got a place station VR One person I think it's pretty cool. I bought one. They're pretty cool But like we don't know how to use these experiences properly We don't know how to build them properly as well So it's a very kind of emerging market But the Chrome team in particular have been working on kind of making sure that you know You can start to like build web-based experiences that kind of are powered by like the VR subsystem at least anyway And it's in Chrome 56 at the moment again. It's behind an origin trial And I think the thing about web VR for me is not that it's gonna like like take over the world And everyone must kind of use it but it's it is uniquely positioned to be able to provide kind of compelling experiences that are very web Like web like you don't have to install a whole bunch of native applications just to experience some web based VR content and The interesting thing and if you've yet if you've used the Chrome Dev Summit site is that we believe at this point Like progressive enhancement is key to this right that you can build experiences that live on the web They're kind of you know for people to interact with Irrespective of whether they have like the piece of hardware that they need to experience a VR system So that's pretty cool on that side of things the way that we implemented it And we're trying to think about how you implement some of these early VR experiences Like we're not saying right now that you go out and build a whole bunch of games on these the triple-a class games to actually You know take advantage of web VR, but it's a very much more incremental approach So in the Chrome Dev Summit site we had the plate plain old image You got the kind of the picture of this venue then you had like this 2d immersive view So if you had like a device that had web GL you could click on it And then you could kind of like drag your mouse around and scroll around the page Then you had this kind of AR view if you had an iPad or an iPhone or any device with a gyroscope on you'd be able to kind of Like basically move your device around. It's not complete AR. It's like foe AR at this point But then if you have a headset and if you I think the headset got launched today You have the headset you can pop your phone in and then experience the the web VR experience first class So this is the experience that we've got on the Chrome Dev Summit site Now this is like we know that this device doesn't have web VR But we can provide this immersive experience because we have web GL And I think that's pretty cool because the This is the model right the plain image view the immersive 2d view So this is where I'm kind of I've got my phone and I can move it around like not every experience is going to be like this But it's quite powerful that you can do that and then We've got this idea of the full immersion right and this is rendered using web GL using the web VR view Are that Boris must on the Chrome team wrote or is in the Google team at least now? Is that you can basically plop your phone in it will know that you've connected your phone to the To the hardware at least and then you move around and it automatically moves into this model. I think that's actually It's actually pretty cool right because you get to this point of every single user can experience your site You're not building an application for this experience You're not having to get people to go install it if they have the VR kind of capabilities They can start to take advantage of it pretty quickly and you can do this for videos You can do this for images like a really nice way of doing it now The thing I would say is like you can get to this point where you know We want to ultimately build these triple class or triple a class types of games I personally don't know whether we're there on the web just yet But I think we're getting into a good place and the final thing I would say is that I I Want to get to this point where we have a common understanding and it could be slice It could be any other kind of model going We have a common understanding for how we want to deploy these experience on the web The web has properties that no other platform has specifically around ephemeral ephemerality and the ability to link ability and index ability You can give a link to anyone. You can start to use that experience and go anywhere The last thing I would say is if you are interested in obviously the progressive web app space and the future developments from Chrome and These are new APIs We do have our developer portal and developers.google.com Slash web if you go to slash web slash updates You will get all the new APIs as they come through Chrome But our guidance and our focus is the new and shiny stuff is great right it gets people excited and it gets you inspired to actually build the next generation things Developers.google.com slash web is our place to build like gives you practical guidance for all the technologies that are available today so much more focused on responsive design performance and Service worker and progressive web applications and obviously developer feedback as well. So with that I've know I've run completely over time But I would like to thank everyone this rehearsal right by the way Did they see keep going are you trying to run straight into Chrome Dev Summit 2017? Yes Ladies and gentlemen Paul Kimlin