[Taming the Browsers of Tomorrow] [Flurin Egger]

[Sideview 2013] [Sponsored by Treehouse]

[Flurin Egger] [Digitpaint]

Thank you.

Taming the Browsers of Tomorrow.

My name is Flurin.

There's a picture of me back when I was really cool.

Nowadays I just work a lot.

I work at a small company in the Netherlands called Digitpaint,

and we do mostly front-end work,

and my job is to actually get people together to work on front end,

and I'm also the guy that gets to experiment with new stuff.

So I'm going to talk about things in browsers and APIs,

and big things are happening to browsers,

especially this year.

There's really a lot going on,

and the browsers, they are getting smarter

and more aware of their surroundings,

and actually 7 years ago you had no input,

like video, audio, or touch input wasn't really there.

So this talk will be about APIs,

but I'm not going to talk about the big stuff.

As I said, 2013 was really great,

but I'm not going to talk about the Shadow DOM today,

because that has been covered a lot.

There are a lot of blog posts around that.

There are a lot of talks this year about Shadow DOM.

I'm also not going to talk about WebGL.

It's really awesome, but not today.

I'm also not going to talk about WebRTC.

Also, these technologies are awesome, and they're cool,

but I'm going to talk about 6 pieces of small magic.

I think a lot of this is underappreciated.

As I said, you talk a lot about the big stuff,

but this is the small stuff I'm going to talk about.

And the first thing I'm going to cover is not an API.

It's promises, or it used to be called futures,

and I'm going to talk about native promises.

You've probably heard about them.

If you have not, this is what the promise is.

A promise represents the eventual result of an asynchronous operation just like a marriage.

But what does this mean? What does this solve?

Because if you say we have events for this—

but the thing is there are 2 key words in the sentence, eventual and asynchronous.

I'm going to give a short demonstration with this scenario.

Let's say we have to fetch a list of news items,

and we want to smartly cache the first item's details.

We actually want to do a second request to get the first item,

so if the user clicks on the first item, it instantly gets the details of that first item.

If we have to do this traditionally—is this visible?

I can zoom in, I think.

It doesn't work, but I have abstracted the Ajax call to get the Ajax function.

I get a list, and when it gets back

I have to call back, and we check the results there,

and I'm going to do this, and then I have a handle failure.

It's really just quite abstract.

So if we continue, we want to get the details as well.

We do the getAjax, and we get the list,

and we see if the list is there, and we do the second request,

and if the second request returned,

in the callback we will call the cache result,

so if the user clicks it it will be right there.

Yeah, we're in so-called callback hell now,

and this is just a simple scenario.

If we want to go deeper,

this gets worse and worse and worse.

If we want to solve this with promises,

we are going to do it like this.

We get the list, and then we call the getAjax call.

It now returns the promise, and we can call then,

and then takes 2 parameters.

The first is the success callback,

and the second one is the failure callback.

The cool thing is that I do not have to call them immediately.

I can say, "Okay, I'm going to fire off this Ajax call,

and then I'm going to do some other stuff," and finally, when I'm ready for it,

I call the then, and it will return immediately, of course, still asynchronously.

Or if it still has to wait for the request to finish, it will return later.

If we continue on our example, I get the list again.

Then if we have a success,

we are going to get the detail page,

and then we are going to chain them.

The second result is down here.

When the first is done, the second then will trigger,

and so we can actually cache the result.

This is a much more readable code.

This is another example that is really cool.

You can also do promise.all.

I have a little example here that it doesn't really do much,

because I have made a function that returns a promise right here,

and it finds out for X milliseconds,

and when it's done it calls the resolve function.

This is really basic, because I don't handle the reject case,

and so what I can do now is I can ask promise.all sleep 5 seconds

and another one for 2 seconds.

And if we're all done, this one gets called

with an array of return values of these.

And the failed ones we'll get back here.

If you want to do this with callbacks,

you'd have to write codes that in every callback it would check via a global variable

if the other callback is already done,

and if I'm the last, I will now execute this code.

This is really hard to do without promises.

I've been talking about promises, and they have been around quite some time,

so you have Q as an implementation.

RSVP is another one.

JQuery.deferred has been around quite long,

but it's not really adhering to the spec,

but it's a way to handle promises.

These are our native promises,

and I found this tweet, and the eventual part is the amazing thing here,

because if the browser will use promises,

you can ask for the screen with WebRTC, for instance.

You have to ask permission, and then you can fire that off

and wait for it to return.

We currently use promises in Firefox,

in Safari, and in Chrome 32 and up.

I think Chrome 32 is the current Canary,

and it's actually going to come to IE,

because IE has publicly decided they will want to support this.

Continuing on to another little API.

This one is actually an API.

It's called ambient light events,

and this is its definition.

