As JavaScript is getting more and more popular, teams are leveraging its support on many levels in their stack — front-end, back-end, hybrid apps, embedded devices and much more. This article is meant to be aimed at digging deeper into JavaScript and how it really works.

# **Overview**

Almost everyone has already heard of the V8 Engine as a concept, and most people know that JavaScript is single-threaded or that it is using a callback queue.

In this post, we’ll go through all these concepts in detail and explain how JavaScript actually runs. By knowing these details, you’ll be able to write better, non-blocking apps that are properly leveraging the provided APIs.

If you’re relatively new to JavaScript, this blog post will help you understand why JavaScript is so “weird” compared to other languages. And if you’re an experienced JavaScript developer, hopefully, it will give you some fresh insights on how the JavaScript Runtime you’re using every day actually works.

In this article, we will discuss the internal working of JavaScript in the run-time environment and the browser. This will be an overview walk-through of all the core components that are involved in the execution of JavaScript code. We will discuss the following components:

1. JavaScript Engine
2. JavaScript Runtime Environment
3. The Call Stack
4. Concurrency and Event Loop

Let’s begin with the JavaScript engine.

# **The JavaScript Engine**

As you may heard before, JavaScript is an **interpreted programming language**. It means that source code isn’t compiled into binary code prior to execution.

How your computer can understand what to do with a plain text script?

That’s the job for a JavaScript engine. JavaScript engine is simply a computer program that execute JavaScript code. JavaScript engines are inbuilt in all the modern browsers today. When the JavaScript file is loaded in the browser, JavaScript engine will execute each line of the file from top to bottom (to simplify the explanation we are avoiding hoisting in JS). JavaScript engine will parse the code line by line, convert it into machine code and then execute it.

