Forem: Arika O

Tree shaking in Javascript - short explanation

Arika O — Sun, 31 Mar 2024 14:13:58 +0000

Tree shaking is a term commonly used with Javascript and it refers to the process of eliminating dead code when trying to optimize it.

Before moving further, we should first understand what "dead code" means:

Dead code refers to code that is not being executed and has no impact on the final output. If you have unused variables and functions or lines that will never be reached, you most likely suffer of an obvious case of "dead code".

Now that we understand what dead code is, you might ask yourself, when and why do we need to eliminate it?

THE WHY
When sending Javascript over the network, the code is often compressed. What this mean is that, in reality the code is much bigger after the browser decompresses it. Then the hard work starts: after is being downloaded by the browser, JavaScript must be parsed, compiled and then finally executed. Compared to other resources (images for example), Javascript is expensive to process, so we had to come up with ways of making the code more performant.

THE WHEN
Among other techniques, tree shaking is one way we can improve Javascript's performance by reducing bundle size.

Bundle size refers to the combined file size of all JavaScript code, libraries, and dependencies that are bundled together and served to the end-user in their browser.

Bigger bundle size means longer loading times, so the goal is smaller bundle sizes. Tree shaking can help us achieve that while the code gets compiled.

THE HOW

We declare all of our imports and exports for each of our Javascript modules.
The bundler (Webpack, Rollup, Parcel etc) analyzes our dependency tree during the compilation.
All unused code is dropped from the final bundle.

IMPORTANT - take advantage of the ES6 imports and exports
If you want tree shaking to happen, you must use exports and imports in your modules. If you use require, the bundler isn't able to reliably tell what is actually exported or imported so it can't determine what code is safe to drop.

RESOURCES

IMAGE SOURCE

Pavel Danilyuk on Pexels

Early return pattern in JavaScript

Arika O — Wed, 27 Dec 2023 21:03:52 +0000

This concept might sound fancy but I bet you are already using it and maybe you didn't know it had a name. It is an approach mainly used to keep readability of methods and functions and it is not specific to Javascript.

The Early Return pattern is a coding technique where a function or method is stopped as soon as a specific condition is met and evaluates to true. Instead of proceeding with the rest of the function's logic, the method immediately returns a value or performs an action based on the condition's outcome.

Let's dive deeper into this definition using an example. We have a very simple function with two parameteres of type integer that returns their sum.


const addTwoIntegers = (firstInteger, secondInteger) => {
  return firstInteger + secondInteger;
};

Looks about right, doesn't it? But let's say that we want to throw an error if one of the arguments is not an integer.


const addTwoIntegers = (firstInteger, secondInteger) => {
  let result;

  if (Number.isInteger(firstInteger) && Number.isInteger(secondInteger)) {
    result = firstInteger + secondInteger;
  } else {
    throw new Error("Both arguments need to be integers!");
  }

  return result;
};

Chrisis averted. Now another requirement gets added: both integers need to be positive.

const addTwoIntegers = (firstInteger, secondInteger) => {
  let result;

  if (Number.isInteger(firstInteger) && Number.isInteger(secondInteger)) {
    if (firstInteger > 0 && secondInteger > 0) {
      result = firstInteger + secondInteger;
    } else {
      throw new Error("Both integers need to be positive!");
    }
  } else {
    throw new Error("Both arguments need to be integers!");
  }

  return result;
};

I believe you already notice the code becoming harder to read. Imagine that more requirements would be added to the function and we would need to implement all of them. We could of course do this using multiple if-else statements or we could go back to our defintion and try to re-write our function using the early return pattern. For this, we would write everything that we wouldn't want to happen in our function at the top, and everything that we want to happen at the bottom. In simple terms, we will be reversing the conditions we wrote in the initial example.

 const addTwoIntegers = (firstInteger, secondInteger) => {
  let result;

  if (!Number.isInteger(firstInteger) || !Number.isInteger(secondInteger)) {
    throw new Error("Both arguments need to be integers!");
  }
  if (firstInteger <= 0 || secondInteger <= 0) {
    throw new Error("Both integers need to be positive!");
  }

  return result;
};

The code in our last example is easier to read because we removed nested conditionals. Also, the expected result of our function is written at the end, so it's easy to find.

NOTE
In some situation, this pattern has no real advantage, so be mindful of when to use it. It is recommened to return early if we have simple conditions that can be checked at the beginning of a function or method.

Refrence materials:

Manipulating the DOM using Javascript - traversing the DOM(part 2)✂️🕹

Arika O — Fri, 19 Aug 2022 05:56:54 +0000