When a device's light sensor detects a change in the light level,

it notifies the browser by firing the DeviceLightEvent.

Once the event is captured, the event object gives access to the light intensity expressed in lux.

Lux is a way to measure light.

I'm going to have to switch browsers now.

This does not work in Canary.

So what I'm going to do, I'm going to start the demo now.

I'm plotting out the values of the light sensor,

and the thing is, I don't have a flat light,

but I'm holding my phone on there, and once the sensor detects light that is lighter,

you saw it flashing white, so what you can do is change the coloring

of the contrast of your page by looking at how bright the user is,

how bright the location is where the user is.

Sorry.

But how would this look in code?

It's really simple, because we add an event to the window,

and we listen for the device light event.

And when the value changes, we can plot out the event of the value,

and the example you just saw of changing the background color is like this.

When the lux value goes below 50,

it will add a class darklight to the HTML element,

and if it gets above that, we will add brightlight and remove the darklight.

We can actually switch based on the light intensity.

This is currently working on multi Firefox,

and it doesn't currently work on Windows,

but I read they're working on that, but it works on Firefox OS and Firefox for Android.

And if you research it, there is a pretty cool movie on what other things you could do with it.

That was DeviceLight API.

Another small one is Vibration API.

This background image, I know you probably think about different images,

and I thought to keep it family friendly.

This is really simple.

I can't really demonstrate this because most laptops

don't have vibrating devices in them, but it's really easy.

You just call navigator.vibrate

and the number of milliseconds you want it to vibrate, and there you go.

You can also make patterns,

navigator.vibration, and you pass it an array,

and then every second element in the array is paused,

so in this example you would vibrate for 100 milliseconds

and then pause for 50 and continue for about 100.

There are, of course, some security measures built in,

like in the specification you cannot activate the vibration

when you're not the visible page.

Most of the browsers have implemented limits

on the time you can actually use, you can vibrate on end.

You can currently use this on Firefox and Android

and Chrome 32 on Android, and it's going to be in Chrome 32.

You cannot actually install this at the moment, I think,

from a run-of-the-mill marketplace, but it's going to be in there.

The big gap here is, of course, iOS and Safari.

It's a bit sad, but it's how it is.

Web speech API.

This is also pretty cool.

I'm going to have to switch browsers again

because this one actually only works in Safari.

Let's see if I can turn up the volume a bit.

[computer] Hello Sideview Attendees.

Great, this really makes me feel like in those '95 days

when you could make these—digital basic script these talking avatars.

But it's really cool that we have these.

It's also pretty simple.

You set up an utterance.

The class name is a bit long, but what can you do about that?

SpeechSynthesisUtterance, Hello SideView Attendees,

and then we set up how we want this to be set.

The volume is set to 1.

The rate of the speech, how fast it's going, and pitch is how high,

and the language you want to have it pronounce it.

And in the end, you just say window.speechSynthesis.speak,

the utterance we just created.

There in the specification you can also specify

what voice you want to use, if you had a voice URI,

but that does not seem to work anywhere at the moment.

This is just one part of the web speech API,

because this is output, or synthesis.

The second part is recognition

and this is also where you—like you have seen for TVs.

You can actually do this in the browser.

Currently I think it's only in Chrome.

This needs an Internet connection, so I cannot really demonstrate this right now,

but it's a bit more complicated.

We initialize a new webkitSpeechRecognition object.

You see its prefixed with webkit there.

We tell it we want to have continuous recognition,

so if we stop speaking it doesn't stop,

so we can keep on talking, and it will keep on recognizing what we are saying.

The language we're talking.

We want to have interim results.

This means that even if the result is not yet final

because the recognition process takes a while to get to a final result,

like you are saying a word, so it makes an assumption of what you're going to say,

and in the end, we'll get a final result for that word or sentence.

And then we start it, so we could start talking,

and we have there the end result event handler,

and in there we can do all kinds of things

from the input we get.

And when we are done recognizing, we just stop.

This currently works in Chrome 25 and up.

It's only the input part,

and you need an active Internet connection,

because the recognition is actually happening on the Google service.

The output part, as you just saw before,

works on Safari 6.1 and up on desktop and on iOS7,

and this API is coming to Firefox,

and the speech synthesis part is also in Chrome 33

that's going to be the next Canary.

I just saw a tweet last night that this will be in Chrome 33,

so it's pretty neat.

I'm going pretty fast.

I have 2 more left, but first of all, I lied.

I said I wouldn't be talking about WebRTC.

I just saw this demo a couple of weeks ago,

and it was like yeah, I wanted do this really a long time,

because it's so annoying that I have to use Skype to share my screen

with my remote co-worker, so there was this demo in Chrome

that you can share your screen.

There are some limitations, though.

You can only use it on an HTTPS server.