![https://miro.medium.com/max/640/1*BoZoWnaWz4b0Je8iPCHxVQ.png](https://miro.medium.com/max/640/1*BoZoWnaWz4b0Je8iPCHxVQ.png)

Every browser has its own JavaScript engine but the most well known engine is Google’s V8. The V8 engine powers Google Chrome but also Node.js which is that JavaScript Runtime.

![https://miro.medium.com/max/443/1*4dOuG6zvGAWxobk3UhVN_Q.png](https://miro.medium.com/max/443/1*4dOuG6zvGAWxobk3UhVN_Q.png)

Browser engines

The Engine consists of two main components:* Memory Heap — this is where the memory allocation happens* Call Stack — this is where your stack frames are as your code executes

![https://miro.medium.com/max/700/1*RLbK8nM3pfLWPu4qIUaWww.png](https://miro.medium.com/max/700/1*RLbK8nM3pfLWPu4qIUaWww.png)

Any JavaScript engine always contains a call stack and a heap. The call stack is where our code is actually executed. Then the heap is an unstructured memory pool which stores all the objects that our application needs.

# **The Runtime**

So far we have discussed JavaScript engine, but the JavaScript engine doesn’t run in isolation. It runs inside an environment called JavaScript Runtime Environment along with many other components. JRE is responsible for making JavaScript asynchronous. It is the reason JavaScript is able to add event listeners and make HTTP requests asynchronously.

JRE is just like a container which consists of the following components:

1. JS Engine
2. Web API
3. Callback Queue or message queue
4. Event Table
5. Event loop

![https://miro.medium.com/max/700/1*sV2l-ME3FC9wBUyLnPoNNA.png](https://miro.medium.com/max/700/1*sV2l-ME3FC9wBUyLnPoNNA.png)

And then, we have the so popular **event loop** and the **callback queue**.

# **The Call Stack**

JavaScript is a single threaded programming language , which means it has a single Call Stack. Therefore it can do one thing at a time.

The Call Stack is a data structure which records basically where in the program we are. If we step into a function, we put it on the top of the stack. If we return from a function, we pop off the top of the stack. That’s all the stack can do.

Let’s see an example. Take a look at the following code:

```
function multiply(x, y) {
    return x * y;
}function printSquare(x) {
    var s = multiply(x, x);
    console.log(s);
}printSquare(5);
```

When the engine starts executing this code, the Call Stack will be empty. Afterwards, the steps will be the following:

![https://miro.medium.com/max/700/0*pJhM8I34lOnEjBt3.png](https://miro.medium.com/max/700/0*pJhM8I34lOnEjBt3.png)

Each entry in the Call Stack is called a **Stack Frame**.

Running code on a single thread can be quite easy since you don’t have to deal with complicated scenarios that are arising in multi-threaded environments — for example, deadlocks.

But running on a single thread is quite limiting as well. Since JavaScript has a single Call Stack.

# **Concurrency & the Event Loop**

What happens when you have function calls in the Call Stack that take a huge amount of time in order to be processed? For example, imagine that you want to do some complex image transformation with JavaScript in the browser.

You may ask — why is this even a problem? The problem is that while the Call Stack has functions to execute, the browser can’t actually do anything else — it’s getting blocked. This means that the browser can’t render, it can’t run any other code, it’s just stuck. And this creates problems if you want nice fluid UIs in your app.

And that’s not the only problem. Once your browser starts processing so many tasks in the Call Stack, it may stop being responsive for quite a long time. And most browsers take action by raising an error, asking you whether you want to terminate the web page.
## Reference
[https://blog.devgenius.io/how-javascript-works-behind-the-scenes-88c546173f32](https://blog.devgenius.io/how-javascript-works-behind-the-scenes-88c546173f32)

How JavaScript Works behind the scenes?

In the early stages of learning how to structure an HTML document, it’s not uncommon to end up with what some developers call “[div soup](https://www.pluralsight.com/blog/software-development/html5-web-components-overview).” Need a content section your homepage? Wrap in a div! Building a sidebar? Div it up! Three column layout? Div, div, div!

There isn’t anything *functionally* wrong with writing HTML this way. Browsers will still be able to render your markup and display your content to users. The primary issue with heavy use of `<div>` tags is that they lack semantic meaning. Writing [Semantic HTML](https://www.lifewire.com/why-use-semantic-html-3468271) gives your markup meaning to web browsers and screen readers, can help with SEO, makes it easier to debug code, and more.

According to the [W3C](http://w3c.github.io/html/grouping-content.html#the-div-element):

> “The div element has no special meaning at all…Authors are strongly encouraged to view the div element as an element of last resort, for when no other element is suitable. Use of more appropriate elements instead of the div element leads to better accessibility for readers and easier maintainability for authors.”
> 

Ok, so what are these “more appropriate elements” that the W3C mentions? When HTML5 was released in 2014, it introduced some new section and grouping elements that web developers could use to enhance the semantic meaning of their markup.

Let’s explore a few of the more semantic alternatives to the `<div>` tag.

# **The M`ain` Element**

The [main](http://html5doctor.com/element-index/#main-desc) element indicates to browsers and screen readers which portion of your markup contains the main section of content on a given page. This can help with keyboard command access, zooming on mobile browsers, and more. It should be used only once per page.

![https://miro.medium.com/max/2000/1*PtEKG5X1pqJOypOOuph5gw.png](https://miro.medium.com/max/2000/1*PtEKG5X1pqJOypOOuph5gw.png)

# **The S`ection` Element**

The [section](http://html5doctor.com/element-index/#section) element is used to group content by theme and represents a section of a document or application. Sections can have their own `header` and `footer` elements, and there can be multiple `section` elements used on a single page.

![https://miro.medium.com/max/2000/1*3B4HZ_z5DKtmxx3TJZrS_Q.png](https://miro.medium.com/max/2000/1*3B4HZ_z5DKtmxx3TJZrS_Q.png)

# **The Aside Element**

[aside](http://html5doctor.com/element-index/#aside) elements are mainly used to represent part of a page containing related content to a given section. Asides are typically used as sidebars.

![https://miro.medium.com/max/2000/1*qqIQLegbU9cmS2rIXbcIvQ.png](https://miro.medium.com/max/2000/1*qqIQLegbU9cmS2rIXbcIvQ.png)

# **The Article Element**

The [article](http://html5doctor.com/element-index/#article) element can be used for portions of content that could stand on their own. Blog posts, newspaper articles, and user comments are some possible use cases the the `article` element.

![https://miro.medium.com/max/2000/1*0AVaI9fKeDnPF_EqiOElyw.png](https://miro.medium.com/max/2000/1*0AVaI9fKeDnPF_EqiOElyw.png)

# **The Blockquote Element**

The [blockquote](http://html5doctor.com/element-index/#blockquote) element represents content that is being quoted from an external source (a person, document, newspaper, case study, etc.). It is often accompanied by the `cite` element to attribute the quote to its source.

![https://miro.medium.com/max/2000/1*QGmqFzasBXsKR6HghYiWoQ.png](https://miro.medium.com/max/2000/1*QGmqFzasBXsKR6HghYiWoQ.png)

# **The Nav Element**

As the name implies, [nav](http://html5doctor.com/element-index/#nav) elements represent the navigation section of a document. The `nav` element should include the primary navigation links for a give page, application, etc.

![https://miro.medium.com/max/2000/1*lowhket3yyahdQ3DPzoC6Q.png](https://miro.medium.com/max/2000/1*lowhket3yyahdQ3DPzoC6Q.png)

# **The Footer Element**

The [footer](http://html5doctor.com/element-index/#footer) element represents the “footer” section of a document or section. In many websites, the `footer` element will contain contact and copyright information, a brief “about” blurb, social media logos and links, etc.

![https://miro.medium.com/max/2000/1*2xCYjC2w-OxibGYtXrnpOw.png](https://miro.medium.com/max/2000/1*2xCYjC2w-OxibGYtXrnpOw.png)

Now that we know about some semantically optimized alternatives to the `div` element, how do we know when to use each of them? And when (if ever) is it ok to still use `div` elements in our markup? [HTML5 Doctor](http://html5doctor.com/) has a really handy flowchart to help answer that question:

![https://miro.medium.com/max/2000/1*1d6PpXylYNTGZtMU_q4_Vg.png](https://miro.medium.com/max/2000/1*1d6PpXylYNTGZtMU_q4_Vg.png)

## Reference
[https://medium.com/@zac_heisey/7-alternatives-to-the-div-html-tag-7c888c7b5036](https://medium.com/@zac_heisey/7-alternatives-to-the-div-html-tag-7c888c7b5036)

7 Alternatives to the <div> HTML Tag

Next.js is a framework created by [Vercel](https://vercel.com/). It is open-source based on [Node.js](https://www.ideamotive.co/node) and Babel and integrates with React for developing single-page apps. Here’s a list of things you might be able to do to improve the performance of your NextJS application.

# **1. SSR (server-side rendering)**

Modern JavaScript frameworks have made our lives as developers much easier. We can create powerful, rich web applications using many different rendering techniques.

You have probably heard of single-page applications before. A single-page application is an application that is rendered at the client-side, even if the data might be fetched from the server.

Server-side rendering (SSR) is the exact opposite of this. SSR describes the process of pre-rendering the page on the server, which is then generated upon each user request.

When the pre-rendered page reaches the browser, JavaScript code is run to make the page interactive. This whole process makes the load speed faster. It also makes it easier and preferable to use server-side rendering for applications that depend on SEO.

Next.js does this work out of the box. By default, it will try to detect which pre-rendering technique your application is using and fetch your data.

Years ago, before JavaScript became so mature and powerful, developers usually returned HTML files based on HTTP calls. It was a very common technique to process the response on the server-side using a server-side language (usually PHP) and returning a static HTML file.

# **2. SSG (static site generation)**

Static-generated websites are nothing new for developers. We have been building them since the beginning of the web. Building rich web experiences can be hard, but with Next.js we can do so easily.

Next.js has introduced us to a better way of building static-generated websites with more dynamic performance.

SSG describes the process of building websites that render at build time. The output is an HTML file, assets such as JavaScript and CSS, and a few other static files.

When using SSG with Next.js, the page is pre-rendered at compile time. That means that the user won’t have to wait for the page to load at the browser; the page will simply be rendered.

For data fetching, Next.js provides three different functions:

- `getStaticProps` : The page will be pre-rendered at build time
- `getServerSideProps`: The page will be pre-rendered at runtime
- `getStaticPaths` : This function generates a list of pages that will be pre-rendered at build time

The biggest disadvantage of using SSG is that the build time can get very long. You won’t have a problem when you have only a few statically-generated pages, but as your application grows, the build time will increase.

The worst-case scenario is when you have hundreds of statically-generated pages. The build time will take a long time, and if you have dynamic content on those pages, you can end up with too many builds.

# **3. The `<Image/>` component**

The `<Image/>` component was contrived by the creators of Next.js to solve the optimization issues the former lacks.It is a better and enhanced version of the `<img>` tag, but unlike the `<img>` tag, the `<Image/>` component is not a native HTML element – but a built-in API in Next.js.The component essentially wraps the `<img>` element with other div elements to prevent cumulative layout shift.

## **Benefits of using the component**

The `<Image/>` component’s API doesn’t just render images to the browser like the `<img>` tag, it also optimizes the image for every viewport by implementing each of the functionalities below out of the box:

- **Lazy loading**: Every image linked to a webpage with the `<Image/>` component is fetched and rendered on-demand as soon as its holding space is scrolled into view by default. So you never have to worry about slow load time in your web pages and writing extra scripts for such functionality.
- **Responsiveness**: Images are automatically responsive when rendered with the `<image/>` component, saving you from the stress of CSS media queries.
- **Resizing**: The appropriate size and aspect ratio of an image for a viewport is fetched and rendered on-demand, instead of fetching the intrinsic size and aspect ratio before reducing it for the target viewport.
- **Optimized file size**: The `<Image/>` component fetches the appropriate file size for each viewport, taking away the need to store images with different file sizes for every viewport on the server, and fetching them one after the other when needed.
- **Optimized image format**: when an image is fetched from the server with the `<Image/>` component, the file format is changed to a more optimized and SEO-friendly one like WebP, if the browser supports it.

# **4. Font Optimization**

**Automatic Webfont Optimization** is a feature that shipped with [Next.js 10.2](https://nextjs.org/blog/next-10-2#automatic-webfont-optimization).

## **How to use it?**

Add a `link` tag that loads the Google fonts CSS to Next.js’ built-in `Head` component.

```
import Head from 'next/head';export default function MyPage() {
  return (
    <div>
      <Head>
        <link
          href="https://fonts.googleapis.com/css2?family=Lobster"
          rel="stylesheet"
        />
      </Head>
      <p>Hello world!</p>
    </div>
  )
}
```

`Head` is a special component that enables us to append the HTML `<head>` element from our page components or from the custom `Document` component.

More info: [next/head](https://nextjs.org/docs/api-reference/next/head) | [next/document](https://nextjs.org/docs/advanced-features/custom-document)

## **How does it work?**

Our code above is compiled into this on build:

```
<head>
  
  <link rel="stylesheet" data-href="https://fonts.googleapis.com/css2?family=Lobster">
  
  <style data-href="https://fonts.googleapis.com/css2?family=Lobster">
    @font-face{font-family:'Lobster';font-style:normal;font-weight:400;src:url(https://fonts.gstatic.com/s/lobster/v23/neILzCirqoswsqX9zoKmM4MwWJU.woff2) format('woff2');unicode-range:U+0000-00FF,U+0131,U+0152-0153,U+02BB-02BC,U+02C6,U+02DA,U+02DC,U+2000-206F,U+2074,U+20AC,U+2122,U+2191,U+2193,U+2212,U+2215,U+FEFF,U+FFFD}
  </style>
</head>
```

Without optimization:

1. the `link` tag loads the Google fonts CSS, `[https://fonts.googleapis.com/css2?family=Lobster](https://fonts.googleapis.com/css2?family=Lobster)`
2. the CSS `@font-face` loads the actual font source, `[https://fonts.gstatic.com/s/lobster/v23/neILzCirqoswsqX9zoKmM4MwWJU.woff2](https://fonts.gstatic.com/s/lobster/v23/neILzCirqoswsqX9zoKmM4MwWJU.woff2)`

With optimization, we skip step (1). Notice that the `href` attribute is changed into `data-href`. Instead, the style declarations are inlined and injected to the `<head>`. The browser requests the font file(s) in step (2) directly.

# **5. Dynamic Import**

Unlike regular import modules, dynamic imports are flexible about when and how they are loaded. Instead of being forced to load the module file at reading time, dynamic imports can be requested at the time of use. By code splitting the module into a separate bundle file it can be fetched separately which reduces the initial page load.

**Building an Example**

Setting up dynamic imports in [Next.js](https://webdevstudios.com/2020/06/02/building-the-nextjs-9-4-wordpress-example/) can be done in a few lines of code that are demonstrated in the example below. For more advanced ways to use the dynamic function, make sure to check out the [Next.js Dynamic Imports](https://nextjs.org/docs/advanced-features/dynamic-import).

1. First, import the `dynamic` function using `import dynamic from "next/dynamic";`.
2. Next, create a new constant. Assign the `dynamic` function to reference your component. Ex:
3. `const GoodbyeDynamic = dynamic(() => import("../components/Goodbye"));`

Now the const can be used just like the original `Goodbye` component.

The following example demonstrates `Goodbye` component being dynamically imported. When the app is first rendered, the console statement from `<Hello />` is immediately invoked. Meanwhile, the console statement from `<Goodbye />` does not invoke until after the button is clicked which triggers the component to `<GoodbyeDynamic />` component to render.

```
import { useState } from “react”;
import Hello from “../components/Hello”;
import dynamic from “next/dynamic”;const GoodbyeDynamic = dynamic(() => import(“../components/Goodbye”));/**
 * Before toggling Hello check the console.
 * 1. Hello component file is immediately read.
 * 2. Goodbye component file is reader once it’s rendered.
 */
export default function IndexPage() {
 const [toggleGoodbye, setToggleGoodbye] = useState(false);
 return (
 <div>
 <button onClick={() => setToggleGoodbye(!toggleGoodbye)}>
 Toggle Hello Component
 </button>
 {toggleGoodbye ? <GoodbyeDynamic /> : <Hello />}
 </div>
 );
}
```

# **6. Script Optimization**

next/script was introduced with Next.js 11 release and it enables developers to set the loading priority of third-party scripts.

you can define the strategy property and Next.js will automatically prioritize them to improve loading performance:

```
<Script
  src="https://polyfill.io/v3/polyfill.min.js?features=Array.prototype.map"
  strategy="beforeInteractive" // lazyOnload, afterInteractive
/>
```

# **7. Next.js Analytics**

You can integrate your Next.js app with Vercel analytics to get more detailed information about your website’s speed.

First, you will need to create a [custom App](https://nextjs.org/docs/advanced-features/custom-app) component and define a `reportWebVitals` function:

```
// pages/_app.js
export function reportWebVitals(metric) {
  console.log(metric)
}function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />
}export default MyApp
```

This function is fired when the final values for any of the metrics have finished calculating on the page. You can use to log any of the results to the console or send them to a particular endpoint.

check the documentation on how to measure Next.js app performance [here](https://nextjs.org/docs/advanced-features/measuring-performance).

# **Conclusion**

Getting a score that is higher than 90 in Google’s PageSpeed is a broad topic with much ground to cover. In this article, I’ve only covered the tip of the iceberg about some of the rare practices you can adopt to get better performance results with Next.js.

## Reference

[https://alabenaicha.medium.com/7-next-js-tips-to-get-a-90-score-on-google-pagespeed-55130221cc7](https://alabenaicha.medium.com/7-next-js-tips-to-get-a-90-score-on-google-pagespeed-55130221cc7)

How JavaScript Works behind the scenes?

More Stories

7 Alternatives to the <div> HTML Tag

7 Next.JS Tips to get a 99% score on Google PageSpeed