Browser, DOM, JavaScript. Everything you need to know to build effective web-apps. Part one - Browser.
Tags: browser, dom, javascript, webdev
Published: 2020-06-14 15:15:42


Initially I planned to write only about DOM and even wrote the first article. But I came to the conclusion that in order to fully understand some of the concepts, I need to touch a little bit on how the browser works. Then I decided - Why "a little"? Maybe no? That's what I've decided. 
Now my article about DOM is this second article in the series. It's just like in Star Wars :) 
In this article I will consider those basic things of browser work, which are most important for web developers.

# How it all started

I'm not going to go into that, but to understand the context, I'll tell you a little bit about it. In the mid-90s, there were so-called "browser wars". Each company, in addition to its HTML, had its own versions of `DOM` and `browser engines` until W3C obliged all companies to standardize technology. A common standard has not yet been achieved, which is why we have to create cross-browser versions of web applications.

> **_REMARK_**
Browser engine != Browser.
Often, the browser engine is equated with the browser. But that's not really true. All the engine does is parset and display the content. The browser, on the other hand, performs much more, more complex tasks. However, it is the different engine that makes us support all sites.

_Browser architecture scheme_
![Image](https://dev-to-uploads.s3.amazonaws.com/i/049goikplpvozmm5gjxn.png)

# Okay, how does it all work? #

While it's running, the browser runs several processes.

![Image](https://developers.google.com/web/updates/images/inside-browser/part1/browser-arch.png)

> **_REMARK_**
The computer program itself is just a passive sequence of instructions. While the process is the direct execution of these instructions. The process can generate other processes as well as threads that share the resources of the parent process.

Since in this article we consider the browser in the context of web development, we are interested only in one process - **`rendering process`**.

> **_IDEA_**
Maybe in the future, I'll take a closer look at the browser work.

For each tab, the browser launches this process. Moreover, modern browsers also run the `rendering process` for each `iframe`. This is done in order to isolate each tab and `iframe`. And if any child process fails, kill it, not the main process. It's called `site isolation`.
The `rendering process` runs threads. We will only consider the main thread. Almost all the work in the `rendering process` is done by browser engines.
The main engines at the moment are:

1. Blink.
1. Gecko
1. WebKit

> **_REMARK_**  
> During development, you should also consider `EdgeHTML`, but soon `Microsoft` will completely abandon it.

Now let's take a look at what happens when drawing a page.

_this is a simplified model_
![Image](https://dev-to-uploads.s3.amazonaws.com/i/u9gfvpajckuukx9jujm3.png)

First of all, resources (`HTML` and `CSS`) are parsed and converted to object trees. They are combined and another tree is constructed based on them - the `render tree`. This tree contains only those elements that will be drawn on the screen.

> **_REMARK_**
An element with the style `display: none` - will not be contained in this tree. Because the element does not have its own visual representation.

After that, a walk through this tree to calculate their size and location on the screen. This process is called `layout` (or `flow` in Firefox).

Then, all calculated elements are drawn onto the screen.

Let us dwell on each point.

# HTML parsing.

Many parsers are based on `context free grammar`, which allows them to work very efficiently. But the main problem with parsing `HTML` is that it cannot be defined using` context free grammar`. This is because the browser needs to keep track of how `HTML` is written. If the tag is not closed somewhere, then the browser will close it and so on. Even if you do not make mistakes, this feature slows down parsing very much.

Another important feature of `HTML` parsing is how it reacts when it encounters the `<script>`tag. Parsing stops until the script is executed and only after that continues to work. This is why you should place scripts before the `</body>` tag or use `async` and `defer`. `async` and` defer` - allow loading scripts in parallel with parsing.

> **_REMARK_**
`defer` differs in that it guarantees the execution order.

It should be noted that if there are very large scripts, the browser starts to allocate separate streams and tries to optimize the download.

A similar situation occurs when the parser encounters `CSS`. Style loading blocks parsing.

# CSS parsing.

CSS parsing is free of such problems as when parsing HTML and, in principle, is no different.

# Attachment

At this point, the render tree` begins to be constructed.

# Layout (Flow)

After the `render tree` is formed, the position and geometric dimensions of the elements of this tree are calculated.

The speed of `layout` directly depends on the quality of the` CSS` you wrote.

**What does it mean?**

This means that each `CSS` rule needs to be applied to a separate `DOM` node. This is achieved by recursively traversing the `HTML` tree, another tree - the `CSS` tree. And the more difficult it is to write `CSS`, the longer it will take.

`CSS` - selectors are not equal in performance.
The most productive are: `#(id)`, `.(Class)` Slightly less productive - `type(for ex. - h1)`
Combinations of attributes are not productive, and the most not productive are `pseudo elements`.

> **_REMARK_**
There are various `css methodologies` which are based on productive selectors.

# Painting

Here the image is constructed and sent to the `GPU` to draw it onto the screen.

_that's how the `layout` process goes_
![Gif](https://dev-to-uploads.s3.amazonaws.com/i/yzwm08a4mk01eee8trku.gif)

> **_REMARK_**
[source](https://www.youtube.com/watch?v=ZTnIxIA5KGw)

In browsers, in devtools you can enable a mode that will show the rendering of elements.

# Conclusion

We examined the main points of the browser. In some of the following articles, we will touch upon a few more interesting points.

---

# Afterword.

Thank you very much for your attention. I hope it was useful for you 🙏
Follow me, it makes me write new articles 😌
I'd be happy for your feedback.
C u! 😉

<a href="https://www.buymeacoffee.com/lKsISqg" target="_blank"><img src="https://cdn.buymeacoffee.com/buttons/default-green.png" alt="Buy Me A Coffee" style="height: 51px !important;width: 217px !important;" ></a>