This is probably a good thing, because you wouldn't want your screen to be shared

on a regular HTTP connection where everyone may be listening in.

It pops up this, "Do you want to share your screen?"

Yes, I want to.

I'm displaying here—I can go like this.

It's pretty neat.

I'm going to stop sharing now.

And it also works in the basic navigator.getUserMedia.

But apart from that, we are not asking for a video.

We're actually telling the browser what video source we want to use,

and this is the chromeMediaSource stream,

and then we got the stream here,

and we output it to a video element,

and we append that to the body.

This just works in Chrome 26 and up.

But it's really cool, and I hope other browsers will implement this.

This is the last thing I'm going to talk about today, the ServiceWorker, and I'm really excited about it.

By the way, this is not a slide I created.

This is a slide Bruce Lawson from Opera uses,

and he showed this at the Fronteers Conference in the Netherlands,

but when I was looking at this slide I was like, "Whoa,

if I ever talk about ServiceWorkers, I want this slide,"

so I asked him if I could use it, and he said yeah.

So what are ServiceWorkers?

I'm really excited about those.

ServiceWorkers allow us to persistently cache

resources and handle requests to these resources

even when the network isn't available.

This means we can make offline apps.

You'd say, "Yeah, okay, but we've got appcache

or other caching mechanisms for the app."

But the thing is, with appcache it's decorative.

There are a lot of drawbacks.

We have to think up front what we want to cache,

and then once it's cached,

we are having a lot of trouble getting it out of the cache.

And ServiceWorkers give us a way to—if we fire code, to control this mechanism.

They consist of 2 parts,

a shared worker/controller that lives across page loads

and a programmable HTTP cache.

A little example of how this would work.

On the first page load you're going to register the ServiceWorker.

We're saying we want to handle everything on /*

with this controller.

And as you see here, they are using promises.

Once it has been registered and initialized,

it will handle all subsequent requests on this domain.

That's why it says here if you want to use ServiceWorker immediately,

you might call window.location.reload

because that would mean that the current HTML page

also would be handled by this ServiceWorker.

This is what the worker looks like.

It's pretty much like a ServiceWorker.

I'm going to run through this code really quick.

We have here base URL and inventory URL.

We have the install event listener,

so on the previous slide we called the register function,

and everything worked well.

In the worker the install event gets called,

and in the install event we are telling the whole mechanism

yeah, we are handling fetch here.

This is something—actually, I talked to Alex Russell last night from Google.

He is working on this, on the spec,

and this is something that may look a bit weird right now,

but there will be more events for streams,

for instance, in the future.

And then we listen to this fetch event and see what comes in.

This is really just a basic example

to see when we have a request for services inventory data JSON.

We are going to respond with an empty JSON object right here,

so this is pretty useless, but you can imagine what you could do with it,

like stuff like it's really hard to do right now when you have also a news app,

and if you open the app, you want to have an immediate result on there,

so you show them the cached result you already have,

and in the meantime, in the worker you're going to fire off a request

to get more data or newer data.

And if this does not work—

and if it comes in, you can update it.

And if it doesn't work, you maybe get a generic error,

and you say at the bottom of the page that's why we cannot load any new data

because you may or may not be online, or there may be something wrong with your connection.

The thing is, this is just the specification right now,

and it's in flux, but I'm really excited about this one.

This is going to happen. It's really cool.

When I started researching this for this presentation,

I was looking into if it worked in Chrome, and there is some basic scaffolding code in there,

because the primitives are there,

but it doesn't really do anything.

But there is a lot of stuff going on around these ServiceWorkers.

Previously they were called navigation controllers,

and what you see here is a Google+ post by Paul Irish,

and he links to the intent to implement for Mozilla.

They're also into this, and Chrome is obviously working on it,

so this is going to happen I hope next year.

These were my 6 little things.

There is much more I could not cover in this talk.

The Midi API.

It basically means if you're into music

you could dig garage bands.

You could do all this in your browser,

have your keyboard input directly to your—

battery Status API, it's been around quite a while.

It's also pretty simple,

a little API, but you can do fun stuff with it

like when your battery is dying

you can quickly save some stuff.

The Web Crypto API and the URL object.

This has been standardized pretty recently.

These were some of the things,

and I think we as web developers should look into this.

Most of the time we're busy making money

or making money for our clients, and we have to stick to stuff that works,

but I think we need to do this.

We need to research this. We need to do experiments with these APIs.

Not only to get them improved,

because just last night I was talking about the ServiceWorker with Alex Russell,

and he was asking me what I thought about it,

because they want to have the input to improve this

and make it actually usable, and if we use and experiment with this,

browser vendors have more incentive to implement them

so we will never get into an IE6 situation anymore.

This was my talk.

I'm doing pretty well on schedule, I think.

Thank you very much.