Thank you all a theme of this conference has been the future of JavaScript but I want to take a step back and look at the future of the browser as a whole but first let me introduce myself I am Lynn Clark and I make code cartoons and I also work at Mozilla where I’m in the emerging technologies group.

So that’s things like the rust programming language and web assembly which is a fast way to run code that’s not javascript.

Also work on servo which is.

A new web engine and I’ll be talking.

About all of these things today because they’re all a part of the future of the browser so why talk about the future of the browser because browsers are facing a challenge.

And whether or not browsers meet this challenge could change the web as we know it so what is this challenge the browser needs to get faster as Rachel talked about this morning content on the web has changed since the early days in the early days of the web speed really didn’t matter.

That much we were just looking.

So as soon as you downloaded that document it was rendered to the screen the browser was.

Pretty much done I may have a little bit more work to do a few scrolled.

Or something like that but there was nothing too complicated then people started pushing the boundaries they started thinking what can we do with this web besides just serving static documents pages started getting interactive and started having animations.

Like do you remember when everybody went wild for dropdowns and you had these animated jQuery things going up and down once those were on the page the web page wasn’t just being painted once in the browser it was being painted multiple times for that motion to look smooth you had to.

Be painting at a certain rate you had to be.

Painting 60 times per second so this meant that you only had 16 milliseconds to actually figure out what had changed the browser only has 16 milliseconds.

To figure out what changed between the last version of the page and the next version browsers made all.

Sorts of changes to come up to speed to accommodate these new applications and get up to 60 frames per.

Second but as is the way with the web content authors started pushing things further they started not just making their web applications more.

Interactive but bringing whole new classes of applications to the web so things like PC games and companies started talking about bringing their applications so web things like Photoshop these new classes of applications are pushing.

The web even further they’re taxing the web and they’re making it clear that things like JavaScript needs to get.

Faster but it’s not just content authors that are pushing the boundaries of the web is also the hardware vendors for example the new iPad is going from 60 frames per second to 120 frames per second so that means that you have half as much time to do just as much work and there are new kinds of content coming to the web that are pushing this further for example with a VR you have two different displays one for each eye and each of these has to be going at at least.

90 frames per second to avoid motion sickness and each of these displays could be up to 4k resolution which is a lot more pixels that you have to display so let’s think about what this change means if we’re running a web site on a MacBook Pro 13 inch we have 16 milliseconds.

To fill in about 4 million pixels on an iPad you have 8 milliseconds half as much time to fill in about 3 million pixels with a VR experience we’re looking at 11 milliseconds to fill in 16 point five million pixels since that that’s not even including.

Any additional JavaScript heavier application javascript needs that these applications have that is a huge leap that browsers need to make what happens if the browser’s don’t keep up well as more and more people buy these new devices.

And as more and more content moves to these heavier applications if browsers don’t keep.

Up it mean that people don’t see the web as the default place to put their content and that could mean that the web as we know it withers which.

Is a pretty scary thought but to be honest I’m not too worried I’m confident that browsers can make this leap the reason that.

I’m confident about this is because at Mozilla we’ve been planning for this for the past 10 years we’ve been looking at the direction that computer hardware is going we’ve been figuring out the new way that we need to program in order to keep up with these changes the answer is parallelism the future of the browser is parallel we’ve only just started taking advantage of this in Firefox but we’re already seeing some really big wins.

From it and every indication is that this new way of programming.

Is going to get us where we need to go so in this talk I want to explain exactly what it is that browsers need to change.

Keep up with these changes but before we do that let’s talk a little bit about how the browser works must start with a rendering engine which is the most.

Important part of the browser it takes your HTML and CSS and turns it into the pixels that you see on the screen so it does this in five steps but I can make this simpler because we can group these into two different groups the first group takes the HTML and CSS and figures out a plan that figures out where everything should go it’s kind of like a blueprint and it specifies things like widths and Heights and colors all.

Of the different elements the second group takes that plan and turns it into the pixels that you see on the screen now let’s look more closely at each of these steps the first step is called parsing and what the parsha does says is takes the HTML that you’ve downloaded and turns it into something.

That the browser can understand because the HTML when it comes in is just basically like a big paper ribbon with one long string of HTML on it and we need to turn it into something.

That the browser can actually use a data structure that will tell us what the different elements on the page are and what their relationships are to each other so I think of this kind of like a family tree and what the parser does is it goes along this paper ribbon and with a pair of scissors basically and it sees an opening tag for an HTM HTML element is going to cut that out and put it into the family tree so let’s say it comes across a div it’ll.

Lin Clark: The Parallel Future Of The Browser (closing Keynote)