In the last article we learned what the DOM is and that it can be manipulated (change the nodes inside it). We also learned about one way we can target DOM nodes using different selectors (if you didn't read the first article of the series, I recommend doing so before going any further). We basically learned how to make use of the built-in methods of the document object to access HTML elements by class, id, tage name or query selectors.

Another way of targeting nodes is by traversing the DOM. Traversing simply means to move throught the DOM using the relation between nodes (when having access to a certain DOM node, we can reach its related nodes). This means we can stay on the same DOM level (branch) while moving up, down or even sideways.

But why would we need to do that? We would think that using document.querySelector() would be enough for every situation we encounter when trying to manipulate the DOM. Well, yes and no.

Let's think of an analogy

Imagine you are inside of your favorite book store, where the books in a series are sorted in ascending order, from left to right. You are looking at the first Harry Potter volume that's sitting on a shelf. You're missing the first two volumes and you would like to buy them, so after you found the first one, you know the second should be next to it. Now you have two possibilities to get the second volume:

You get it directly from the shelf, since you can move a bit to the right and find it right away.
You go to the cash register and ask for the person working there to look for the book in their system, tell you where in the store it's located and then go get it.

Which approach would be faster? The first one, of course. We found the second volume based on the position (relation) to the first one, instead of interogating the system (do a search by name). Based on this analogy, it will always be easier to move from one node to the other than doing a full search.

TRAVERSING THE DOM

Before moving forward, let's write some simple HTML code so we can visualize our examples better:

<!DOCTYPE html>
<html>
 <head>
   <title>Traversing the DOM is fun!</title>
 </head>
 <body>
  <h2>How to</h2>
  <p>If you want to learn how to traverse the DOM, you should continue reading this 
   tutorial.</p>
  <h2>We can traverse the DOM based on the relation between:</h2>
  <ul id="nodesList">
    <li>Parent nodes</li>
    <li>Children nodes</li>
    <li>Siblings nodes</li>
  </ul>
 </body>
</html>

A real representation of the DOM based on the above HTML looks like bellow (if you want to generate real DOM trees, you can use this tool)

We can traverse the DOM based on the relation between parent, children and sibling nodes. We have the first node in the tree which is called the root node. This is the only node that doesn't have a parent since it's positioned on the highest level. Every other node has exactly one parent and can have any number of children. We call nodes with the same parent sibling nodes.

In our example above, the simplest parent-child relationship between nodes is:

the document is the root node and it has two children: the DOCTYPE declaration and the html
the html is the parent of head and body
the body is the parent of h2, p, h2 and ul
the ul is parent to the lis

Also, let's remember that everything in an HTML document is considered a node and we have:

the Document, which in itself is a node
HTML elements, which are Element Nodes
the text inside the HTML elements, which are Text Nodes
comments, which are Comment Nodes

TRAVERSING BASED ON THE PARENT NODE RELATION

A parent node is any node that is one level above another node, or closer to the document node in the DOM hierarchy. There are two ways to get the parent of a node: parentNode and parentElement. So, in our example, if we would want to get the parent node of the first h2, we would say:

// first we target the h2 tag
const headerTwo = document.getElementsByTagName("h2")[0];
const parent = headerTwo.parentNode;
console.log(parent);
► (1) [body]

What we are going to get is the <body></body> tag, since it's one level above the <h2></h2> tag. If we want to go even one more level up, we can chain multiple parentNode properties, like so:

const headerTwo = document.getElementsByTagName("h2")[0];
const parent = headerTwo.parentNode.parentNode;
console.log(parent);
► (1) [html]

Now we 'll be targeting the <html></html> tag since it's one level above the <body></body>.

TRAVERSING BASED ON THE CHILDREN NODES RELATION

The children of a node are considered to be all nodes that are positioned one level bellow that node (that is one level of nesting).

The properties that help us target children nodes are: childNodes, firstChild, lastChild, children, firstElementChild and lastElementChild.

An interesting situation

If we would want to target the children of the <body></body> element in our example, we would probably say:

const bodyChildren = document.body.childNodes;
console.log(bodyChildren);

I assume you would expect to see a list of four items printed to the console.

► (4) [h2, p, h2, ul]

Instead you will see this:

► (9) [text, h2, text, p, text, h2, tex, ul, text]

This is happening because the childNodes property is targeting all nodes, including text nodes. In our example, the indentation between the HTML lines of code are interpreted as text.

I think now is the perfect time to clarify what nodes (which were targeted by the childNodes property) and elements (h2, p, h2, ul, which we were expecting to see in the console) are.

A node is any object represented in the DOM. Nodes can be of multiple types but the ones we are going to encounter most often are document, element and text. So, elements are just nodes of the type element. A complete list of all node types can be found here.

Coming back to out example, where instead of four nodes we got back nine, this is because childNodes selects all node types (including text), not only the element ones, which we were interested in.

If we want to select only the children of the type node element, we can use the children, firstElementChild and lastElementChild properties. So, to rewrite our example:

const bodyChildren = document.body.children;
console.log(bodyChildren);
► (4) [h2, p, h2, ul]

TRAVERSING BASED ON THE SIBLING NODES RELATION

A sibling node is any node that is on the same DOM level with any other node. In our example, h2, p, h2 and ul are all siblings since they are on the same DOM level. The property we can use to select sibling nodes are: previousSibling, nextSibling, previousElementSibling and nextElementSibling. Keep in mind that, just like in the case of child nodes, previousSibling and nextSibling select siblings of any type, whether previousElementSibling and nextElementSibling will only select nodes of type element.

So, if we want to select the second <li> element in the <ul>, we need to write:

// we target the list based on its id
const list = document.getElementById("nodesList");
// we target the first node of element type
const firstElement = list.firstElementChild;
// we use nextElementSibling to get to the second list item
const thirdElement = firstElement.nextElementSibling;
console.log(thirdElement )
► (1) [li]

If instead we would have used the nextSibling property, the return value would have been a text node since the indentation in the HTML is considered text, so we would have targeted white space (a node of type text) instead of the next list item element.

const thirdElement = firstElement.nextSibling;
console.log(thirdElement )
► (1) [text]

Now that we know how to traverse the DOM, in the next article we will focus on how we can actually change things in the DOM, with examples. See you next time!

Header source image: Paul Esch-Laurent on Unsplash

Refrence articles:

Remember to whitelist your IP when you can't connect to Mongo DB 📡💡

Arika O — Sun, 03 Jul 2022 16:51:48 +0000

I recently started looking into backend using the MERN stack, and sometimes it happens that I can't connect to a Mongo cluster, even though it worked in the past. In 99% of the cases this is because my IP adress changed and my current IP is not whitelisted*. This is nothing that can't be fixed but I never remember what causes it and I waste time until I get to the correct solution (this is pretty much like forgetting how to center a div). When I would try to connect to a cluster I would see someting like this in the terminal (in the past I think I've also seen some straight up errors, but this is the most recent message I got):

[nodemon] 2.0.16
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): *.*
[nodemon] watching extensions: js,mjs,json
[nodemon] starting `node index.js`
connection <monitor> to 52.58.6.203:27017 closed
[nodemon] clean exit - waiting for changes before restart

The connection couldn't be established because my IP address changed since I initially set up the cluster (or the last time I whitelisted my IP address). So what I would need to do is go to MongoDB Atlas and on the left side of the page, chose Security and then Network Access.

I would press ADD IP ADDRESS, wait for your current IP to be whitelisted and then try to reconnect. Now everything should work again. MongoDB is pretty good at auto detecting your current IP but if the connection still can't be established, try a quick "what's my ip" on Google and compare if the IP you got back is the same as the one detected by Mongo. If it's not, you might want to add it manually again.

*MongoDB Atlas only allows connections to clusters from IP addresses that are matched by entries in our project’s IP whitelist

How web browsers work - the render tree (part 7, with illustrations)💻 ⏳

Arika O — Wed, 01 Jun 2022 05:20:30 +0000

The trees built in the parsing phase (DOM, CSSOM) are combined into something called the render tree. This is used to compute the layout of all visible elements that will be painted to the screen in the end. The purpose of the render tree is to make sure the content of the page will paint the elements in the correct order. It will be serverd as input to the painting process that will display the pixels on the screen.

The DOM and the CSSOM are created using the HTML and the CSS files. Both of these files hold different types of information and the trees are different structures, so how does the render tree gets created?

COMBINING THE DOM WITH THE CSSOM

The browser will start doing its magic at the root of the DOM tree and traverse every visible node. Some of the nodes, like script or meta tags are not visible, so they are ignored. There are also nodes that will be hidden with the use of CSS (the display: "none" property for example) and they will also be ignored. We are only interested in the visible nodes because only they matter for the input on the screen.
For each visible node that's found in the DOM, the coresponding rules will be found in the CSSOM and they will be applied.

The result of these steps will be a render tree that contains all visible nodes, with content and styles.

THE LAYOUT (REFLOW) STAGE

The render tree holds information on which nodes are displayed along with their computed styles, but not the dimensions or location of each node.

What needs to be done next is calculate the exact position of those nodes within the viewport of the device (inside the browser window) and their size. This is the stage called layout (in Chrome, Opera, Safari and Internet Explorer) or reflow (in Firefox) but they mean the same thing. The browser starts this process at the root of the render tree and traverses it.

The reflow step doesn't happen only once, but every time we change something in the DOM that affects the layout of the page, even partially. Examples of situations when the positions of the elements is recalculated are:

adding or deleting elements from the DOM
resizing the browser window
changing the width, the position of an element or floating it

Let's get a very basic example of HTML, with some CSS applied inline:

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <title>Reflow</title>
  </head>
  <body>
    <div style="width: 100%; height: 50%">
      <div style="width: 50%; height: 50%">This is the reflow stage!</div>
    </div>
  </body>
</html>

The above code just says that inside the viewport we should have two divs, where the second one is nested inside the first. The parent div takes up 100% of the viewport and the second 50% of the parent. This will look something like this:

The output of this process is a box like model which captures exactly where each element needs to be on a screen and its size. After this step is finished, the output is ready to be passed to the next step called the painting stage.

THE PAINTING (REPAINTING) STAGE

After the browser decides which nodes need to be visible and calculates their position in the viewport, it's time to paint them (render the pixels) on the screen. This phase it is also known as the rasterization phase, where the browser converts each box calculated in the layout phase to actual pixels on the screen.

Just like the layout stage, the painting stage doesn't happen just once but every time we change something in the appearance of the elements on the screen. Examples of these situations are:

changing the outline of an element
changing background color
changing opacity or visibility

Painting means the browser needs to draw every visual part of an element to the screen, including text, colors, borders, shadows, and replaced elements like buttons and images and it needs to do it super quickly. To ensure repainting can be done even faster than the initial paint, the drawing to the screen is generally broken down into several layers. If this occurs, then compositing is necessary.

LAYERING AND COMPOSITING

Traditionally, web browsers relied entirely on the CPU to render web page content. But nowadays even the smallest devices have performant GPUs, so the attention has turned on finding ways to use this piece of hardware to achieve better performance.

Compositing is a technique to separate parts of a page into layers, painting them separately and composite as a page in a separate thread called the compositor thread. When sections of the document are drawn in different layers, overlapping each other, compositing is necessary to ensure they are drawn to the screen in the right order and the content is rendered correctly.

Generally, only specific tasks get redirected to the GPU and those are the tasks that can be handled by the compositor thread alone.

In order to find out which elements needs to be on which layer, the main thread walks through the layout tree and creates the layer tree. By default, there's only one layer (and how these layers are implemented is browser specific) but we can find the elements that would trigger a repaint and create a separate layer for each of them. This way, the repainting should not be applied to the whole page and in addition, this process will use the GPU.

If we want to hint to the browser that ceratain elements should be on a separate layer, we can use the will-change CSS attribute. There are actually specific properties and elements that signal the creation of a new layer. Some of these are <video>, <canvas>, and any element which has the CSS properties of opacity, a 3D transform, will-change and a few others. These nodes will be painted onto their own layer, along with their descendants.

KEEP IN MIND
Both of the operations discussed above, reflow and repaint, are expensive, especially on devices with low processing power like phones. That's why when dealing with DOM changes we should try to optimze them (I will talk more about this in one of the future articles in my DOM series). Some actions will trigger a repaint only and some actions both a reflow and a repaint.

Glosary:

The critical rendering path - is the sequence of steps the browser goes through to convert the HTML, CSS and JavaScript into pixels on the screen.

Resource refrences:

What book(s) are you reading these days (and we should too)? 📖🧠

Arika O — Fri, 27 May 2022 13:38:41 +0000

Currently I am reading these two books:

The Code Breaker. A book about DNA, RNA, gene theraphy and gene editing. It also touches on mRNA vaccines. I found it very interesting and relatively easy to follow, even though I know nothing about the field of genetics. One should read it, even if it's just for the sole purpose of expanding thier general knowledge.

The Art of Invisibility. A book written by a hacker on how to be online without leaving traces. The content is easy to follow but I personally find it tought to stomach. I think this book should be read by everyone concerned with their online presence and privacy.

Header source image: Shiromani Kant on Unsplash

Manipulating the DOM using Javascript - how to select nodes (part 1) 👨🏼‍🔬🎯

Arika O — Wed, 18 May 2022 06:54:17 +0000

In the beginning, websites were entirely made out of HTML and they could only display text (back in the early 90’s, computer monitors only supported 16 colours). The browser was downloading the HTML document, render it and in the end the content was displayed on the user's screen. There was no way to change that text, so in a way we could say it was set in stone.

But people wanted more than displaying boring text so they started creating interactive sites. Internet Explorer was released and Javascript was developed in 1995. This new exciting scripting language started to be used for webpages but the interactivity provided was very limited since UIs were generated using HTML and HTML couldn't be changed after the files were downloaded (that very limited interactivity eventually became known as DOM Level 0 or Legacy DOM).

From the need to be able to change the UI after the page was loaded (add, remove, edit or move elements around in the HTML document), the first standardized version of the DOM was born in 1998 and it was called DOM Level 1. Changing (manipulating) the DOM suddenly opened the door for infinite possibilities. We can now create applications that are customizable by the user, that react on user's input or even update the data we see on the screen without refreshing the page (so no extra trips to the server are needed). We can drag or move elements across the screen, delete some of them or add new ones if that's what we want.

Some concrete examples of DOM manipulation are:

change the content/ color of a button after we clicked on it
change the content of a paragraph when hovering over it
remove an item from a "To Do" list after we checked it as completed
adding a new item to a "To Do" list after we typed it in an input and clicked an "Add" button
navigating to a different page after submitting a form

THE DOM (DOCUMENT OBJECT MODEL)

The Document Object Model is a cross-platform and language-independent interface that treats an XML or HTML document as a tree structure wherein each node is an object representing a part of the document. The DOM represents a document with a logical tree.

In simple terms this means that after the browser downloads the HTML document, it converts its content into a tree like structure called the DOM (Document Object Model) and stores it in its memory.

IMPORTANT
The DOM is not a programming language and it's not a part of Javascript. It is one of the multiple web APIs built into web browsers and it has been created to be independent of any language (think of web APIs like they're collections of functions). Implementations of the DOM can be built using other scripting languages besides Javascript and every non-empty webpage has a DOM, even the ones that don't use any Javascript. You don't have to modify the DOM if your pages display only text for example, but if you want interactivity, you will probably need to work with the DOM (some of the same interactivity Javascript offers can be achieved using CSS, but this is another topic).

