Check out a free preview of the full The Good Parts of JavaScript and the Web course

The "The Browser" Lesson is part of the full, The Good Parts of JavaScript and the Web course featured in this preview video. Here's what you'd learn in this lesson:

Doug walks through a flow chart of how the original web browsers functioned. This includes everything from fetching a URL to painting the display. He compares this original flow to scripted browsers which added an event loop.


Transcript from the "The Browser" Lesson

>> [MUSIC]

>> Douglas: So this is a flow chart of our browser. This is how the original web browser worked. You can think of it as a snake. You put your URL's on one side, your get pixels out the other side. So you feed it with the URL that goes to the fetch engine which will then go out on the Internet and find the thing and bring it back, and put it in the cache.

Then it gets given to the parse engine which will parse it and turn it into a tree, the tree being the data structure which represents the document. The tree is then given to the flow or layout engine which will figure out all of the components of the page,how big they are and how they're all located relative to each other and create a display list.

And then the display list gets given to the paint engine which will then turn it all into pixels which you can then send to the screen or to the printer. All browsers still do essentially that. When work started on the Mosaic browser, they added the image tag. So this is the hack that they came up with for making the image tag work.

When they got to the parse engine and they'd get an image tag, they'd stop, sneak back to the fetch engine, say go get that picture and they'd wait for it to come back and then they'd resume parsing. They were on one of the world's fastest university networks, so that was working really well for them.

But, Mosaic got loose, got into the world and at that time we were still on dial up modems. Anybody remember dial up modems, can anybody sing the dial up modem song.
>> Speaker 2: [LAUGH]
>> Douglas: Yeah. Yeah.
>> Speaker 2: Ding, ding, ding.
>> Douglas: And so the experience of running Mosaic on those modems was that you would wait until every image got loaded and then everything would display.

So it could take a long time to get a web page going. So those kids then moved to Netscape, and their goal is to kill Mosaic. They want to create a monster that kills Mosaic, so they make a Mozilla. And Mozilla works a little differently. So when the parse engine gets to an image tag, it goes to the fetch engine and says go get it but they then resume parsing.

They put a placeholder in the tree to represent the picture and they continue to parse. And if they see another image tag, they tell the fetch engine get that one too and put a second placeholder in the tree and they continue parsing. And then at the end, they will display what they've got so far.

And so you would see little placeholders in the thing but you saw text right away. And then as the fetch engine delivers the images, they then repeat the flow and the paint to incorporate the new things. And so there'd be an animation effect where it go, boom, boom, boom, boom, as the images would appear.

So overall this could take longer than it did on Mosaic, but the user experience was much better because they would see things immediately. And so it was a hit, it was very successful, and all browsers today are essentially doing that. It's just that networks are going so fast that we don't see the placeholders anymore.

So in Netscape Navigator 2, they added scripting. So there's now an event loop in the browser which looks something like this. We'll do the layout, we'll do the painting. We'll then wait for an event which could be something happening with the UI if someone moving a mouse or typing on a keyboard.

Or it could be something coming from the fetch engine, something happened on the network. Or it could be a timer cue saying some time has elapsed and something happens. Whatever it is, it will cause some script to run. And that script will run to completion. It's guaranteed it will not be interrupted by the next event which is a good thing.

Cuz it makes the the scripts much easier to write. That script will probably mutate the tree in some way, that the events probably caused something to want to be displayed or modified, which means we'll then do another flow and other paint and then we'll get the next event and so on, and that's basically what browsers do.

Now this is way over simplified. There are some mutations of the tree which will cause flow to happen immediately. So it's not in these very clean phases necessarily, but this is pretty much how they work. This is the way of the browser. They all do that.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now