
Inside a web browser, there exists a software component responsible for determining the content to show you based on the data it receives. This component is known as the browser engine.

The browser engine is a fundamental element present in all major web browsers, and various browser manufacturers give their engines distinct names. For instance, Firefox's browser engine is known as [Gecko](https://en.wikipedia.org/wiki/Gecko_(software)), while Chrome uses [Blink](https://en.wikipedia.org/wiki/Blink_(browser_engine)), a derivative of [WebKit](https://en.wikipedia.org/wiki/WebKit).

## From raw bytes of HTML to DOM

We are all familiar with the term **Document Object Model** or DOM, but it's always helpful to revisit how this crucial component is constructed: It starts with **bytes** of data that the browser reads from the HTML files, which are then transformed into readable **characters**.

But that bunch of text doesn't produce an actual website. Those characters are parsed into **tokens**, such as the start or end HTML tags, the content characters and so on. The browser then organizes those tokens into **nodes**, and assembles into the hierarchical structure known as the DOM.

> Check out this article for a more detailed understanding about this process: [How web browsers work - parsing the HTML (part 3, with illustrations)](https://dev.to/arikaturika/how-web-browsers-work-parsing-the-html-part-3-with-illustrations-45fi).

![](assets/from-markup-to-pixels-a-look-inside-the-dom-cssom-and-render-tree_html-parser.webp)

_Image Source: [How web browsers work - parsing the HTML (part 3, with illustrations)](https://dev.to/arikaturika/how-web-browsers-work-parsing-the-html-part-3-with-illustrations-45fi)_

## How about CSS?

As soon as the browser begins to parse the HTML, once encountering a `link` tag to a CSS file, it simultaneously makes a request to fetch that. As you may anticipate, the procedure mirrors the way browsers form the DOM (from bytes to the object model). This process forms a tree structure called the **CSS Object Model** (CSSOM).

> For further information, please check out this article: [How web browsers work - parsing the CSS (part 4, with illustrations)](https://dev.to/arikaturika/how-web-browsers-work-parsing-the-css-part-4-with-illustrations-4c).

![](assets/from-markup-to-pixels-a-look-inside-the-dom-cssom-and-render-tree_cssom.webp)

_Image Source: [How web browsers work - parsing the CSS (part 4, with illustrations)](https://dev.to/arikaturika/how-web-browsers-work-parsing-the-css-part-4-with-illustrations-4c)_

As you can see in the example above, the elements have both inherited styles from the parent (depicted in white), and their own styles that overwrite the inherited ones (depicted in black). And since we can have several CSS files linked to our HTML, that's when the [Specificity](https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity) comes in handy for the browser in determining which style to apply to a particular node.

## Combining the DOM with the CSSOM

The browser traverses every visible node starting from the root of the DOM tree. Certain nodes are ignored by default (such as script or meta tags), while for others, the browser seeks the relevant rules within the CSSOM and proceeds to paint them on the screen. The browser will also ignores the nodes that are hidden due to their CSS property (`display: none` for example).

Now the Render Tree holds the information of the **visibility** of each node and its **styles**, but what needs to be done next to calculate the exact position of those elements and paint them to the screen?

![](assets/from-markup-to-pixels-a-look-inside-the-dom-cssom-and-render-tree_render-tree.webp)

_Image Source: [How web browsers work - the render tree (part 7, with illustrations)](https://dev.to/arikaturika/how-web-browsers-work-the-render-tree-part-7-with-illustrations-24h3)_

## The layout/reflow stage

The **Layout**/**Reflow** is a process to find the **geometry** of elements. The main thread walks through the DOM and constructs a layout tree that stores details such as **x and y coordinates**, as well as **bounding box dimensions**.

![](assets/from-markup-to-pixels-a-look-inside-the-dom-cssom-and-render-tree_layout-tree.webp)

_Image Source: [Inside look at modern web browser (part 3)](https://developer.chrome.com/blog/inside-browser-part3/)_

This process happens every time we change something in the DOM that affects the layout, which may include:

- Adding or deleting elements from the DOM
- Resizing the browser window
- Changing the width, the position of an element or floating it

## The painting stage

Despite having a DOM, style information, and a layout, these elements alone do not suffice for rendering a web page. Once the browser determines which nodes should be visible and calculates their positions within the viewport, the next step is to actually draw (render) them. Similar to the layout phase, the painting process doesn't occur just once but repeatedly whenever there are changes to the appearance of on-screen elements.

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

## Compositing

**Compositing** is a method used to divide different elements of a webpage into distinct layers, independently rendering each layer, and then combining them to form a complete page in a separate thread known as the compositor thread. When scrolling occurs, this approach becomes efficient because the layers are already rendered, requiring only the composition of a new frame. Similarly, animation can be achieved by repositioning these layers and composing a new frame, enabling smooth and responsive animations.

To determine which elements should be placed within specific layers, the main thread goes through the layout tree to generate the **Layer tree**.

> Learn more about the **Layers panel** of DevTools [here](https://blog.logrocket.com/eliminate-content-repaints-with-the-new-layers-panel-in-chrome-e2c306d4d752/).

![](assets/from-markup-to-pixels-a-look-inside-the-dom-cssom-and-render-tree_layer-tree.webp)

_Image Source: [Inside look at modern web browser (part 3)](https://developer.chrome.com/blog/inside-browser-part3/)_

Once the Layer tree is established and the orders of rendering are determined, the main thread transfers that information to the compositor thread. The compositor thread then begins the process of rendering each layer. Some layers, such as those having the entire length of a webpage, can be quite extensive. To handle this, the compositor thread breaks them down into smaller sections known as **tiles** and dispatches each tile to **raster threads**. These raster threads are responsible for rendering each tile and storing the results in the memory of the GPU.

![](assets/from-markup-to-pixels-a-look-inside-the-dom-cssom-and-render-tree_compositing.webp)

_Image Source: [Inside look at modern web browser (part 3)](https://developer.chrome.com/blog/inside-browser-part3/)_

## Reference

- https://developer.chrome.com/blog/inside-browser-part3/
- https://blog.logrocket.com/how-browser-rendering-works-behind-scenes/
- https://dev.to/arikaturika/series/17842
- https://twitter.com/alexxubyte/status/1534201516063461376


A deep dive into the rendering process of a web page, exploring the Document Object Model (DOM), CSS Object Model (CSSOM), and the Render Tree.

From markup to pixels - a look inside the DOM, CSSOM, and render tree


## Why?

With the rise of social platforms like Facebook, Twitter and LinkedIn, it's easier than ever to share URLs with a large audience quickly and efficiently. However, each social network has its own unique way of handling URLs, and understanding the correct formatting can make a significant difference in the visibility and engagement of your shared content.

## Facebook

```javascript
`https://www.facebook.com/sharer.php?u=${url}`;
```

This format allows you to share a specific URL with your [Facebook](https://about.meta.com/technologies/facebook-app/) friends and followers. By replacing `url` with the actual URL, you can create a link that shows a dialog with the content you want to share.

![](assets/url-formats-for-sharing-via-social-networks_hmijfth.webp)

## Messenger

Sharing via [Messenger](https://about.meta.com/technologies/messenger/) is another way to share a URL with your Facebook friends and contacts.

```javascript
`https://www.facebook.com/dialog/send?app_id=${appId}&display=popup&link=${url}&redirect_uri=${url}`;
```

To use this format, you'll need to replace `${appId}` with your Facebook app ID and `${url}` with the URL you want to share.

> Follow this [documentation](https://developers.facebook.com/docs/development/create-an-app) to create a Facebook app and get the app ID.

![](assets/url-formats-for-sharing-via-social-networks_yrq15em.webp)

## Zalo

To share a URL via [Zalo](https://zalo.me/pc), a widely used messaging app in Vietnam, you need to create a JSON object containing a key of `"url"` and the value of the URL you want to share. Then stringify and encode the string in the base64 format.

```javascript
function encodeB64(str: string) {
  return window.btoa(str)
}

const sharingUrl = `https://button-share.zalo.me/share_external?d=${encodeB64(JSON.stringify({ url }))}`
```

![](assets/url-formats-for-sharing-via-social-networks_5gtifrk.webp)

## Other platforms

Check out some other formats that allow you to share a URL via some social networks.

| Platform | URL format                                                              |
| -------- | ----------------------------------------------------------------------- |
| LinkedIn | <pre>`https://www.linkedin.com/sharing/share-offsite/?url=${url}`</pre> |
| Twitter  | <pre>`http://twitter.com/share?url=${url}`</pre>                        |
| Telegram | <pre>`https://telegram.me/share/?url=${url}`</pre>                      |
| Reddit   | <pre>`https://www.reddit.com/submit?url=${url}&title=${title}`</pre>    |


Each social network has its own unique way of handling URLs, and understanding the correct formatting can make a significant difference in the visibility and engagement of your shared content.

URL formats for sharing via social networks


## Infinite scroll - benefits and challenges

Infinite scroll has become a popular web design technique in recent years, as it offers several benefits over traditional pagination models such as reducing page load times or minimizing the need for users to browse through multiple pages. However, it can also present some painful challenges for accessibility and usability. One of the most common issues happens when you are scrolling the list, then click on an item to view its detail (and of course, is navigated to another page). When going back to the list, you lose your previous scroll position and have to scroll all the way to find the item you clicked on before.

![](assets/retain-scroll-position-in-infinite-scroll_infinite_scrolling.webp)

_Image Source: [https://www.explainxkcd.com](https://www.explainxkcd.com/wiki/index.php/1309:_Infinite_Scrolling)_

## Solution

In this article, we will show you an approach using the session storage to store the scroll position, with the infinite scroll implemented using [`useSWRInfinite`](https://swr.vercel.app/docs/pagination.en-US#useswrinfinite).

```javascript
export const LIST_STATES_KEY = 'infinite-scroll-list-states'

export default function createRetainPositionStore<
	T extends SWRInfiniteResponse<any, any>,
>(storeKey = LIST_STATES_KEY) {
	function useRetainPosition({ swr }: { swr: T }) {
		// ...
	}

	function handleSaveStates({ swr }: { swr: T }) {
		// ...
	}

	return { useRetainPosition, handleSaveStates }
}
```

Let's begin by creating a `createRetainPositionStore` that takes in a key that we will use to store and retrieve data from the session storage.

We will also implement two functions inside, one to handle the behaviors before routing happens, and another one for those when we go back to the page and want to retain the scroll position. Both of them accept the parameter of `swr` which is the [response](https://swr.vercel.app/docs/pagination.en-US#return-values) of the `useSWRInfinite()`.

```javascript
function handleSaveStates({ swr }: { swr: T }) {
  sessionStorage.setItem(storeKey, JSON.stringify({ swrSize: swr.size, scrollPosition: window.scrollY }))
}
```

The function above simply stores an object with `swrSize` and `scrollPosition` to the session storage. When a user clicks on an item and is navigated to the detail page, we call this function along with the routing function to store the vertical scroll position (`scrollPosition`) and also the number of pages (or a group of several consecutive items) that infinite scroll already loaded (`swrSize`).

```javascript
function useRetainPosition({ swr }: { swr: T }) {
  const documentHeight = document?.documentElement.scrollHeight || 0
  const listStates = JSON.parse(sessionStorage.getItem(storeKey) || '{}')

  useEffect(() => {
    if (typeof listStates.scrollPosition !== 'number') {
      return undefined
    }

    if (documentHeight > listStates.scrollPosition) {
      window.scrollTo(0, listStates.scrollPosition)
      sessionStorage.removeItem(storeKey)
    }
  }, [documentHeight, listStates.scrollPosition])

  useEffect(() => {
    if (typeof listStates.swrSize !== 'number') {
      return undefined
    }

    if (listStates.swrSize > 1) {
      swr.setSize(listStates.swrSize)
    }
  }, [listStates.swrSize, swr])
}
```

The hook `useRetainPosition` is called in the listing page that uses the infinite scroll technique, so that everytime we visit the page, the two `useEffect`s help us to retrieve the data from the session storage. The `scrollPosition` is used for scrolling the page to the previous position. The `swrSize`, on the other hand, is passed to the `setSize` function to tell `swr` how many pages already loaded before we were navigated to the item detail page.

This makes sense since as mentioned above, when user clicks on an item and is navigated to the detail page, we will store those data to the session storage, and when user wants to go back to the listing page, `useRetainPosition` can retrieve those data and the page will be scrolled to the previous position. After calling `window.scrollTo(0, listStates.scrollPosition)`, don't forget to remove the relating data from the session storage to prevent unwanted scrolling behaviors of the page in the future.

## Reference

- https://www.explainxkcd.com/wiki/index.php/1309:_Infinite_Scrolling


Infinite scroll has become a popular web design technique in recent years, as it offers several benefits over traditional pagination models. However, it can also present some painful challenges for accessibility and usability.

Retain scroll position in infinite scroll


## Overview & when to use IndexedDB

**IndexedDB** is a low-level API for client-side storage like [_localStorage_](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage) and [_cookies_](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies). But this built-in **non-relational database** is much more powerful than those 2 counterparts.

If you want to build a traditional client-server app with a moderate amount of data needed to store in the client side (browser), simply use localStorage or cookies for their ease of implementation and usage. IndexedDB is intended for **offline** apps, when you want to store and retrieve some data even without connection to the Internet. An example might be a to-do list or saved games that are played locally. In this case, the user data is in local side, and the web site is just the vehicle for delivering it.

Beside that, IndexedDB has some important characteristics and much more powerful supplementations:

- Stores almost any kind of key-value pairs, including **complex objects**
- It is mostly **asynchronous**
- Can store **significant volumes** of structured data, much bigger than localStorage
- Supports **transactions** for reliability
- Does not use Structured Query Language (SQL)

Like most web storage solutions, IndexedDB follows a [same-origin policy](https://www.w3.org/Security/wiki/Same_Origin_Policy) i.e. while you can access stored data within a domain, you cannot access data across different domains.

## Important terminologies

### Database

Database in IndexedDB contains the object stores, which in turn contain the data you would like to persist. You can create multiple databases with the following must-have information:

- Name: identifies the database and must stay constant
- Current version: with default value of 1

```javascript
const openRequest = indexedDB.open('shelf' /* name */, 1 /* version */)
...
openRequest.onsuccess = () => {
	const db = openRequest.result
	...
}
```

> [Read more](https://developer.mozilla.org/en-US/docs/Web/API/IDBDatabase) about methods, attributes and how to use **IDBDatabase**.

### Object store

Object store is an individual bucket to store data. It is the **core concept** of IndexedDB. You can think of object stores as being similar to tables in traditional relational databases. A database may have multiple stores and each of them must have a name that is **unique** within its database.

```javascript
db.createObjectStore("books" /* name */, { keyPath: "id" });
```

> [Read more](https://developer.mozilla.org/en-US/docs/Web/API/IDBObjectStore) about **IDBObjectStore**, an interface of IndexDB API that represents object stores.

### Transaction

An atomic set of _data-access_ and _data-modification_ operations on a particular database, they should either **all succeed** or **all fail**. It is how you interact with the data in a database. **Any reading or changing of data in the database must happen in a transaction**.

A database connection can have several active transactions associated with it at a time, so long as the writing transactions do not have overlapping scopes. The scope of transactions gives us information of during the transaction, which object stores are involved (and are expected to be modified) and which of them remain.

```javascript
const trans = db.transaction("books" /* store */, "readwrite" /* type */)

// start operating on this store
const objStore = trans.objectStore("books")

const book = {
	id: 'Remote - Office not required',
	price: 10,
}

const request = objStore.add(book /* value */) // operations must happen in a transaction

request.onsuccess = () => {
	...
}
```

> [Read more](https://developer.mozilla.org/en-US/docs/Web/API/IDBTransaction) about **IDBTransaction**, an interface of the IndexedDB API that provides a static, asynchronous transaction on a database.

### Index

An **index** is a specialized object store for looking up records in another object store (often called the *referenced object store*). The **index** is a key-value storage where all its values are the keys of the referenced object store. Hence all its records are automatically populated when a new record is inserted, updated or deleted.

> [Read more](https://developer.mozilla.org/en-US/docs/Web/API/IDBIndex) about **IDBIndex** interface of the IndexedDB API.

**Searching by a field using an index**:

```javascript
...
openRequest.onupgradeneeded = () => {
	const books = db.createObjectStore('books', {keyPath: 'id'})
	const index = books.createIndex('price_idx', 'price')
}
```

Search the `books` object store by `price` key

### Cursor

With a huge object store, bigger than the available memory, `getAll` might fail to get all records as an array. Cursors provide the means to work around that.

**A cursor is a special object that traverses the object storage using a given query, and returns one key/value at a time, thus saving memory**.

```javascript
const request = store.openCursor("id" /* query */, [
  "next" /* or 'prev', 'nextunique'... */,
]);

// to get keys only, you can use 'openKeyCursor' instead of 'openCursor'
```

> [Read more](https://developer.mozilla.org/en-US/docs/Web/API/IDBCursor) about **IDBCursor**, an interface of IndexedDB API that represents a cursor.

## Limitation

IndexedDB is designed to cover most cases that need client-side storage. However, it is not designed for a few cases like the following:

- Not all languages sort strings in the same way, so internationalized sorting is not supported
- The API is not designed for synchronizing with a server-side database
- It does not have an equivalent of the `LIKE` operator in SQL for full text searching

Moreover, errors that are **out of developers' control** can happen for a variety of reasons. For example, some browsers like **Firefox** or **Edge** currently don't allow writing to IndexedDB when in private browsing mode. There's also the possibility that a user is on a device that's almost out of disk space, and the browser might not allow storing anything else at all.

Using IndexedDB is also likely to require **a lot more coding** than localStorage or cookies. But if the values you’re storing are complex JavaScript objects that would be difficult to serialize, or if you need a transactional model, then it may be worthwhile.

> Detailed information about Limitations of IndexedDB from MDN site [[here](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Basic_Terminology#limitations)]

## Reference

- https://javascript.info/indexeddb
- https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB
- https://www.javascripttutorial.net/web-apis/javascript-indexeddb/
- https://web.dev/indexeddb/


IndexedDB is a low-level API for client-side storage like localStorage and cookies. But this built-in non-relational database is much more powerful than those 2 counterparts.

Intro to IndexedDB


Since modern websites and applications contain huge amounts of dynamic content and complex components with no semantics to describe what they mean, users with disabilities, those dependent on **assistive technologies** such as **[Screen Reader](https://chrome.google.com/webstore/detail/screen-reader/kgejglhpjiefppelpmljglcjbhoiplfn/related?hl=en)**, text-to-speech or screen magnification tools might suffer to interact with those components.

Web Accessibility Initiative’s Accessible Rich Internet Applications or simply **WAI-ARIA** is a technology that can help with such problems.

## What is WAI-ARIA?

Before semantic elements like `<nav>` or `<footer>` were introduced that define specific features of a web page, some developers would rely on JavaScript libraries that generate a bunch of **nested `<div>`s**, then styled them with CSS and controlled with JavaScript.

The website still works fine and behaves normally. The problem comes when the site is used by a user dependent on assistive technologies, tools that help users with disabilities interact with websites (by speaking the content or information out loud, zoom into the content at the cursor position etc.). If those tools cannot make any sense of what the components are since no semantics were provided, they cannot assist their users. WAI-ARIA provides 3 main features: **Roles**, **States** and **Properties** to solve this problem, giving an opportunity to add attributes to content and components that make them **meaningful** and enhance **accessibility**.

### Roles:

WAI-ARIA roles define **what that HTML is or does**, add the required additional information in cases the markup does not provide the required role. If we write `<a role="button">`, the screen reader will recognize it as a button. You can also use roles to describe sections on a web page such as `navigation`, `main` or `banners` etc.

> Detailed documentation about **WAI-ARIA Roles** from MDN [[here](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles)]

```javascript
<ul role="menu">
  <li role="menuitem" aria-selected="true" tabindex="0">
    Home
  </li>
  <li role="menuitem" aria-selected="false" tabindex="0">
    About
  </li>
  ...
</ul>
```

We can have `button`s, `tab`s,... representing widget roles working as part of larger components, or `heading`, `row`, `rowgroup`,... describing content structure in a page.

### Properties:

Represent the **data value associated** with the object. When combined with roles, the user agent can supply the assistive technologies with user interface information to convey to the user at any time. Properties are **less** likely to change. `aria-label`, `aria-required` and `aria-describedby` are some instances for WAI-ARIA properties.

> Detailed documentation about **WAI-ARIA States & Properties** from MDN [[here](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes)]

```javascript
<form>
	<label for="name">Enter your name:</label>
	<input type="text" name="name" aria-label="Name input" aria-required="true" placeholder="Your name">

	<label for="age">Enter your age:</label>
	<input type="number" name="age" aria-label="Age input" aria-required="true" placeholder="Your age">

	<input type="submit">
</form>
```

### States:

Have the same characteristics as properties, except for one thing that states are frequently changed during the life cycle of the component. Some commonly used WAI-ARIA states are `aria-pressed`, `aria-expanded`, `aria-selected`,...

```javascript
<ul role="tablist">
  <li class="active" role="tab" aria-selected="true" tabindex="0">
    Tab 1
  </li>
  <li role="tab" aria-selected="false" tabindex="0">
    Tab 2
  </li>
  <li role="tab" aria-selected="false" tabindex="0">
    Tab 3
  </li>
</ul>
```

Below is a small demonstration, you can add this [Screen Reader extension](https://chrome.google.com/webstore/detail/screen-reader/kgejglhpjiefppelpmljglcjbhoiplfn/related?hl=en) and interact with it to know how WAI-ARIA helps enhance accessibility before reading further about benefits of using it:

<iframe height="400" style="width: 100%;" scrolling="no" title="WAI-ARIA" src="https://codepen.io/nguyend-nam/embed/XWqZPPE?default-tab=result" frameborder="no" allowfullscreen="true"></iframe>

## Why use WAI-ARIA?

Note that WAI-ARIA attributes **do not** change the behavior of the supplied component, they do not affect anything about the web page. The difference is that the [browser's accessibility APIs](https://wiki.mozilla.org/Accessibility/WebAccessibilityAPI) will expose that information and the assistive technologies can rely on that information to enhance users' accessibility.

WAI-ARIA will become handy in some cases as listed below:

- WAI-ARIA roles are useful when defining specific **regions on a web page** (e.g. banner, navigation, main,...). ![](assets/wai-aria_r1s3rbm.webp)

- `aria-live` can inform screen reader users when a component is **dynamically updated**.
<iframe height="400" style="width: 100%;" scrolling="no" title="WAI-ARIA" src="https://codepen.io/nguyend-nam/embed/WNJKEvy?default-tab=result" frameborder="no" allowfullscreen="true"></iframe>

- Strong support **keyboard users**: some HTML elements already have built-in keyboard accessibility (e.g. `<buttons>`, `<inputs>`,... where users can navigate to using tab key), but some need JavaScript along with to do that. WAI-ARIA provides `tabindex` attribute to allow focusing on those elements.
- **Improve accessibility** of non-semantic components: as modern web pages are getting more and more complex, UI components might have a bunch of nested `<div>`s inside. WAI-ARIA helps cover that with roles (e.g. button, tablist), it also improves functionality (e.g. `aria-required`).

## Reference

- https://developer.mozilla.org/en-US/docs/Learn/Accessibility/WAI-ARIA_basics
- https://www.maxability.co.in/trainings/advanced-web-accessibility-testing/what-is-wai-aria
- https://www.w3.org/WAI/ARIA/apg/example-index/button/button
- https://pressbooks.library.torontomu.ca/wafd/chapter/wai-aria-landmarks/#:~:text=WAI%2DARIA%20landmarks%20are%20used,bypass%20links%20and%20page%20headings


WAI-ARIA is a technology that can help with the problems of modern websites and applications containing huge amounts of dynamic content and complex components with no semantics to describe what they mean.

WAI-ARIA


**ThreeJS** is a JavaScript 3D library that allows developers to develop and describe data in 3 dimensions, and then convert them into 2 dimensions and display them on [HTML Canvas](https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement). [**Camera**](https://threejs.org/docs/index.html?q=camera#api/en/cameras/Camera) is one of the core elements of a ThreeJS project, beside [Scene](https://threejs.org/docs/index.html?q=scene#api/en/scenes/Scene), [Renderer](https://threejs.org/docs/index.html?q=renderer#api/en/renderers/WebGLRenderer) and 3D objects (can be formed with [Geometries](https://threejs.org/docs/index.html?q=geometry#api/en/geometries/BoxGeometry) and [Materials](https://threejs.org/docs/index.html?q=material#api/en/materials/MeshBasicMaterial)).

This article gives basic information about characteristics of the frequently used types of camera in ThreeJS.

## Most commonly used types of camera in ThreeJS

You cannot use the `Camera` class directly to initialize a new camera in ThreeJS. Instead, use the `PerspectiveCamera` or `OrthographicCamera` specifically. The **perspective camera** gives information about depth, distances, etc. since it represents perspective in **real life**. On the other hand, with an **orthographic camera**, all sizes are projected the same way and we can easily compare them accurately.

The image below shows the object viewed in **perspective camera** (upper) and in **orthographic camera** (lower).

![](assets/cameras-in-threejs_va74b4e.webp)

Place them into the **Oxyz** coordinate...

![](assets/cameras-in-threejs_uioctax.webp)

### Perspective camera

![](assets/cameras-in-threejs_oipfgw7.webp)

Some crucial attributes:

- **fov** (field of view): Camera frustum **vertical** field of view, i.e. the angle of the view in the yOz plane, in degree. The lower the number, the narrower the view. ![](assets/cameras-in-threejs_zkoiiim.webp)
- **near** and **far**: Clipping planes at 2 points on the z axis. Note that objects with z position outside the `(near, far)` interval will **not** be displayed.

```javascript
const camera = new THREE.PerspectiveCamera(45, 16 / 9, 1, 1000);
scene.add(camera);
```

In the example above, a perspective camera is initialized with `fov` of 45 degree, `aspect-ratio` of 16 / 9, `near` and `far` of 1 and 1000 respectively.

Perspective camera visualization from [r105.threejsfundamentals.org](https://r105.threejsfundamentals.org/threejs/threejs-cameras-perspective-2-scenes.html) with [`CameraHelper`](https://threejs.org/docs/index.html?q=camera#api/en/helpers/CameraHelper):

<iframe height="400" style="width: 100%;" scrolling="no" title="ThreeJS - Cameras - Perspective 2 views" src="https://codepen.io/nguyend-nam/embed/abGmYBp?default-tab=result" frameborder="no" allowfullscreen="true"></iframe>

### Orthographic camera

![](assets/cameras-in-threejs_cx1u9zi.webp)

Some crucial attributes:

- **left**, **right**, **top** and **bottom**: Horizontal and vertical position of 4 segments of the view.
- **near** and **far**: Same as for perspective camera.

```javascript
const camera = new THREE.OrthographicCamera(-2, 2, 1, -1, 1, 1000);
scene.add(camera);
```

In the example above, an orthographic camera is initialized with `left`, `right`, `top` and `bottom` equal -2, 2, 1 and -1 respectively. The last 2 numbers represent `near` and `far`.

Orthographic camera visualization from [r105.threejsfundamentals.org](https://r105.threejsfundamentals.org/threejs/threejs-cameras-orthographic-2-scenes.html) with [`CameraHelper`](https://threejs.org/docs/index.html?q=camera#api/en/helpers/CameraHelper):

<iframe height="400" style="width: 100%;" scrolling="no" title="ThreeJS - Cameras - Orthographic 2 views" src="https://codepen.io/nguyend-nam/embed/BaxLrWv?default-tab=result" frameborder="no" allowfullscreen="true"></iframe>

## Other types of camera

Beside those 2 most frequently used cameras, ThreeJS also provides various options:

- [ArrayCamera](https://threejs.org/docs/index.html?q=camera#api/en/cameras/ArrayCamera)
- [CubeCamera](https://threejs.org/docs/index.html?q=camera#api/en/cameras/CubeCamera)
- [StereoCamera](https://threejs.org/docs/index.html?q=camera#api/en/cameras/StereoCamera)

## Reference

- https://threejs.org/docs/index.html?q=camera#api/en/cameras/Camera
- https://r105.threejsfundamentals.org/threejs/lessons/threejs-cameras.html
- https://www.vectorstock.com/royalty-free-vector/isometric-and-perspective-drawings-vector-7297379
- https://wiki.freecadweb.org/index.php?title=File:Orthographic_Perspective.gif
- https://www.celestron.com/blogs/knowledgebase/what-is-the-field-of-view-of-a-pair-of-binoculars


**ThreeJS** is a JavaScript 3D library that allows developers to develop and describe data in 3 dimensions, and then convert them into 2 dimensions and display them on [HTML Canvas](https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement). [**Camera**](https://threejs.org/docs/index.html?q=camera#api/en/cameras/Camera) is one of the core elements of a ThreeJS project, beside [Scene](https://threejs.org/docs/index.html?q=scene#api/en/scenes/Scene), [Renderer](https://threejs.org/docs/index.html?q=renderer#api/en/renderers/WebGLRenderer) and 3D objects (can be formed with [Geometries](https://threejs.org/docs/index.html?q=geometry#api/en/geometries/BoxGeometry) and [Materials](https://threejs.org/docs/index.html?q=material#api/en/materials/MeshBasicMaterial)).