Things might sound a bit abstract so before going any further, let's see how this DOM actually looks like. We have a very simple HTML code snippet:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>Simple DOM example</title>
  </head>
<body>
   <section>
     <h1>This is a header!</h1>
     <h4>This is a smaller header!</h4>
     <p>This is a paragraph!</p>
     <img src="mountains.jpg" alt="Mountains covered in snow">
   </section>
   <section>
     <h2>This is another header!</h2>
     <h4>This is another small header!</h4>
     <p>This is a paragraph!</p>
     <p>This is another paragraph!</p>
   </section>
<script src="index.js"></script>
</body>
</html>

Below we can see how the DOM for the above HTML code looks like (if you want to play around with this visual representation, you can use this Live DOM viewer).

So this is the tree-like structure the HTML gets translated to. The tree is made out of nodes. Some nodes represent HTML elements (HTML, HEAD, BODY, SECTION etc) and other represent text (the ones represented as #text). A complete list of all node types can be found here.

Based on its position in the tree, a node can be a:

Root node
This is the top node of the tree, which in the case of HTML is the HTML node.
Parent node
A node which has other node(s) inside it. For example, BODY is the parent node of all nodes inside it.
Child node
A node directly inside another node. In our example, the H1 node is the child of the SECTION node.
Sibling nodes
These are nodes that are found on the same level in the DOM. H1, H4, P and IMG nodes are all siblings since they are on the same level inside the SECTION node.
Descendant node
This is a node that can be found anywhere inside another node. H4 is for example the descendant node of the BODY.

MANIPULATING THE DOM

What does manipulating the DOM means? It means we can change the nodes in the tree we've just seen, making use of APIs that can control the HTML and the styling of a page. Each node has its own properties and methods that can be manipulated using Javascript.

All the properties, methods and events available for manipulating and creating web pages are organized into objects that we're going to call interfaces. There are many DOM interfaces working together but the ones that we're going to use most often are Window and Document. A complete list of the DOM interfaces can be found here.

Window - The Window interface represents a window containing a DOM document (an open window in a browser). It holds the highest position in the DOM hierarchy, as it is a parent of the Document object and all its children .
Document - The Document interface represents any web page loaded in the browser and serves as an entry point into the web page's content, which is the DOM tree.

1.TARGETING NODES
In order to interact with any node in the tree, we first need to target (select) it. We can do this using one of the multiple methods the DOM API offers (notice that all these methods are called on the document object using the dot notation):

getElementById(). We select and HTML element making use of its id attribute. It returns an element matching the specified ID, or null if no matching element was found in the document.

<div id="idSelector">I will be selected based on id.</div>

const elementById = document.getElementById("idSelector");
console.log(elementById ); 
// will return <div id="idSelector"></div>

getElementsByClassName(). We select and HTML element based on its class attribute. This method returns a live HTMLCollection (an array-like list) of HTML elements, possibly of length 0 if no matching elements are found.

<p class="classSelector">I am a paragraph.</p>
<p class="classSelector">I am too a paragraph.</p>
<p class="classSelector">I am, you guessed it, a paragraph.</p>

const elementByClassName = document.getElementsByClassName("classSelector");
console.log(elementByClassName); 
// will return HTMLCollection {0: HTMLParagraphElement {...}, 
// 1: HTMLParagraphElement {...}, 
// 2: HTMLParagraphElement {...}}
// 0:<p class="classSelector"></p>
// 1:<p class="classSelector"></p>
// 2:<p class="classSelector"></p>

getElementsByTagName(). We target HTML elements based on their tag names. This method returns a live HTMLCollection of all matching HTML elements, possibly of length 0 if no match is found.

<p>This is fun!</p>
<p>I like writing this article!</p>
<h4>The DOM is so interesting!</h4>

const elementByTagName = document.getElementsByTagName("p");
console.log(elementByTagName); 
// will return HTMLCollection {0: HTMLParagraphElement {...}, 
// 1: HTMLParagraphElement {...}}
// 0:<p ></p>
// 1:<p ></p>

getElementsByName(). This method returns a live NodeList Collection of elements with a given name attribute in the document. If no match is found, the collection will be empty.

 <input type="text" name="someInput" />

const elementsByName = document.getElementsByName("someInput");
console.log(elementsByName); 
// will return NodeList {0: HTMLInputElement {...}}
// 0:<input type="text" name="someInput"></input>

querySelector(). Method that returns the first element within the document that matches the specified selector, or group of selectors. If no matches are found, null is returned. We can provide any selector we want as an argument (a class, an ID etc).

<div class="divClass">This is just a div!</div>
<div id="thisIsAnId">This is another div!</div>
<p name="numberOnePara">This is just a paragraph!</p>

const querySelectionByClass = document.querySelector(".divClass"); 
console.log(querySelectionByClass); 
// will return <div class="divClass"></div>

const querySelectionById = document.querySelector("#thisIsAnId");
console.log(querySelectionById); 
// will return <div id="thisIsAnId"></div>

const querySelectorByName = document.querySelector("[name='numberOnePara']");
console.log(querySelectorByName); 
// will return <p name="numberOnePara"></p>

querySelectorAll(). This method returns a static (not live) NodeList representing a list of the document's elements that match the specified group of selectors. The NodeList will be empty if no matches are found.

<p>Paragraph number 1!</p>
<p>Paragraph number 2!</p>
<p>Paragraph number 3!</p>
<p>Paragraph number 4!</p>
<p>Paragraph number 5!</p>

const queryAllParas = document.querySelectorAll("p");
console.log(queryAllParas); 
// will return NodeList {0: HTMLParagraphElement {...}, 
// 1: HTMLParagraphElement {...}, 
// 2: HTMLParagraphElement {...}, 
// 3: HTMLParagraphElement {...},
// 4: HTMLParagraphElement {...}}
// 0:<p ></p>
// 1:<p ></p>
// 2:<p ></p>
// 3:<p ></p>
// 4:<p ></p>

GLOSSARY

HTML Collection - in simple terms, an HTML Collection is an array-like object that holds HTML elements extracted from a document. An HTML Collection can contain only Element Nodes.
NodeList - It's a collection of nodes. It is similar to an HTML Collection but it can contain all type of nodes (Element, Text and Attribute) not only Element Nodes.
Live HTMLCollection - The collection updates when the DOM updates.
Static HTML Collection - If the DOM updates, the changes are not reflected in the collection.
Live NodeList - The collection updates when the DOM updates.
Static NodeList - If the DOM updates, the changes are not reflected in the collection.

Resource refrences:

Header image source: Jackson So/@jacksonsophat on Unsplash

How web browsers work - creating the accessibility tree (part 6, with illustrations)🌴🐱‍💻

Arika O — Sun, 08 May 2022 09:35:52 +0000

Besides all these trees we've been talking about until now (DOM, CSSOM and AST), browsers also build something called the accessibility tree.

Accessibility (often abbreviated to A11y — as in, "a", then 11 characters, and then "y") in web development means enabling as many people as possible to use websites, even when those people's abilities are limited in some way. For many people, technology makes things easier. For people with disabilities, technology makes things possible. Accessibility means developing content to be as accessible as possible, no matter an individual's physical and cognitive abilities and how they access the web (ACT).

6. BUILDING THE ACCESSIBILITY TREE

In general, disabled users can and do use web pages with a variety of assistive technologies. They use screenreaders, magnifiers, eye tracking, voice commands and more. In order for any of these technologies to work, they need to be able to access the page's content. And since they can't read the DOM directly, the ACT comes into play.

The accessibility tree is built using the DOM and it will be later used by the assistive devices to parse and interpret the content of the webpage we are visiting. ACT is like a semantic version of the DOM and it gets updated every time the DOM gets updated. Each DOM element that needs to be exposed to assistive technologies will have a corespondent node in the ACT. Until the ACT is not built, the content is not accessible to screen readers.

To view what the accessibility tree actually looks like, you can use Google Chrome by going to a page of your choosing. Open the debugger (F12) and go to the Elements tab. From there, on the right side you can select the Accessibility pane.

I went to Google and inspected the search input and this is what I got in the Accessibility pane under Computed:

The importance of using semantic HTML is beyond the scope of this article, but as developers, we should all keep in mind that the websites we build should be made availabe to everyone who wishes to use them. If you want to read more on the subject, a good introductory article into web accessibility can be found here. According to The Internet Society Accessibility Special Interest Group, there are now over 1.3 billion people worldwide – about 15 percent of the world's population – that experience some form of disability.

Resource refrences:

How web browsers work - executing the Javascript (part 5, with illustrations)💻🌠

Arika O — Wed, 04 May 2022 19:11:03 +0000

While the CSS is being parsed and the CSSOM created, other assets, including JavaScript files, are downloaded. This is happening thanks to the preloader we mentioned in the previous articles.

A preloader is like a parser that scans the HTML file while the main parser is processing the HTML code. Its role is to look for resources like stylesheets, scripts or images (that also need to be retrieved from a server) and request them. Hopefully, by the time the HTML is parsed, those resources are already downloaded and ready to be processed.

5. JAVASCRIPT EXECUTION

So, after we get the Javascript file from the server, the code is interpreted, compiled, parsed and executed. The computer can't understand Javascript code, only the browser can. The JS code needs to be translated into something the computer can work with and this is the job of the Javascript browser engine (not to be confused with the browser engine). Depending on the browser, JS engines can have different names and work differently.

Javascript engines

A javascript engine (sometimes also called an ECMAScript engine) is a piece of software that executes (runs) Javascript code in the browser, and not only (the V8 engine is a core component of the Node.js environment, for example).

JavaScript engines are typically developed by web browser vendors, and every major browser has one. We said the most used browsers as of today are Chrome, Safari, Edge and Firefox. Each one is using a different Javascript engine and these are:

V8
V8 is Google’s high-performance JavaScript engine. It is written in C++ and it's used in Chrome and in Node.js, among others. It implements ECMAScript (a JavaScript standard meant to ensure the interoperability of web pages across different web browsers) and WebAssembley. It implements ECMA-262.

JavaScriptCore
JavaScriptCore is the built-in JavaScript engine for WebKit and it powers the Safari browser, Mail and other applications used on macOS. It currently implements ECMAScript as in ECMA-262 specification. Also it also called SquirrelFish or SquirrelFish Extreme.

Chakra
Chakra is a Javascript engine developed by Microsoft for its Microsoft Edge web browser and other Windows applications. It implements ECMAScript 5.1, and has partial (growing) support for ECMAScript 6. It is written in C++.

SpiderMonkey
SpiderMonkey is Mozilla's Javascript and WebAssembly Engine. It is written in C++, Javascript and Rust and it is used to power Firefox, Servo and other projects.

In the beginning, Javascript engines were simple interpreters. The modern browsers we use today have the capacity to do something called Just-In-Time (JIT) compilation, a mix between compilation and interpretation.

Compilation
During compilation, a piece of software called the compiler takes the code written in a high-level language and converts it into machine code, all at once. An intermediate file (called an object file) is created and that file can run on any machine. After these steps are taken, the code can be executed (imediately after, sometimes in the future or never).

Interpretation
During interpretation, the interpreter is going through the Javascript code line by line and executes it imediately. No compilation is taking place so no Object Code is created (the output of the code is created by the interpreter itself, using its internal mechanisms). Older versions of Javascript use this type of code execution.

JIT Compilation
Just in time compilation is a feature of an interpreter for a given language and it tries to take advantage of both compilation and interpretation. Whether during pure compilation, the code is translated before it is executed, in JIT compilation the code is translated while it is being executed (at run time). So we could say that source code is converted to machine code on the fly. Newer versions of Javascript use this type of code execution.

A very important aspect about JIT compilation is that it will compile the source code into machine code instructions of the running machine. This means that the resulting machine code is optimized for the running machine’s CPU architecture.

In super simple terms, these three processes could be resumed to:

Compiler: translates the code
Interpreter: runs the code
JIT Compiler: translates while running the code

Today, the line between the terms compilation and interpretation has become very blurry so the subject can be extensively debated. If you want to know more about these processes, you could read this article on Mozilla Hacks for starters.

Notice I mentioned older and newer version of Javascript. Browsers that don't support newer versions of the language will interpret the code while the ones that do will use some version of JIT to execute the code (the V8, Chakra JavaScriptCore and SpiderMonkey engines all use JIT). The truth is that even though Javascript is an interpreted language (it does not need compilation), most browsers today will use JIT compilation to run the code, instead of pure interpretation.

How is the Javascript code processed

When Javascript code enters the Javascript engine it gets parsed as a first step. This means the code is read, and while this is happening, the code is transformed into a data structure called the Abstract Syntax Tree (AST). The code will be split into pieces that are relevant to the language (like function or const keywords) and then all these pieces will build the Abstract Synta Tree.

Let's say we have a file containing a program that only does one thing, and that's to define a variable:



const age = 25;

This is how this incredibly super simple line of code would look as an Abstract Syntax Tree (I am using @babel/parser-7.16.12):

If you want convert some Javascript to an Abstract Syntax Tree yourself, you can use this tool. The AST resulted after writing my varible is actually much bigger and has more nodes that are hidden in the screen shot.

After the AST has been built, it gets translated into machine code and executed right away, since modern Javascript uses Just-In-Time compilation. The execution of this code will be done by the Javascript engine, making use of something called the "call stack".

A call stack is a mechanism for an interpreter (like the JavaScript interpreter in a web browser) to keep track of its place in a script that calls multiple functions — what function is currently being run and what functions are called from within that function etc.

Refrence materials:

How web browsers work - parsing the CSS (part 4, with illustrations)⏳🌐

Arika O — Fri, 29 Apr 2022 14:31:14 +0000

After the HTML has been parsed, it's time to parse the CSS (found in in external CSS files and in style elements) and build the CSSOM tree (CSS Object Model).

4. CSS PARSING

When the browser encounters a CSS stylesheet, be it external or embeded, it needs to parse the text into something it can use for styling the layouts. The data structure that the browser turns the CSS into is called the CSSOM. The DOM and the CSSOM follow similar concepts, in the sense that they are both trees, but they are different data structures. Just like building the DOM out of our HTML, building the CSSOM out of CSS is considered a render-blocking process.

Tokenization & building the CSSOM

Similar to HTML parsing, CSS parsing starts with tokenization. The CSS parser takes the bytes and converts them into characters, then tokens, then nodes and finally they are linked into the CSSOM. The browser does something called selector machting which means that each set of styles will be matched against all nodes (elements) on the page.

The browser starts with the most general rule applicable to a node (e.g: if a node it's the child of the body element, then all body styles are inherited by that node) and then recursively refines the computed styles by applying more specific rules. This is why we say that the style rules are cascading.

Imagine we have the HTML and CSS below:



body {
  font-size: 16px;
  color: white;
} 

h1 {
  font-size: 32px;
}

section {
  color: tomato;
}

section .mainTitle {
  margin-left: 5px
}

div {
  font-size: 20px;
}

div p {
  font-size:  8px;
  color: yellow;
}

The CSSOM for this code would look something like this:

Note that in the schema above, the nested elements have both inherited styles (from the parent - e.g: h1 inherits its color from the body and the section inherits its font-size from the body) and their own styles (which can overwrite rules inherited from the parent or not - e.g: p overwrites both the color and the font-size inherited from the div and mainTitle doesn't get its left margin from a parent node).

Since we can have multiple sources for our CSS and they can contain rules that apply to the same node, the browser must decide which rule will apply in the end. That's when specificity comes into play and if you want to read more about it, you can visit this page.

Imagine you're in the airport and you're looking for your friend John. If you want to find him by calling out his name, you could call for "John". Chances are that more than one John will be in the airport at the same time, so they might all respond. A better approach would be to call your friend using his full name, so that when you shout "John Doe", you'll have better chances to finding him, since "John Doe" is more specific than just "John".

On the same note, let's say we have this element:



<p>
  <a href="https://dev.to/">This is just a link!</a>
</p>

and these CSS styles:



a {
   color: red;
}

p  a {
   color: blue;
}

Which rule do you think will the browser apply? The answer is the second rules, since all anchor tags inside a paragraph selector combination has more specificity than just all anchor tags selector. If you want to play around with specificity, you can use this Specificity calculator.

IMPORTANT
CSS rules are read from right to left, meaning that if we have something like: section p { color: blue; }, the browser will first look for all p tags on the page and then it will look if any of those p tags have a section tag as a parent. If that's the case, it will apply the CSS rule.

Refrence materials:

How web browsers work - parsing the HTML (part 3, with illustrations)📜🔥

Arika O — Mon, 25 Apr 2022 16:23:20 +0000

Until now we discussed navigation and data fetching. Today we're going to talk about parsing in general and HTML parsing in particular.

3. HTML PARSING

We saw how after the initial request to the server, the browser receives a response containing the HTML resources of the webpage we are trying to access (the first chunk of data). Now the job of the browswer will be to start parsing the data.

Parsing means analyzing and converting a program into an internal format that a runtime environment can actually run.

In other words, parsing means taking the code we write as text (HTML, CSS) and transform it into something that the browser can work with. The parsing will be done by the browser engine (not to be confused with the the Javascript engine of the browser).

The browser engine is a core component of every major browser and it's main role is to combine structure (HTML) and style (CSS) so it can draw the web page on our screens. It is also responsible to find out which pieces of code are interactive. We should not think about it like a separate piece of software but as being part of a bigger sofware (in our case, the browser).

There are many browser engines in the wild but the majority of the browsers use one of these three actively developed full engines:

Gecko
It was developed by Mozilla for Firefox. In the past it used to power several other browsers but at the moment, besides Firefox, Tor and Waterfox are the only ones still using Gecko. It is written in C++ and JavaScript, and since 2016, additionally in Rust.

WebKit
It's primarily developed by Apple for Safari. It also powers GNOME Web (Epiphany) and Otter. (surprinsingly enough, on iOS, all browsers including Firefox and Chrome, are also powered by WebKit). It it written in C++.

Blink, part of Chromium
Beginning as a fork of WebKit, it's primarily developed by Google for Chrome. It also powers Edge, Brave, Silk, Vivaldi, Opera, and most other browser projects (some via QtWebEngine). It is written in C++.

Now that we understand who's going to do the parsing, let's see what happens exactly after we receive the first HTML document from the server. Let's assume the document looks like this:



<!doctype HTML>
<html>
 <head>
  <title>This is my page</title>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>
<body>
  <h1>This is my page</h1>
  <h3>This is a H3 header.</h3>
  <p>This is a paragraph.</p>
  <p>This is another paragraph,</p>
</body>
</html>

Even if the request page's HTML is larger than the initial 14KB packet, the browser will begin parsing and attempting to render an experience based on the data it has. HTML parsing involves two steps: tokenization and tree construction (building something called the DOM Tree (Document Object Model)).

Tokenization

It is the lexical analysis and it converts some input into tokens (basic components of source code). Imagine we would take an English text and break it down into words, where the words would be the tokens.

What results at the end of the tokenization process is a series of zero or more of the following tokens: DOCTYPE, start tag (<tag>), end tag (</tag>), self-closing tag (<tag/>), attribute names, values, comments, characters, end-of-file or plain text content within an element.

Building the DOM

After the first token gets created, tree building starts. This is essentially creating a tree like structure (called the Document Object Model) based on the previously parsed tokens.

The DOM tree describes the content of the HTML document. The <html> element is the first tag and root node of the document tree. The tree reflects the relationships and hierarchies between different tags. We have parent nodes and tags nested within other tags are child nodes. The greater the number of nodes, the longer it will takes to build the DOM tree. Below is the DOM Tree for the HTML document example we got from the server:

In reality, the DOM is more complex than what we see in that schema, but I kept it simple for a better undestanding (also, we'll talk in more detail about the DOM and its importance in a future article).

This building stage is reentrant, meaning that while one token is handled, the tokenizer might be resumed, causing further tokens to be emitted and processed before the first token's processing is complete. From bytes until the DOM is created, the complete process would look like something like this:

The parser works line by line, from top to bottom. When the parser will encounter non-blocking resources (for example images), the browser will request those images from the server and continue parsing. On the other hand, if it encounters blocking-resources (CSS stylesheets, Javascrpt files added in the <head> section of the HTML or fonts added from a CDN ), the parser will stop execution until all those blocking resources are downloaded. That's why, if yu're working with Javascript it is recommended to add your <script> tags at the end of the HTML file, or if you want to keep them in the <head> tag, you should add to them the defer or async attribute (async allows for asynchronous as soon as the script is downloaded and defer allows execution only after the whole document has been parsed.).

Pre-loaders and making the page faster

Internet Explorer, WebKit and Mozilla all implemented pre-loaders in 2008 as a way of dealing with blocking resources, especially scripts (we said earlier, that when encountering a script tag, the HTML parsing would stop until the script is downloaded and executed).

With a pre-loader, when the browser is stuck on a script, a second ligher parser is scanning the HTML for resources that need to be retrieved (stylesheets, scripts etc). The pre-loader then starts retrieving these resources in the background with the aim that by the time the main HTML parser reaches them they may have already been downloaded (in case these resources were already cached, this step is skipped).

Refrence materials:

How web browsers work - fetching data (part 2, with illustrations)🚀

Arika O — Sat, 23 Apr 2022 11:19:19 +0000

In the last article we talked about navigation, the first step the browser takes to display the websites. Today we'll move onto the next step and see how resources get fetched.

2. DATA FETCHING

HTTP Request

After we established a secure connection with the server, the browser will send an initial HTTP GET request. First, the browser will request the markup (HTML) document for the page. It will do this using the HTTP protocol.

HTTP (Hypertext Transfer Protocol) is a protocol for fetching resources such as HTML documents. It is the foundation of any data exchange on the Web and it is a client-server protocol, which means requests are initiated by the recipient, usually the Web browser.

The method - e.g: POST, GET, PUT, PATCH, DELETE etc
URI - stands for Uniform Resource Identifier. URIs and used to identify abstract or physical resources on the Internet, resources like websites or email addresses. An URI can have up to 5 parts:

scheme: used to say what protocol is being used
authority: used to identify the domain
path: used to show the exact path to the resource
query: used to represent a request action
fragment: used to refer to a part of a resource



// URI parts
scheme :// authority path ? query # fragment

//URI example
https://example.com/users/user?name=Alice#address

https: // scheme name
example.com // authority
users/user // path
name=Alice // query
address // fragment

HTTP header fields - are a list of strings sent and received by both browser and server on every HTTP request and response (they are usually invisible for the end-user). In the case of requests, they contain more information about the resource to be fetched or about the browser requesting the resource.

If you want to see how these headers look like, go to Chrome and open the Developer tools (F12). Go to the Network tab and select FETCH/XHR. In the screen shot bellow I just made a Google search for Palm Springs and this is how the request headers looked like:

HTTP Response

Once the server receives the request, it will process it and reply with an HTTP response. Attached to the body of the response we can find all relevant headers and the contents of the HTML document we requested.

Status code - e.g: 200, 400, 401, 504 Gateway Timeout etc (we aim for a 200 status code, since it tells us everything went ok and the request is successful)
Response header fields - hold additional information about the response, like its location or about the server providing it.

An example of an HTML document can look something like:



<!doctype HTML>
<html>
 <head>
  <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta http-equiv="X-UA-Compatible" content="ie=edge">
  <title>This is my page</title>
  <link rel="stylesheet" src="styles.css"/>
  <script src="mainScripts.js"></script>
</head>
<body>
  <h1 class="heading">This is my page</h1>
  <p>A paragraph with a <a href="https://example.com/about">link</a></p>
  <div>
    <img src="myImage.jpg" alt="image description"/>
  </div>
  <script src="sideEffectsScripts.js"></script>
</body>
</html>

For the same google search I mentioned earlier, this is how the reponse headers look like:

If we take a look at the HTML document, we see that it refrences different CSS and Javascript files. These files will no be requested until the browser won't encounter these links but this doesn't happen in this step, but in the parsing phase which we'll discuss in the next articles. At this point in time, only the HTML is requested and received from the server.

The response for this initial request contains the first byte of data received. Time to First Byte (TTFB) is the time between when the user made the request (by typing the website's name in the address bar) and the receipt of the first packet of HTML (which is usually 14kb).

TCP Slow Start and congestion algorithms

TCP slow start is an algorithm that balances the speed of a network connection. The first data packet will be 14kb (or smaller) and the way it works is that the amount of data transmitted is increased gradually until a predetermined treshold is reached. After each packet of data is received from the server, the client responds with an ACK message. Since the connection has a limited capacity, if the server sends too many packets too quickly, they will be dropped. The client won't send any ACK messages so the server will interpret this as congestion. This is where congestion algorithms come into play. They monitor this flow of sent packets and ACK messages to determine a rate at which traffic is optimal and create a steady traffic stream.

Refrence materials: