[Taming the Browsers of Tomorrow] [Flurin Egger] 0:00 [Sideview 2013] [Sponsored by Treehouse] 0:02 [Flurin Egger] [Digitpaint] 0:05 Thank you. 0:08 Taming the Browsers of Tomorrow. 0:10 My name is Flurin. 0:13 There's a picture of me back when I was really cool. 0:15 Nowadays I just work a lot. 0:19 I work at a small company in the Netherlands called Digitpaint, 0:23 and we do mostly front-end work, 0:26 and my job is to actually get people together to work on front end, 0:28 and I'm also the guy that gets to experiment with new stuff. 0:37 So I'm going to talk about things in browsers and APIs, 0:42 and big things are happening to browsers, 0:50 especially this year. 0:54 There's really a lot going on, 0:56 and the browsers, they are getting smarter 0:59 and more aware of their surroundings, 1:04 and actually 7 years ago you had no input, 1:08 like video, audio, or touch input wasn't really there. 1:15 So this talk will be about APIs, 1:25 but I'm not going to talk about the big stuff. 1:30 As I said, 2013 was really great, 1:33 but I'm not going to talk about the Shadow DOM today, 1:37 because that has been covered a lot. 1:40 There are a lot of blog posts around that. 1:42 There are a lot of talks this year about Shadow DOM. 1:45 I'm also not going to talk about WebGL. 1:48 It's really awesome, but not today. 1:51 I'm also not going to talk about WebRTC. 1:54 Also, these technologies are awesome, and they're cool, 1:56 but I'm going to talk about 6 pieces of small magic. 2:00 I think a lot of this is underappreciated. 2:07 As I said, you talk a lot about the big stuff, 2:12 but this is the small stuff I'm going to talk about. 2:20 And the first thing I'm going to cover is not an API. 2:22 It's promises, or it used to be called futures, 2:26 and I'm going to talk about native promises. 2:31 You've probably heard about them. 2:35 If you have not, this is what the promise is. 2:43 A promise represents the eventual result of an asynchronous operation just like a marriage. 2:47 But what does this mean? What does this solve? 2:57 Because if you say we have events for this— 3:00 but the thing is there are 2 key words in the sentence, eventual and asynchronous. 3:04 I'm going to give a short demonstration with this scenario. 3:08 Let's say we have to fetch a list of news items, 3:14 and we want to smartly cache the first item's details. 3:19 We actually want to do a second request to get the first item, 3:24 so if the user clicks on the first item, it instantly gets the details of that first item. 3:29 If we have to do this traditionally—is this visible? 3:34 I can zoom in, I think. 3:41 It doesn't work, but I have abstracted the Ajax call to get the Ajax function. 3:48 I get a list, and when it gets back 3:55 I have to call back, and we check the results there, 3:59 and I'm going to do this, and then I have a handle failure. 4:03 It's really just quite abstract. 4:06 So if we continue, we want to get the details as well. 4:10 We do the getAjax, and we get the list, 4:15 and we see if the list is there, and we do the second request, 4:18 and if the second request returned, 4:21 in the callback we will call the cache result, 4:24 so if the user clicks it it will be right there. 4:29 Yeah, we're in so-called callback hell now, 4:33 and this is just a simple scenario. 4:39 If we want to go deeper, 4:42 this gets worse and worse and worse. 4:44 If we want to solve this with promises, 4:47 we are going to do it like this. 4:49 We get the list, and then we call the getAjax call. 4:53 It now returns the promise, and we can call then, 4:57 and then takes 2 parameters. 5:01 The first is the success callback, 5:03 and the second one is the failure callback. 5:07 The cool thing is that I do not have to call them immediately. 5:10 I can say, "Okay, I'm going to fire off this Ajax call, 5:15 and then I'm going to do some other stuff," and finally, when I'm ready for it, 5:19 I call the then, and it will return immediately, of course, still asynchronously. 5:24 Or if it still has to wait for the request to finish, it will return later. 5:30 If we continue on our example, I get the list again. 5:38 Then if we have a success, 5:43 we are going to get the detail page, 5:46 and then we are going to chain them. 5:48 The second result is down here. 5:52 When the first is done, the second then will trigger, 5:58 and so we can actually cache the result. 6:02 This is a much more readable code. 6:04 This is another example that is really cool. 6:08 You can also do promise.all. 6:10 I have a little example here that it doesn't really do much, 6:15 because I have made a function that returns a promise right here, 6:20 and it finds out for X milliseconds, 6:24 and when it's done it calls the resolve function. 6:30 This is really basic, because I don't handle the reject case, 6:32 and so what I can do now is I can ask promise.all sleep 5 seconds 6:36 and another one for 2 seconds. 6:43 And if we're all done, this one gets called 6:46 with an array of return values of these. 6:50 And the failed ones we'll get back here. 6:54 If you want to do this with callbacks, 6:58 you'd have to write codes that in every callback it would check via a global variable 7:00 if the other callback is already done, 7:06 and if I'm the last, I will now execute this code. 7:08 This is really hard to do without promises. 7:12 I've been talking about promises, and they have been around quite some time, 7:18 so you have Q as an implementation. 7:22 RSVP is another one. 7:26 JQuery.deferred has been around quite long, 7:28 but it's not really adhering to the spec, 7:32 but it's a way to handle promises. 7:35 These are our native promises, 7:43 and I found this tweet, and the eventual part is the amazing thing here, 7:45 because if the browser will use promises, 7:53 you can ask for the screen with WebRTC, for instance. 7:57 You have to ask permission, and then you can fire that off 8:03 and wait for it to return. 8:06 We currently use promises in Firefox, 8:11 in Safari, and in Chrome 32 and up. 8:14 I think Chrome 32 is the current Canary, 8:18 and it's actually going to come to IE, 8:21 because IE has publicly decided they will want to support this. 8:25 Continuing on to another little API. 8:31 This one is actually an API. 8:36 It's called ambient light events, 8:38 and this is its definition. 8:41 When a device's light sensor detects a change in the light level, 8:44 it notifies the browser by firing the DeviceLightEvent. 8:48 Once the event is captured, the event object gives access to the light intensity expressed in lux. 8:51 Lux is a way to measure light. 8:57 I'm going to have to switch browsers now. 9:03 This does not work in Canary. 9:05 So what I'm going to do, I'm going to start the demo now. 9:11 I'm plotting out the values of the light sensor, 9:16 and the thing is, I don't have a flat light, 9:21 but I'm holding my phone on there, and once the sensor detects light that is lighter, 9:28 you saw it flashing white, so what you can do is change the coloring 9:39 of the contrast of your page by looking at how bright the user is, 9:45 how bright the location is where the user is. 9:55 Sorry. 9:59 But how would this look in code? 10:04 It's really simple, because we add an event to the window, 10:07 and we listen for the device light event. 10:12 And when the value changes, we can plot out the event of the value, 10:15 and the example you just saw of changing the background color is like this. 10:21 When the lux value goes below 50, 10:28 it will add a class darklight to the HTML element, 10:31 and if it gets above that, we will add brightlight and remove the darklight. 10:38 We can actually switch based on the light intensity. 10:43 This is currently working on multi Firefox, 10:50 and it doesn't currently work on Windows, 10:54 but I read they're working on that, but it works on Firefox OS and Firefox for Android. 10:57 And if you research it, there is a pretty cool movie on what other things you could do with it. 11:03 That was DeviceLight API. 11:12 Another small one is Vibration API. 11:14 This background image, I know you probably think about different images, 11:17 and I thought to keep it family friendly. 11:22 This is really simple. 11:26 I can't really demonstrate this because most laptops 11:28 don't have vibrating devices in them, but it's really easy. 11:33 You just call navigator.vibrate 11:37 and the number of milliseconds you want it to vibrate, and there you go. 11:39 You can also make patterns, 11:43 navigator.vibration, and you pass it an array, 11:45 and then every second element in the array is paused, 11:48 so in this example you would vibrate for 100 milliseconds 11:54 and then pause for 50 and continue for about 100. 11:57 There are, of course, some security measures built in, 12:02 like in the specification you cannot activate the vibration 12:09 when you're not the visible page. 12:14 Most of the browsers have implemented limits 12:16 on the time you can actually use, you can vibrate on end. 12:20 You can currently use this on Firefox and Android 12:29 and Chrome 32 on Android, and it's going to be in Chrome 32. 12:31 You cannot actually install this at the moment, I think, 12:38 from a run-of-the-mill marketplace, but it's going to be in there. 12:41 The big gap here is, of course, iOS and Safari. 12:47 It's a bit sad, but it's how it is. 12:51 Web speech API. 12:57 This is also pretty cool. 12:59 I'm going to have to switch browsers again 13:03 because this one actually only works in Safari. 13:06 Let's see if I can turn up the volume a bit. 13:09 [computer] Hello Sideview Attendees. 13:13 Great, this really makes me feel like in those '95 days 13:17 when you could make these—digital basic script these talking avatars. 13:22 But it's really cool that we have these. 13:30 It's also pretty simple. 13:36 You set up an utterance. 13:38 The class name is a bit long, but what can you do about that? 13:42 SpeechSynthesisUtterance, Hello SideView Attendees, 13:46 and then we set up how we want this to be set. 13:49 The volume is set to 1. 13:53 The rate of the speech, how fast it's going, and pitch is how high, 13:56 and the language you want to have it pronounce it. 14:02 And in the end, you just say window.speechSynthesis.speak, 14:07 the utterance we just created. 14:11 There in the specification you can also specify 14:15 what voice you want to use, if you had a voice URI, 14:20 but that does not seem to work anywhere at the moment. 14:25 This is just one part of the web speech API, 14:30 because this is output, or synthesis. 14:35 The second part is recognition 14:39 and this is also where you—like you have seen for TVs. 14:42 You can actually do this in the browser. 14:49 Currently I think it's only in Chrome. 14:51 This needs an Internet connection, so I cannot really demonstrate this right now, 14:53 but it's a bit more complicated. 14:59 We initialize a new webkitSpeechRecognition object. 15:04 You see its prefixed with webkit there. 15:09 We tell it we want to have continuous recognition, 15:12 so if we stop speaking it doesn't stop, 15:15 so we can keep on talking, and it will keep on recognizing what we are saying. 15:18 The language we're talking. 15:24 We want to have interim results. 15:26 This means that even if the result is not yet final 15:28 because the recognition process takes a while to get to a final result, 15:32 like you are saying a word, so it makes an assumption of what you're going to say, 15:39 and in the end, we'll get a final result for that word or sentence. 15:46 And then we start it, so we could start talking, 15:51 and we have there the end result event handler, 15:53 and in there we can do all kinds of things 15:57 from the input we get. 16:00 And when we are done recognizing, we just stop. 16:03 This currently works in Chrome 25 and up. 16:12 It's only the input part, 16:15 and you need an active Internet connection, 16:17 because the recognition is actually happening on the Google service. 16:19 The output part, as you just saw before, 16:25 works on Safari 6.1 and up on desktop and on iOS7, 16:29 and this API is coming to Firefox, 16:36 and the speech synthesis part is also in Chrome 33 16:39 that's going to be the next Canary. 16:44 I just saw a tweet last night that this will be in Chrome 33, 16:46 so it's pretty neat. 16:49 I'm going pretty fast. 16:53 I have 2 more left, but first of all, I lied. 17:00 I said I wouldn't be talking about WebRTC. 17:03 I just saw this demo a couple of weeks ago, 17:08 and it was like yeah, I wanted do this really a long time, 17:11 because it's so annoying that I have to use Skype to share my screen 17:14 with my remote co-worker, so there was this demo in Chrome 17:18 that you can share your screen. 17:24 There are some limitations, though. 17:26 You can only use it on an HTTPS server. 17:28 This is probably a good thing, because you wouldn't want your screen to be shared 17:32 on a regular HTTP connection where everyone may be listening in. 17:36 It pops up this, "Do you want to share your screen?" 17:45 Yes, I want to. 17:47 I'm displaying here—I can go like this. 17:49 It's pretty neat. 17:58 I'm going to stop sharing now. 18:01 And it also works in the basic navigator.getUserMedia. 18:03 But apart from that, we are not asking for a video. 18:10 We're actually telling the browser what video source we want to use, 18:14 and this is the chromeMediaSource stream, 18:19 and then we got the stream here, 18:21 and we output it to a video element, 18:25 and we append that to the body. 18:27 This just works in Chrome 26 and up. 18:30 But it's really cool, and I hope other browsers will implement this. 18:37 This is the last thing I'm going to talk about today, the ServiceWorker, and I'm really excited about it. 18:45 By the way, this is not a slide I created. 18:51 This is a slide Bruce Lawson from Opera uses, 18:53 and he showed this at the Fronteers Conference in the Netherlands, 18:57 but when I was looking at this slide I was like, "Whoa, 19:00 if I ever talk about ServiceWorkers, I want this slide," 19:05 so I asked him if I could use it, and he said yeah. 19:09 So what are ServiceWorkers? 19:12 I'm really excited about those. 19:15 ServiceWorkers allow us to persistently cache 19:17 resources and handle requests to these resources 19:20 even when the network isn't available. 19:23 This means we can make offline apps. 19:27 You'd say, "Yeah, okay, but we've got appcache 19:30 or other caching mechanisms for the app." 19:33 But the thing is, with appcache it's decorative. 19:36 There are a lot of drawbacks. 19:39 We have to think up front what we want to cache, 19:42 and then once it's cached, 19:47 we are having a lot of trouble getting it out of the cache. 19:49 And ServiceWorkers give us a way to—if we fire code, to control this mechanism. 19:53 They consist of 2 parts, 20:02 a shared worker/controller that lives across page loads 20:04 and a programmable HTTP cache. 20:09 A little example of how this would work. 20:17 On the first page load you're going to register the ServiceWorker. 20:20 We're saying we want to handle everything on /* 20:25 with this controller. 20:32 And as you see here, they are using promises. 20:36 Once it has been registered and initialized, 20:39 it will handle all subsequent requests on this domain. 20:43 That's why it says here if you want to use ServiceWorker immediately, 20:50 you might call window.location.reload 20:54 because that would mean that the current HTML page 20:56 also would be handled by this ServiceWorker. 20:59 This is what the worker looks like. 21:05 It's pretty much like a ServiceWorker. 21:08 I'm going to run through this code really quick. 21:10 We have here base URL and inventory URL. 21:16 We have the install event listener, 21:20 so on the previous slide we called the register function, 21:24 and everything worked well. 21:31 In the worker the install event gets called, 21:33 and in the install event we are telling the whole mechanism 21:36 yeah, we are handling fetch here. 21:42 This is something—actually, I talked to Alex Russell last night from Google. 21:45 He is working on this, on the spec, 21:51 and this is something that may look a bit weird right now, 21:53 but there will be more events for streams, 21:59 for instance, in the future. 22:03 And then we listen to this fetch event and see what comes in. 22:07 This is really just a basic example 22:11 to see when we have a request for services inventory data JSON. 22:14 We are going to respond with an empty JSON object right here, 22:23 so this is pretty useless, but you can imagine what you could do with it, 22:29 like stuff like it's really hard to do right now when you have also a news app, 22:34 and if you open the app, you want to have an immediate result on there, 22:40 so you show them the cached result you already have, 22:48 and in the meantime, in the worker you're going to fire off a request 22:53 to get more data or newer data. 22:58 And if this does not work— 23:00 and if it comes in, you can update it. 23:03 And if it doesn't work, you maybe get a generic error, 23:05 and you say at the bottom of the page that's why we cannot load any new data 23:08 because you may or may not be online, or there may be something wrong with your connection. 23:11 The thing is, this is just the specification right now, 23:19 and it's in flux, but I'm really excited about this one. 23:26 This is going to happen. It's really cool. 23:30 When I started researching this for this presentation, 23:33 I was looking into if it worked in Chrome, and there is some basic scaffolding code in there, 23:36 because the primitives are there, 23:45 but it doesn't really do anything. 23:48 But there is a lot of stuff going on around these ServiceWorkers. 23:53 Previously they were called navigation controllers, 24:01 and what you see here is a Google+ post by Paul Irish, 24:04 and he links to the intent to implement for Mozilla. 24:09 They're also into this, and Chrome is obviously working on it, 24:15 so this is going to happen I hope next year. 24:19 These were my 6 little things. 24:25 There is much more I could not cover in this talk. 24:27 The Midi API. 24:31 It basically means if you're into music 24:33 you could dig garage bands. 24:37 You could do all this in your browser, 24:39 have your keyboard input directly to your— 24:41 battery Status API, it's been around quite a while. 24:47 It's also pretty simple, 24:49 a little API, but you can do fun stuff with it 24:51 like when your battery is dying 24:55 you can quickly save some stuff. 24:59 The Web Crypto API and the URL object. 25:01 This has been standardized pretty recently. 25:05 These were some of the things, 25:10 and I think we as web developers should look into this. 25:14 Most of the time we're busy making money 25:17 or making money for our clients, and we have to stick to stuff that works, 25:23 but I think we need to do this. 25:30 We need to research this. We need to do experiments with these APIs. 25:33 Not only to get them improved, 25:37 because just last night I was talking about the ServiceWorker with Alex Russell, 25:40 and he was asking me what I thought about it, 25:45 because they want to have the input to improve this 25:49 and make it actually usable, and if we use and experiment with this, 25:52 browser vendors have more incentive to implement them 25:58 so we will never get into an IE6 situation anymore. 26:01 This was my talk. 26:06 I'm doing pretty well on schedule, I think. 26:10 Thank you very much. 26:13