Generative AI (GenAI) can write impressive essays, produce original images, and perform useful, time-saving analysis of huge datasets. With new capabilities appearing seemingly every day, everyone is wondering what they could accomplish with GenAI.

But for AI tools to be useful to your team, they have to fit into your existing workflows. When AI tools aren’t properly integrated, they interrupt rather than enhance the flow state. Constant context-switching is costly, and AI tools should make such interruptions less, rather than more, frequent.

In this article, we’ll cover some best practices for integrating AI tools into your technical workflows, from identifying the right tools and training your team to monitoring and optimizing the tools’ performance over time.

## Identifying the right tools

It’s important to clarify your goals in using new AI tools. It’s tempting, but trying every product you can get your hands on creates too much noise and introduces unnecessary risk. Think about the needs of your team and the challenges your organization is facing. Assess your criteria for speed, size, security, and privacy. Do you want a chatbot that can make recommendations based on a set of criteria, or a search engine that will respond with relevant data when your team has complex questions about an upcoming project?

Not every organization has the same needs, of course, but in general terms, a GenAI system integration involves connecting the model to the relevant data or documentation, deciding what information you’ll use to train the model, and determining what data it will have access to when it’s generating answers to user queries.

GenAI systems hinge on a technology called [vector embedding](https://stackoverflow.blog/2023/07/31/ask-like-a-human-implementing-semantic-search-on-stack-overflow/). To integrate AI tools into your business, you’ll need to use an embedding model and store the results in a vector database. There are lots of [embedding models](https://stackoverflow.blog/2023/09/20/do-you-need-a-specialized-vector-database-to-implement-vector-search-well/) to choose from, some from private companies and others open-source. You’ll probably want to start with free, open-source options if you’re prototyping something internally. You can always scale up to enterprise-grade solutions once you settle on the ideal approach.

For your database, there are purpose-built options from companies that are entirely focused on vector databases, as well as options from providers you might already work with. If your company already has a large account with a firm like MongoDB, for example, it might make sense to utilize their [recently released vector database offering](https://www.mongodb.com/products/platform/atlas-vector-search), as it can sit alongside and integrate with your existing database. If you’re starting from scratch, you might want to look at providers like [Pinecone](https://www.pinecone.io/) and [Weaviate](https://weaviate.io/), which are focused on this specific niche and bring a wealth of knowledge and support to customers trying to create their first LLM-powered apps.

Want to rely on an external partner to handle the heavy lifting? Companies like OpenAI have done the work of creating a foundational model with its own embedding and vector database. You can use their Completions API to send your user queries to their system and feed their responses back. Just remember that there are tradeoffs around speed, security, privacy, and cost to consider when relying entirely on a third party.

## Training the team

In order for your team to take full advantage of whatever GenAI tools you end up introducing into your workflow, proper training is critical. That means training the AI itself on high-quality data that is complete, correct, and up-to-date, so you get [accurate, reliable answers](https://stackoverflow.blog/2023/07/06/why-knowledge-management-is-foundational-to-ai-success/).

It also means training your human team to ask the right questions and refine those queries, providing them with comprehensive documentation, and [capturing and preserving their knowledge](https://stackoverflow.blog/2022/02/10/foster-a-continuous-learning-culture-with-stack-overflow-for-teams/) for the benefit of future users. This is where a healthy [knowledge management (KM)](https://resources.stackoverflow.co/topic/thought-leadership/craft-a-knowledge-management-strategy/) strategy becomes critical.

## Integrating AI into your technical workflows

Gradually introducing GenAI tools into your technical teams’ daily workflows will be more effective in terms of adoption than suddenly forcing everyone to use a bunch of new tools instead of the ones they’re familiar with. Similarly, starting with small-scale or low-stakes tasks is a good way to demonstrate proof of concept and get people on board.

Allowing users to interact with the AI via chat or email can lower the barrier to adoption by incorporating GenAI into a tool users already have at their fingertips. At Stack Overflow, for example, we’re planning a [Slack integration](https://stackoverflow.co/labs/slack/) that will allow employees to engage with the AI without even opening a new window, much less shifting to an unfamiliar platform.

Another great way to integrate AI is through pre-trained text embeddings like the [Universal Sentence Decoder](https://tfhub.dev/google/collections/universal-sentence-encoder/1), which “encode text into high-dimensional vectors that can be used for text classification, semantic similarity, clustering and other natural language tasks.” It takes just a few lines of Python to package your data for use by a GenAI-powered chatbot. Or go even further with this [tutorial](https://daleonai.com/semantic-ml) for prototyping a language-powered app using Google Sheets and an add-on called [Semantic Reactor](https://research.google.com/semanticexperiences/semantic-reactor.html).

## Monitoring and adjusting AI tools in the workplace

GenAI doesn’t offer set-it-and-forget-it tools, at least not yet. Assessing and optimizing the effectiveness of AI tools requires continuous monitoring, feedback, and adjustment based on performance metrics.

One thing to consider is that once you’ve spent time and money training an AI model, getting your embedding into a vector database, and deploying it, it can be difficult to update that database without re-running the training cycle. We touched on this during a conversation with Louis Brandy, VP of Engineering at Rockset, for [our podcast](https://stackoverflow.blog/2023/08/25/fighting-comment-spam-at-facebook-scale-ep-602/).

## Knowledge in, knowledge out

Most technologists are eager to understand how to integrate AI tools into their workflows, but there are some best practices to bear in mind going in. Knowledge management tools can ensure that the data your AI is trained on is complete, accurate, and up-to-date: in fact, the right knowledge management strategy is [foundational to success with AI tools](https://stackoverflow.blog/2023/07/06/why-knowledge-management-is-foundational-to-ai-success/).

For AI tools to be useful to your team, they have to fit into your existing workflows

Integrating AI tools into various coding and non-coding workflows

You might have heard the term “Jamstack” as you’ve built sites in recent years. Jamstack is about building web applications in the same style as mobile applications: the UI is compiled, and then data is pulled in as needed. [Here’s a diagram from Twitter that I found particularly useful in understanding the concept](https://twitter.com/VeryThorough/status/1352299261463994368?s=20). In the Jamstack, you build applications upfront as much as possible at deploy time (called pre-rendering), rather than at runtime (called server-side rendering).

Right now, there are a lot of opinions out there about how to improve and scale sites “beyond the Jamstack” by adding in features that use a Node server in addition to the pre-built pages. One of those features is called Incremental Static Regeneration.

Some people call it **“hybrid web development”** (or “hybrid serverless + static”) but let’s talk a bit more about what that means.

## What happens when you deploy a Jamstack project {#What-happens-when-you-deploy-a-Jamstack-project}

First of all, we should talk about what happens when you build Jamstack sites, and how atomic and immutable deploys work. These are fundamental principles to understand for this style of web development.

**Atomic deployment** means all of the code, assets, and configuration of a site are updated together at the same time. This means that a website cannot be served in a partially updated state.

**Immutable deployment** insulates deploys from future actions, guaranteeing their integrity. This means there is always a stable copy of this deploy that can be referenced or re-deployed at any state in the future.

> [Read more about these terms in the Jamstack glossary](https://jamstack.org/glossary/).

Think of this as state-driven development. Every single deploy is a new state of your application or site.

![Atomic deploys, the latest deploy is the live deploy](https://lh4.googleusercontent.com/PqTH5Ov7geTnfNy8kAzrlclcoPguVl2NoNoYrntNY7ay9bnscBSkqdtiV2CehKdcHXmTBLDZVqVchhVzSADcSlJx_8GwU-8UWzsj6frMWlGOpTCc0fsDad8bTOO7YGK6-oHtqVX2 'Atomic deploys, the latest deploy is the live deploy')

If you were to make a mistake on your site, let’s say you broke prod, you deployed the wrong brand colors, or you mixed up some copy, you can instantly rollback to a previous deploy without having to wait for a new build, because that old version of your site exists in space. It’s the same concept as reverting a commit in Git, and it works just as smoothly.

![Instant rollbacks mean you can choose any built deploy to go live at any time](https://lh4.googleusercontent.com/u73M4IZ4iUQa-jiaFbgwpqes0kAhhBjgBZV5GopUZdcrFGI0B8lK-wGc1CjqNSgtIoPrKZHyP68LmbO2KR8ukrIdT-9tVThlNMpozXwfgYUToYl-uqHBvzex8n7n25wO6yoxC-6o 'Instant rollbacks mean you can choose any built deploy to go live at any time')

I won’t get into the details of the perks of pre-rendering all of your pages, but if you’d like to read more about that, you can check out more information on [Jamstack.org](https://jamstack.org/what-is-jamstack/).

## Incremental Static Regeneration {#Incremental-Static-Regeneration}

Incremental Static Regeneration, or ISR, seeks to extend the power of static sites by adding some server-side rendering (SSR) goodies on top with the power of a Node server.

### How it works and why it is cool {#How-it-works-and-why-it-is-cool}

When you deploy a site with ISR enabled, you deploy a (mostly) static site. You have your pre-defined static pages that were built, and you have routes on your application that aren’t built until your users hit those pages.

Typically when you have a server-side rendered (SSR) page that is one of these unbuilt pages, your users have to wait for the page to be built and served all at once. But in the case of ISR, if your users hit that route, they get a _fallback page_. A fallback page is a placeholder for the actual content that will be on that page, and you can have skeleton components in place until data is built and loaded. Once that data has been resolved, that page is cached, added to the rest of the site’s bundle, and the next user of your page will see the built page. If the data needs to update, the user will see that cached version instead of the fallback, and the site can set a _revalidate timeline_ so that it can revalidate and update data regularly when your users hit the page.

![Incremental static regeneration adds new pages to the latest deploy and caches them separately](https://lh6.googleusercontent.com/ZVG0Ml7P3pL1B14X3TNA1BOfi-z3s1pk2mwHZBN2jfXYvQWGzS4pmMUg3Dxt9xhpIj8eqLIuBg9nYJAX4oJKQwrXEBLZ1ts5hhj9tvuQqWMOvC_hTQhw0eNUp6w-9tr4oSDwgoUF 'Incremental static regeneration adds new pages to the latest deploy and caches them separately')

Each of the new blocks in this diagram is a new page that is built at runtime and added to the “stack.”

This method of serving pages is using the [stale-while-revalidate caching strategy](https://web.dev/stale-while-revalidate/). It’s pretty dang performant, because you can (nearly) get the performance benefits of a pure static page, with the power of new dynamic data like you would in SSR. That’s why this strategy is very often called “hybrid” development, because it combines the best of both worlds!

### Why it is not great {#Why-it-is-not-great}

There’s a few flaws in ISR that you might want to consider before going all-in on the concept.

When you have a user come to your page, you want them to see the most up-to-date version, immediately. With ISR, the first visitor to a page will not see that. They will always see a fallback first. And then later, if the data gets stale, the first visitor to see that cached page will see the out-of-date data first before it revalidates. Once again, this inconsistent experience can be pretty difficult to debug if your users experience negative side-effects as a result of old/unbuilt pages.

![Pages can get stale, but they'll stay deployed](https://lh4.googleusercontent.com/Kvh-y_pW5uwmMntpwjDDnepjtlqGo4lGbldfWP3UIZm1B_KwFIXjdth1IMLSTdGKDJJFAIagI8pB7EehWQTWV-om99uXqshpJEur1ml3N_eB1KFvmtkCATwyCCYGpkkBn2UtqhsV "Pages can get stale, but they'll stay deployed")

Remember the whole section up there of atomic and immutable deployment? ISR, unfortunately, breaks that model. By adding extra pages to your bundle, rollbacks can no longer be instant, and you no longer have that single new version of your site when you update your content.

Let’s say you build a site that has a bunch of products for sale, and each of those products are on ISRed pages. In an ideal scenario, your users can navigate to a products’ page, see a product for sale, and buy it. The next users who go to the page will see it, and the page might update to show that the product is out of stock.

If you rollback your site to a different deploy, because your page is cached separately from the bundle, it could exist in a different state for your user than expected. It could be the old version of the site, the new version, or some funky in-between cached version trying to revalidate itself. And unfortunately, debugging this is difficult, because different users (and the dev team!) would see different pages, and it might be difficult to duplicate.

![ISR means that you can rollback, but the stale/separately cached pages will stay live](https://lh6.googleusercontent.com/LI9vFD2R6uxvsFe2GXLbJiwzufv_5Y-56CouIeVT6cuZVLd4bGJLuKm2Tw-DnpAy6XFjx2wHtR_J0yFRrfPN2cUJKqXIkJvqOE_Ny9TZ0pmqcjaQPxIFyUKSH3_2jqaPsZbq5GCr 'ISR means that you can rollback, but the stale/separately cached pages will stay live')

Notice how in this graphic, the pages that are cached separately stick around with their nice big checkmarks, while the rolled-back page is no longer the shipped deploy. If the users navigate to those cached routes, they might see out-of-date data.

The stale-while-revalidate caching that powers ISR is the reason for these gotchas. When ISR is based on serving stale content like this, we end up with a pretty big footgun that ultimately is confusing for users and frustrating for developers.

## What should I do for my projects? {#What-should-I-do-for-my-projects?}

✨ It Depends ✨

Pros:  
– Faster build times  
– Performant pages taking advantage of a Node server as well as a cached static model

Cons:  
– Inconsistent pages per user (breaking atomic and immutable deploys)  
– Difficult to debug due to stale-while-revalidate caching

Clearly there are benefits to ISR, but it does come with caveats! Weigh the pros and the cons and decide for yourself if it’s right for you.

There are a lot of opinions out there about how to improve and scale sites “beyond the Jamstack” by adding in features that use a Node server in addition to the pre-built pages. One of those features is called Incremental Static Regeneration. Some people call it “hybrid web development” (or “hybrid serverless + static”) but let’s talk a bit more about what that means.

Incremental Static Regeneration: Building static sites a little at a time

Events are detectable actions or occurrences commonly used in programs to trigger functions. These actions include a user clicking a button and a webpage loading.

This article will cover how event capturing and bubbling work in React. Before we go over what event capturing and bubbling are, we’ll learn about event delegation and how it works. We will also look at the [SyntheticEvent in React, how it works, and its connection to event capturing and bubbling in React](https://reactjs.org/docs/events.html).

## Understanding event delegation in React {#Understanding-event-delegation-in-React}

Event delegation is a technique for handling events that involves adding a single event listener to a parent element rather than adding event listeners to individual child elements. When an event occurs on a child element, the event listener on the parent element is notified, and the parent element can handle the event. This is useful when you have many child elements and want to avoid adding event listeners to them.

> [Here is a deep dive into event bubbling and capturing](https://blog.logrocket.com/deep-dive-into-event-bubbling-and-capturing/).

Imagine a scenario in which you have the following code :

```javascript
function App() {
	const parentFunction = () => {
		console.log('Hello from the parent');
	};
	const firstChildFunction = () => {
		console.log('Hello from the first child');
	};
	const secondChildFunction = () => {
		console.log('Hello from the second child');
	};
	const thirdChildFunction = () => {
		console.log('Hello from the third child');
	};
	return (
		<div className='App'>
			<div
				className='parent-div'
				onClick={parentFunction}
			>
				<button
					className='first-child-button'
					onClick={firstChildFunction}
				>
					First child button
				</button>
				<button
					className='second-child-button'
					onClick={secondChildFunction}
				>
					Second child button
				</button>
				<button
					className='third-child-button'
					onClick={thirdChildFunction}
				>
					Third child button
				</button>
			</div>
		</div>
	);
}
export default App;
```

In the code above, we have a parent `div` with an `onClick` handler attached to it. The parent `div` houses three children `buttons` with `onClick` handlers attached to them. The `onClick` handles all the `PointTo` functions that print text to the console.

When we click any of the buttons and check the console, we get the log for the button, which is the second button. However, we also get another log that shows that the parent `div` was clicked, as shown in the image below:

![React Child Component](https://blog.logrocket.com/wp-content/uploads/2023/02/react-child-component.png)

We know that event delegation took place because the parent element also handles the event of the children element. With that out of the way, let’s look at the order in which React handles the event.

## Intro to event propagation {#Intro-to-event-propagation}

Event propagation is the order in which event handlers are called when an event occurs on a webpage. To understand how event propagation works, it helps to know about the [three phases of event flow in the DOM](https://blog.logrocket.com/react-reference-guide-refs-dom/) : the capturing phase, the target phase, and the bubbling phase.

In the capturing phase, the event propagates from the top of the document down to the element on which the event occurred. Capturing is less commonly used than bubbling. Simply put, this is otherwise known as an event moving downwards from the top of the document to the element on which the said event occurred.

In the target phase, the event handler is executed on the element on which the event occurred and can be assessed via `event.target`.

In the bubbling phase, the event moves back up the DOM tree from the element where the event occurred to its parent element, and so on, until it reaches the top of the document. This is the default behavior for most events in the DOM. This is the reverse of the capturing phase.

The image below describes the three phases of event propagation and how it works:

![React Event Propagation Diagram](https://blog.logrocket.com/wp-content/uploads/2023/02/event-capturing-react.png)

> Note : There is a fourth phase of event propagation known as the `none` phase, where no event is executed.

## What is the SyntheticEvent? {#What-is-the-SyntheticEvent?}

React relies on a virtual DOM and uses this concept to handle DOM operations. The `SyntheticEvent` wrapper wraps around the native DOM event that React uses to abstract the differences between the events the browser can handle. This allows you to write [event handlers that work consistently across all browsers](https://blog.logrocket.com/creating-hover-events-synthetic-event-react-hover/).

For example, consider the following code that attaches a click `EventListener` to a `button`:

```javascript
document.getElementById('myButton').addEventListener('click', () => {
	console.log('Button was clicked');
});
```

In the code above, the `click` event is a native DOM event. In React, you would write that event like so:

```javascript
<button onClick={() => console.log('Button was clicked')}>Click me</button>
```

The `onClick` event in this example is a synthetic event. React will call the event handler function you provided when the button is clicked. Internally, React will convert the synthetic event into a native DOM event and pass it to the event listener.

React creates `SyntheticEvents` to allow you to write your event handlers in a way familiar to you without worrying about the differences between the various events the browser can handle. `SyntheticEvents` also include methods such as `stopPropagation` and `preventDefault`, which are instrumental to React’s Event System.

## Using event.stopPropagation method in React {#Using-event.stopPropagation-method-in-React}

We have looked at event propagation, its phases, and how they work. However, there are occasions when you don’t want an event to bubble. This is where the `event.stopPropagation()` method comes in.

In React, the `event.stopPropagation()` method prevents an event from being handled by the parent component if a child component handles it. You can call `event.stopPropagation()` on the event object to stop the event from propagating further up the tree. This is useful in cases where the parent component has an event handler that conflicts with the event handler of the child component.

Let’s see an example of a use case where you would want to use `event.stopPropagation()` to avoid conflict between the parent and child components. In the code below, we have a `header` component that has a `button` for logging out:

```javascript
import './App.css';
function App() {
	const handleHeaderClick = () => {
		console.log('Header was clicked');
	};
	const handleButtonClick = () => {
		console.log('The logout button was clicked');
	};
	return (
		<>
			<div
				className='styleHeader'
				onClick={handleHeaderClick}
			>
				<div>Header</div>
				<button
					type='button'
					onClick={handleButtonClick}
				>
					Log Out
				</button>
			</div>
		</>
	);
}
export default App;
```

The code block above will display the `header` component as shown in the image below:

![Example of React Header Logged](https://blog.logrocket.com/wp-content/uploads/2023/02/react-header-log.png)

In such cases, we don’t want the event handled by the parent component. At this point, if you click the **logout button**, the parent still handles the event as shown below:

![React Event Clicked](https://blog.logrocket.com/wp-content/uploads/2023/02/log-out-react.png)

We can stop the parent component from handling the event by passing the `event.stopPropagation()` to the child component — the button — as shown below:

```javascript
import './App.css';
function App() {
	const handleHeaderClick = () => {
		console.log('Header was clicked');
	};
	const handleButtonClick = (event) => {
		event.stopPropagation();
		console.log('The logout button was clicked');
	};
}
export default App;
```

We first passed the `event` object as a parameter to the `handleButtonClick` function and then used `event.stopPropagation()` to stop the event from bubbling into the parent component. Now, if we click the **button**, no bubbling occurs, and we only get the log for the button component. It should look like this:

![React Event Capture Example](https://blog.logrocket.com/wp-content/uploads/2023/02/log-out-two-react.png)

## Event delegation in React v16 vs v17 {#Event-delegation-in-React-v16-vs-v17}

In React v16 and earlier, event delegation was handled by attaching event handlers at the Document node per event. This meant React would figure out which component was called during an event and bubble that event to the Document node where React had attached event handlers.

There were [issues](https://github.com/facebook/react/pull/8117) with this method because of the nested [React trees](https://blog.logrocket.com/comparing-react-tree-components/). If you have nested React trees in your application, the `event.stopPropagation()` method will not work as intended. Let’s look at an example below:

```javascript
// Nested React trees in the index.html
<div id='parent'>
	<div id='root'></div>
</div>
```

Paste the following code into the `App.js` file:

```javascript
import './styles.css';
import React from 'react';

export default function App() {
	const handleButtonClick = () => {
		console.log('The button was clicked');
	};
	return (
		<div className='App'>
			<button onClick={handleButtonClick}>Click me</button>
		</div>
	);
}
```

In the code block above, we have a `button` with an `onClick` handler that points to a function that logs some text to the console when clicked.

In the `index.js` file, paste the code below into it:

```javascript
import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';

const parent = document.getElementById('parent');
parent.addEventListener('click', (e) => {
	console.log('The parent was clicked');
	e.stopPropagation();
});

ReactDOM.render(<App />, document.getElementById('root'));
```

In the code block above, we got the `parent` element from the DOM and attached an `EventListener` to it. The `EventListener` listened for a `click` event and logged a different text to the console. Then, we called the `event.stopPropagation()` method in the following line.

We expect to get two different text strings when we click the button. But, instead, we get one, and it’s not even the one that we are expecting, as shown in the image below:

![Example of React Bubbling Tree](https://blog.logrocket.com/wp-content/uploads/2023/02/react-bubbling-tree.png)

This happens because when you have nested React trees, React will still bubble events to the outer tree even after `event.stopPropagation()` has been called.

### Changes to the DOM tree {#Changes-to-the-DOM-tree}

In React v17 and later, the developers of React changed how it attaches events to the DOM tree. The event handlers are now attached to the root DOM container that renders your React tree and is no longer attached to the Document node. Here’s a visualization of those changes:

![A Diagram Showing How React v17 Attaches Events to the Roots Rather Than to the Document](https://blog.logrocket.com/wp-content/uploads/2023/02/react-tree-changes.png)  
If we change the `index.js` file to reflect React v17 changes, we get the appropriate logs in the console, as shown below:

```javascript
import { createRoot } from 'react-dom/client';
import App from './App';

const parent = document.getElementById('parent');
parent.addEventListener('click', (e) => {
	console.log('The parent was clicked');
	e.stopPropagation();
});

const rootElement = document.getElementById('root');
const root = createRoot(rootElement);
root.render(<App />);
```

Now, when we click the **button**, we get the logs, as shown in the image below:

![React Event Capturing and Bubbling](https://blog.logrocket.com/wp-content/uploads/2023/02/react-event-capture-bubble-final.png)

## Conclusion {#Conclusion}

This article looked at how events are handled in React. We looked at event delegation, propagation, bubbling, capturing, and `SyntheticEvents` in React. In addition, we looked at the `event.stopPropagation()` method, and how we can use it to stop event propagation. We also looked at how events were handled in previous versions of React and how events are handled in the current versions of React.

This article explores what Synthetic Events are and how they works in tandem to event bubbling and event capture and how we can prevent such bubbling using stopPropagation method.

Event bubbling and capturing in React

In recent years, web application development has undergone a radical transformation due to the [rise of React based meta framework `Next.js`](https://stackoverflow.blog/2020/10/07/qa-with-the-creators-of-next-js-on-version-9-5/). This framework allows developers to build powerful web apps with JavaScript without worrying about building the back-end infrastructure. It simplifies the process of creating hybrid applications with client-side as well as server-side rendered pages. While the framework is simple, developers still struggle to increase the speed of their applications.

An application’s speed is strongly related to the amount of time it takes to serve the application code, styles, and data to the client in the first round trip. When the server needs to send additional assets (for example images) during the initial round trip, the application performance degrades. Fortunately, developers can follow a number of best practices to improve the speed of their Next.js applications.

## Use server side rendering {#Use-server-side-rendering}

Server-side rendering (SSR) is a technique used to render the initial HTML of a webpage on the server before delivering it to the browser. Using server-side rendering will help your app reduce the time required to render the first page on the client side, so the user will see the content of your page much faster. SSR will also improve application performance, especially on mobile devices.

Next.js provides an async function named `getServerSideProps` that we can use to render any page on the server and return static HTML to the client. You can do your data-fetching work inside this function.`getServerSideProps` function takes a context object as a parameter that contains page data such as `params`, `res`, `req`, `query`, etc. This function will be called by the server on every request, returning an object that will be passed to the page component as a prop. In other words, this function allows you to fetch your data from the API and return the fetched data to the page component as a prop.

**Example :**

```javascript
// This function will be called by the server
export async function getServerSideProps({ context }) {
	// Fetch data from external API
	const data = await fetch(`YOUR_API`);

	// Returning the fetched data
	return { props: { data } };
}

function SSRPage({ data }) {
	// Displaying the data to the client
	return <div>{data}</div>;
}

export default SSRPage;
```

In the above example, whenever the user visits the SSR page, the `getServerSideProps()` function will be called by the server and will return the fully rendered static page.

## Use dynamic imports {#Use-dynamic-imports}

Traditionally, applications load all the components and the CSS required by the application in the initial load. Dynamic import allows you to split your code into small chunks and load them on demand. In the context of web applications, this means that you can import specific components on an as-needed basis. If a user never interacts with a particular component, that component will never be loaded. This can be a huge performance boost, especially on mobile devices. This will also reduce the initial load time and the overall bundle size of the application.

For example, if the user hasn’t logged in, you can lazy load the login component. To use dynamic import, you just need to import the code using an ES2020 dynamic import.

```jsx
import dynamic from 'next/dynamic'
 
const DynamicHeader = dynamic(() => import('../components/header'), {
  loading: () => <p>Loading...</p>,
})
 
export default function Home() {
  return <DynamicHeader />
}
```

In the above code, we are using the dynamic component provided by the framework to load our Header component dynamically. You can pass a component name, an array of module names, and a function inside the component that will be invoked when the module is loaded.

## Cache frequently used content {#Cache-frequently-used-content}

Caching improves response times and reduces bandwidth usage by serving content from a cache instead of the original source. Next.js has built-in caching so pages load faster. To implement caching in your Next.js application, you can manually set the headers on any API routes that retrieve content and server-side rendered props to use `Cache-Control`. Below is the implementation for built-in caching.

**For API routes :**

```javascript
export default function handler(req, res) {
	res.setHeader('Cache-Control', 's-maxage=10');
}
```

**For server-side rendering :**

```javascript
export async function getServerSideProps({ req, res }) {
  res.setHeader(
    'Cache-Control',
    'public, s-maxage=10, stale-while-revalidate=59'
  );
  return {
    props: {}
  };
}
```

For static files and assets, you don’t have to manually add caching; Next.js automatically adds them.

## Remove unused dependencies {#Remove-unused-dependencies}

Many applications depend on third-party packages. While dependencies are definitely good for your app, they increase its size and loading time. If you are using npm packages in your Next.js application, you should watch for unused dependencies. They take up space in your final bundle and might cause unexpected behaviors in your application.

If you have a small project, you can easily find the unused dependencies and remove them from the `package.json` file of your Next.js app. But if you have a large project with lots of different dependencies, it may be difficult to find the unused dependencies. In this case, use the [`depcheck` package to find unused dependencies in the project](https://www.npmjs.com/package/depcheck) (this package is included with npm).

I recommend that you remove dependencies one by one and restart your application after each removal to ensure that the dependency was truly not needed and that you didn’t break your application.

## Optimize images {#Optimize-images}

Image optimization involves reducing the size of an image file. Because images are one of the biggest assets weighing down your app’s performance, reducing the size of image files can improve performance. This is a two-step process: 1) resize the image to a smaller size and 2) save it in the correct format (jpeg is better for photos; png is better for graphics).

Next.js provides an inbuilt `next/image` component that we can use in place of the native `<img>` component.

```javascript
import Image from 'next/image';

export default function OptimizedImage() {
  return (
    <>
      <h1>Next.js Image</h1>
      <Image
        src={image_url}
        alt='Any Text'
        width={500}
        height={500}
        blurDataURL='URL'
        placeholder='blur'
      />
    </>
  );
}
```

Now let’s look at the benefits of the `next/image` component.

**Lazy loading :**

Lazy loading is the process of loading a particular chunk of an app only when it is visible in the client viewport. By default, the `next/image` component lazy loads images, which will decrease the loading time. If you don’t want to lazy load an image, set `priority={true}` to turn it off.

**Placeholder images :**

Using the `next/image` component, you can add a blurred placeholder for any image using the `placeholder` prop.

**Preload images :**

If you have multiple images in a page, you can prioritize loading using the `next/image` component.

## Optimize your scripts {#Optimize-your-scripts}

In addition to npm dependencies, many applications use third-party scripts like Google Analytics, Google AdSense, and Bootstrap. These scripts can further slow your Next.js app. Instead of using the default `<script>` tag, you can use the `next/script` component of Next.js. It allows you to set the loading priority for third-party scripts.

**For example :**

```javascript
import Script from 'next/script';

export default function OptimizedScript() {
  return (
    <>
      <Script
        id='YOUR_ID'
        src='URL'
        onError={(err) => {
        	console.error('Error', err);
        }}
        onLoad={() => {
        	// Function to perform after loading the script
        }}
      />
    </>
  );
}
```

By setting the value of the `strategy` prop in the `next/script` component, you can use three different script loading approaches:

- **`afterInteractive`:** The script will be loaded on the client side after the page becomes interactive.
- **`beforeInteractive`:** The script will be loaded on the server side before self-bundled JavaScript is executed.
- **`lazyOnload`:** The script will be loaded after all other resources are loaded.

After applying one of these strategies, check the speed and performance of your app using web performance tools like Google pagespeed. A web performance tool can provide valuable information about application performance, such as:

- The time it takes to get the initial page.
- The time it takes to get the initial resources.
- The number of round trips transmitted.
- The amount of data transferred each trip.

## Start building faster Next.js applications {#Start-building-faster-Next.js-applications}

Next.js has become popular because it allows developers to build powerful JavaScript apps without having to build the back-end infrastructure, but it’s also full of features that can help you improve application performance while doing much of the heavy lifting on the server. Following these best practices will help you take advantage of those features so you can start building faster Next.js applications.

Next.js is a powerful yet simple framework, though developers still struggle to increase the speed of their applications. Here's how you can make those apps faster.

Best practices to increase the speed for Next.js apps

Every time JavaScript goes through a major update, we seem to repeat the same cycle. At first, developers are delighted by the new features. They move back to coding directly in JavaScript, and frameworks become less popular. Then, in the relatively long periods between releases, frameworks begin to offer new features and tempt developers back. Repeat.

With ES6—arguably the biggest change to the language yet—the same cycle could repeat again. Frameworks aren’t nearly as popular as they were when ES6 first came out, while JavaScript is going strong. However, I want to argue for a more radical prediction: As developers get more and more familiar with what ES6 can do, we will finally break this cycle. The JavaScript developers of the future won’t use frameworks. At all.

![https://insights.stackoverflow.com/trends?tags=jquery%2Cangular%2Creactjs%2Cjavascript%2Cexpress%2Cvue.js](https://149351115.v2.pressablecdn.com/wp-content/uploads/2021/11/image.png)

I know that’s going to be an unpopular conclusion, but hear me out. I’m not saying that JavaScript will see its use narrow—in fact, plenty of companies are hiring JavaScript developers right now. Rather, I think two of the key features of ES6 (modules and classes, specifically) will make many of the most popular frameworks obsolete. In other words, JavaScript frameworks will die in the same way, and for the same reasons, [that Flash player died because there was simply no need for it anymore](https://stackoverflow.blog/2017/08/01/flash-dead-technologies-might-next/) and the inherent security vulnerabilities) made it dangerous to use.

> [Know more about the security vulnerabilities in the Flash player](https://www.securecoding.com/blog/most-common-security-vulnerabilities-using-javascript/)

So before you get defensive about your favorite framework, let me explain why I think this shift will occur.

## The problem with JavaScript frameworks {#The-problem-with-JavaScript-frameworks}

JavaScript frameworks exist as a tool for developers to abstract away some of the more complex aspects of developing front-end applications. And while frameworks have undeniably been very useful tools, advances in JavaScript’s web component specs have made developing new front-end applications (such as single-page applications) without existing frameworks much easier. This has raised the question of whether frameworks are still even necessary.

Let’s take a look at the most popular JavaScript frameworks today and examine where they fall down. You don’t have to look far for this, because most of the frameworks in use today suffer from a number of fundamental flaws.

Most of us who work with [some of the leading JavaScript frameworks](https://hackr.io/blog/best-javascript-frameworks) (and yes, I’m among that group) don’t notice those flaws, of course, because we are so used to them. It’s been a devil’s bargain: we appreciated the ease of development that the abstractions gave us, but overlooked the messy JavaScript that they produced. But the simple fact is that most of the frameworks we use are bloated libraries that manage complex processes that JavaScript was not designed for or shortcuts that make debugging code harder.

In addition to these issues, there is another, more important problem: there is actually no good definition of what constitutes a JavaScript framework in the first place. This has led to a somewhat absurd situation in which one of the most popular JavaScript “frameworks”—React—isn’t really a framework at all (no wonder it’s still popular). At best, it’s a library that developers use to build their own, highly-specialized JavaScript frameworks.

All of these issues are manifest in the most popular frameworks being used today. But there are also a number of specific issues that affect individual frameworks. So let’s take a quick look at each in turn.

### AngularJS and Angular {#AngularJS-and-Angular}

The fact that AngularJS has to appear on this list at all is indicative of one of the issues with JavaScript frameworks—that while they will become obsolete, people won’t necessarily stop using them. Plenty of developers, in fact, will tell you that [AngularJS is still “the best” way to code JavaScript](https://thinkmobiles.com/blog/why-use-angularjs/), even though the framework is (a) deprecated and (b) difficult to understand for anyone who hasn’t spent years using it.

This second issue—of code that is almost impossible to understand—was actually carried over into Angular 2. And while some see this as [a reason why back-end developers can earn more](https://stackoverflow.com/jobs/salary?_ga=2.260529931.761822388.1636990617-940169366.1584736921), in reality it can make life miserable for developers. Take, as an example, the fact that Angular 2 contains instances of case-sensitive HTML, which not only violates the principles of HTML itself, but also forces many to implement an interstitial parser just to clean up the HTML that Angular 2 produces.

### React {#React}

The other big JavaScript “framework” i.e. React suffers from a different set of problems. In fact, in retrospect it’s possible to see the development of React as a kind of reaction (pun intended) to the obscurity of Angular. React promises users that it is easy to use and doesn’t need to be any more complicated than you make it.

That’s true, up to a point. The problem is that React is not really an integrated framework, but rather a set of modules and components that often don’t play well together. Doing anything halfway complicated with React, such as [implementing browser fingerprinting](https://privacyaustralia.net/browser-fingerprinting/), means building a complex stack of components that you then have to constantly maintain and manage.

Some will argue with me here by pointing out that systems like Redux and Flux allow complex React stacks to be used even by beginners. I would counter that if you need to use a framework to work with your framework to work with JavaScript, then you are really in trouble. But React isn’t really a framework, so making a comparison isn’t quite fair.

### Ember and Vue and Aurelia {#Ember-and-Vue-and-Aurelia}

Finally, a quick note about some less well-known, and less well-used, frameworks. Most developers don’t have much exposure to any of these three frameworks, for the simple reason that they are not very widely used outside of their own niche applications.

Each of these three frameworks has its own idiosyncrasies, but the main problem with them is linked directly to their niche use cases. None of these frameworks has reached the market share necessary to build a true relationship with the wider JavaScript community (though according to Stack Overflow question statistics, Vue is about as popular as jQuery currently). As a result, developers who love these frameworks are often fighting an uphill battle when it comes to arguing for their use.

It’s also worth a quick note here about why none of these frameworks has gained popularity, especially because in many ways they are the most “fully featured” of the systems on this list. Ember, for instance, is probably the most “frameworky” of the frameworks on this list, but it suffers from performance issues, the largest download size, the largest API footprint, and the steepest learning curve of any of the frameworks on this list.

Think about that for a moment, and you may come to a strange conclusion—that many developers think we need a framework to work with JavaScript, but that when a full framework is actually available, we prefer to use ad-hoc solutions like React. Given that, [perhaps we should reassess whether, we even need front-end frameworks at all?](https://stackoverflow.blog/2020/02/03/is-it-time-for-a-front-end-framework/).

## The promise of ES6 {#The-promise-of-ES6}

This is the context, then, in which ES6 was released. ES6—also called ECMAScript2015—is the most recent version of JavaScript. It changed some of the fundamental ways we use the language. It introduced a number of new features that the community had been calling for for years.

At first glance, the claim that ES6 will make JavaScript frameworks obsolete seems pretty absurd, because [the changes made in ES6 were (at least according to some authors) little more than syntactical tweaks](https://www.freecodecamp.org/news/write-less-do-more-with-javascript-es6-5fd4a8e50ee2/). Seeing the additions that were made as syntactical, however, misses the point.

That’s because most of the “extra functionality” that frameworks provide could be seen in the same way—a method of providing quick shortcuts to features of JavaScript via syntactic changes. Some of these syntactic shortcuts have become so familiar to us that we have come to see them as separate features, but they are nonetheless merely ways of automating existing elements of JavaScript.

That’s not to understate the utility of syntactic innovation. In fact, the majority of the new features in ES6 are essentially syntactic shortcuts. These include:

- Default parameters
- Template literals
- Multi-line strings
- Destructuring assignment
- Enhanced object literals
- Arrow functions

But the reason why these features help make frameworks more obsolete is because they bring functionality that has so far been limited to frameworks right into the core of JavaScript itself. This subsequently reduces the need for frameworks in most situations. More functions—including promises and block-scoped constructs—standardize things we were all using frameworks to do in an ad-hoc fashion. Developers who were previously working in different frameworks can now talk to each other for the first time in years.

It’s two other new features of ES6, however, that will really spell the end of frameworks or at least pause [the brutal lifecycle of JavaScript frameworks](https://stackoverflow.blog/2018/01/11/brutal-lifecycle-javascript-frameworks/). These are the novel ways in which ES6 implements classes and functions.

### Classes {#Classes}

Plenty of developers [now use OOP as standard](https://stackoverflow.blog/2020/09/02/if-everyone-hates-it-why-is-oop-still-so-widely-spread/), and so have been implementing objects in JavaScript for years. Up until now, we’ve been using both frameworks and our own home-brewed solutions, because working with classes in ES5 was a total pain. That always struck me as strange, because it was clear from the outset that ES5 was designed to support classes—in fact, the keyword `CLASS` was reserved.

What this led to was arguments. Everyone turned to their favorite framework and used it to create an OOP interface. These were generally difficult to work with for anyone other than their creators, and they did not play nicely together.

Now, finally, with ES6, we have a standardized way of working with classes. ES6 classes use prototypes, not the function factory approach, where if we have a class `baseModel`, we can define a constructor and a `getName()` method.

### Modules {#Modules}

The situation was pretty much the same when it came to modules. In fact, some developers are still surprised to learn that by default there was no native modules support in ES5. It’s just that we got so used to workarounds—implemented via AMD, RequireJS, CommonJS, and others—that we forgot that what we were doing wasn’t really a part of JavaScript.

Now, with ES6, we can all use simple commands—`import` and `export`—to work with modules. Or at least some of us can, some of the time. Because, to slightly undermine my own argument right here at the end, this is perhaps the first place in which people are going to turn to frameworks again.

That’s because the way modules have been brought to ES6 is really pretty confusing. They don’t mirror the way modules are used in Node.js, and plenty of people are going to stick to that method.

## The bottom line {#The-bottom-line}

In short, ES6 brought a host of syntactic changes to JavaScript that greatly reduce the need for most frameworks. Coupled with the fact that most of the frameworks we are using at the moment obscure JavaScript code and add an additional dependency, we could see a tangible and permanent reduction in the use of frameworks over the next few years.

Or perhaps the cycle will simply repeat, and we’ll have only a few years of learning [how to write better JavaScript](https://stackoverflow.blog/2019/09/12/practical-ways-to-write-better-javascript/) before we retreat into our frameworks again.

Is ES6 the JavaScript release that will finally free us from the endless cycle of frameworks? Let us explore some of the new found powers of EcmaScript 2015.

Does ES6 make JavaScript frameworks obsolete?

React is [the most popular front-end framework](https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-web-frameworks) in the JavaScript ecosystem. It is famous for its ease of use and its readability, allowing companies and startups to adopt it. But classes can be unwieldy and hard to understand. Hooks allow you to use state, lifecycle methods, and other functionalities of React without using classes.

This article will explain what hooks are, what makes them unique, and why they are the best thing to happen to React.

## The origin of React hooks {#The-origin-of-React-hooks}

Originally, React mainly used class components, which can be strenuous at times as you always had to switch between classes, higher-order components, and render props. With React hooks, you can now do all these without switching, using functional components. Hooks make React so much better because you have simpler code that implements similar functionalities faster and more effectively. You can also implement React state and lifecycle methods without writing classes.

Below are code examples to illustrate React class and functional components.

```javascript
import React, { Component } from 'react';

export default class Hello extends Component {
	render() {
		return <div>Hello World!</div>;
	}
}
```

The code above is a class component that prints “Hello World” in the DOM.

```javascript
import React from 'react';

export default function Hello() {
	return <div>Hello World!</div>;
}
```

The code above is a functional component that prints “Hello World” on the DOM.

Comparing both sets of code above, the functional component has significantly simpler code that performs the same function; there’s no need to allocate space to a class instance, then call a `render()` function, you just call the function. React hooks have so many benefits and functions they perform, but one of the big ones is to make the React lifecycle methods easier.

> NOTE : You cannot use React hooks on class components.

## How have hooks made the React lifecycle easier {#How-have-hooks-made-the-React-lifecycle-easier}

The various lifecycle methods in React include mounting, updating, and unmounting.

- Mounting inserts elements into the DOM.
- Updating as the name implies, updates elements in the DOM.
- Unmounting removes elements from the DOM.

Below is an illustration of the various React lifecycle methods:

![A graph that shows how mounting, updating, and unmounting work in the render, pre-commit, and commit phases. ](https://lh4.googleusercontent.com/JoTzwb0XqJdldu-C6uvm-eYaurTFrQ7YsMQz-ZXhLVwLh_OPseD8CkBfxEIXL3Ij5B525ZXj7t9uKQPvRb8FO9Ha0nzw8_Uc-_EaU7XlSRQCnEWL2IeQBg4EOlSRIATB9TZpwjsH=s1600)

[Learn more about React Lifecycle Methods](https://stackoverflow.com/questions/29873730/react-lifecycle-methods-understanding)

Initially, you could only use these lifecycle methods with class components, which usually comprise a lot of carefully engineered code that is more difficult to write or understand than when you use hooks to implement them as functional components.

Take, for instance, if you try to fetch user data using a `componentDidMount()` in a class component like in the code below:

```javascript
import React, { Component } from 'react';
import Axios from 'axios';

export default class Hello extends Component {
	constructor(props) {
		super(props);
		this.state = { name: '' };
	}

	componentDidMount() {
		Axios.get('/api/user/name').then((response) => {
			this.setState({ name: response.data.name });
		});
	}

	render() {
		return <div>My name is {this.state.name}</div>;
	}
}
```

Now let’s compare it to doing the same thing with a functional component by using the `useState` and `useEffect` hooks in the code below:

```javascript
import React, { useEffect, useState } from 'react';
import Axios from 'axios';

export default function Hello() {
	const [Name, setName] = useState('');

	useEffect(() => {
		Axios.get('/api/user/name').then((response) => {
			setName(response.data.name);
		});
	}, []);

	return <div>My name is {Name}</div>;
}
```

The code above collects user data by using the Axios API and prints it on the DOM. The `useEffect` and `useState` hooks make for more straightforward and concise code that is easy to understand and work on than the class components. When using lifecycle in class components, the `componentDidMount()`, `componentDidUpdate()`, `componentWillUnmount()` methods are handled individually, but when using React hooks, you can just do everything through the `useEffect` hook.

## Hooks have made it easier for beginners to learn React {#Hooks-have-made-it-easier-for-beginners-to-learn-React}

Class components have always been a little cumbersome and confusing, especially as it makes state management and code reuse look so much more complicated than it actually is. That made many beginner developers shy away from React and opt for an “easier” framework. With hooks, it’s now simpler to learn React; because of this, its use in the tech world today has grown:

![A chart showing the relative volumes of questions for JavaScript Frameworks: jquery, ReactJS, AngularJS, and Angular. ](https://lh4.googleusercontent.com/ktziH1T91IngHVTSaF8bI6S3TKJpHZgdi6iWo4oFdo-R0spD-d7gwnRBIzy66mDMsNlceuARgajRQkqSE6qL-9lclTWUVF1QNoPfbIeVBHlVyTkO3oAd4rdcSDu3o9cJ5m65HhQa=s1600)

The graph above shows the increase in the percentage of Stack Overflow questions about React over the years vs. other popular JavaScript frameworks, proving that its general usage has increased since the introduction of hooks.

## Some hooks and their functions {#Some-hooks-and-their-functions}

Before hooks were introduced, organizing components by lifecycle methods forced us to sprinkle similar logic in several components i.e. writing the same code in several places.  To solve this and other superficial problems, React embraced functions for more straightforward and more flexible code. The next issue they had to solve was how to change the state of our components. This now brings us to our first hook: `useState`.

### The useState Hook {#The-useState-Hook}

Arguably the most common React hook, `useState` helps you pass in state variables in a functional component. Take a look at the code below:

```javascript
const loadingTuple = React.useState(true);
const loading = loadingTuple[0];
const setLoading = loadingTuple[1];

loading; // true
setLoading(false);
loading; // false
```

In the code above, `useState` takes a single argument: the state’s initial value. It returns an array with a `state` variable and a function to update that state. You now have everything you need to update the  `state` of your functional component.

The next hook we will look into solves the problem of implementing lifecycles in a functional component. It’s called `useEffect`.

### The useEffect Hook {#The-useEffect-Hook}

The `useEffect` helps to perform side effects in functional components; that is, any function that you need to run after updating the DOM. It replaces some events by running a function whenever one or more variables change. It takes two arguments: a function and an optional array. The function defines which “side effect” to run, and the optional array indicates variables, objects, etc., to watch for changes.

### Other React hooks include {#Other-React-hooks-include}

- `useContext()`: This hook helps to build a context API, which itself is a mechanism used to share data without passing props.

- `useRef()`: This hook allows you to reference the DOM in the functional component directly.

- `useReducer()`: This stores the current state value. You can liken it to Redux.

- `useMemo()`: This is a hook used to return a memoized value, i.e. when you need your function to return a cached value.

- `useCallback`: This hook is used when you have a component’s child continuously re-rendering. It will then return a memoized version of the callback that only changes when one of the dependencies changes.

> Note: `useRef()` doesn’t trigger a re-render like `setState()` does.

These are just some of the most commonly used React hooks. [If you want to learn more about React hooks, you can check it out here](https://reactjs.org/docs/hooks-overview.html).

## Conclusion {#Conclusion}

We used classes for React components because it was the best way at the time as we couldn’t create a state or implement the lifecycle methods in functional components. React hooks have made performing these functionalities much easier by providing an avenue for simpler, more composable, flexible, and extendable code than using class components without hooks. Many companies have adopted React as their primary front-end framework, which makes more developers add it to their skill-set.

Originally, React mainly used class components, which can be strenuous at times as you always had to switch between classes, higher-order components, and render props. With React hooks, you can now do all these without switching, using functional components.

Why hooks are the best thing to happen to React

The side-effect Hook of React as we know it, is one of the most useful yet tricky to grasp. This article explores how to master the use of useEffect hook for better functionality and performance.

A complete guide to the useEffect React Hook

React router as we all know is the goto 3rd party routing system for react. This comprehensive article breaks down and explains all new and core features of version 6.

An extensive guide to React Router version 6

As the web grows in popularity and power, so does the amount of data stored and transferred between systems, many of which know nothing about each other. From early on, the format that this data was transferred in mattered, and like the web, the best formats were open standards that anyone could use and contribute to. XML gained early popularity, as it looked like HTML, the foundation of the web. But it was clunky and confusing. 

That’s where JSON (JavaScript Object Notation) comes in. If you’ve consumed an API in the last five to ten years, you’ve probably seen JSON data. While the format was first developed in the early 2000s, [the first standards](https://datatracker.ietf.org/doc/html/rfc4627) were published in 2006. Understanding what JSON is and how it works is a foundational skill for any web developer. 

In this article, we’ll cover the basics of what JSON looks like and how to use it in your web applications, as well as talk about serialized JSON—JST and JWT—and the competing data formats. 

## What JSON looks like {#What-JSON-looks-like}

JSON is a human-readable format for storing and transmitting data. As the name implies, it was originally developed for JavaScript, but can be used in any language and is very popular in web applications. The basic structure is built from one or more keys and values:

```json
{
  "key": value
}
```

You’ll often see a collection of key:value pairs enclosed in brackets described as a JSON object. While the key is any string, the value can be a string, number, array, additional object, or the literals, `false`, `true` and `null`. For example, the following is valid JSON:

```json
{
  "key": "String",
  "Number": 1,
  "array": [1,2,3],
  "nested": {
    "literals": true
  }
}
```

JSON doesn’t have to have only key:value pairs; the specification allows to any value to be passed without a key. However, almost all of the JSON objects that you see will contain key:value pairs.

## Using JSON in API calls {#Using-JSON-in-API-calls}

One of the most common uses for JSON is when using an API, both in requests and responses. It is much more compact than other standards and allows for easy consumption in web browsers as JavaScript can easily parse JSON strings, only requiring `JSON.parse()` to start using it.

`JSON.parse(string)` takes a string of valid JSON and returns a JavaScript object. For example, it can be called on the body of an API response to give you a usable object. The inverse of this function is `JSON.stringify(object)` which takes a JavaScript object and returns a string of JSON, which can then be transmitted in an API request or response. 

JSON isn’t required by REST or GraphQL, both very popular API formats. However, they are often used together, particularly with GraphQL, where it is best practice to use JSON due to it being small and mostly text. If necessary, it compresses very well with GZIP.

GraphQL’s requests aren’t made in JSON, instead using a system that resembles JSON, like this

```json
{
  foo {
    bar
    baz
  }
}
```

Which will return the relevant data, and if using JSON, it will match very closely:

```json
{
  "foo": {
    "bar": "data",
    "baz": "data"
  }
}
```

## Using JSON files in JavaScript {#Using-JSON-files-in-JavaScript}

In some cases, you may want to load JSON from a file, such as for configuration files or mock data. Using pure JavaScript, it currently isn’t possible to import a JSON file, however [a proposal has been created to allow this](https://github.com/tc39/proposal-json-modules). In addition, it is a very common feature in bundlers and compilers, like [webpack](https://webpack.js.org/) and [Babel](https://babeljs.io/). Currently, you can get equivalent functionality by exporting a JavaScript Object the same as your desired JSON from a JavaScript file.

`export const data = {"foo": "bar"}`

Now this object will be stored in the constant, `data`, and will be accessible throughout your application using `import` or `require` statements. Note that this will import a copy of the data, so modifying the object won’t write the data back to the file or allow the modified data to be used in other files. 

## Accessing and modifying JavaScript objects {#Accessing-and-modifying-JavaScript-objects}

Once you have a variable containing your data, in this example `data`, to access a key’s value inside it, you could use either `data.key` or `data["key"]`. Square brackets must be used for array indexing; for example if that value was an array, you could do `data.key[0]`, but `data.key.0` wouldn’t work.

Object modification works in the same way. You can just set `data.key = "foo"` and that key will now have the value “foo”. Although only the final element in the chain of objects can be replaced; for example if you tried to set `data.key.foo.bar` to something, it would fail as you would first have to set `data.key.foo` to an object.

## Comparison to YAML and XML {#Comparison-to-YAML-and-XML}

JSON isn’t the only web-friendly data standard out there. The major competitor for JSON in APIs is XML. Instead of the following JSON:

```json
{
   "hello": "world"
}
```

in XML, you’d instead have:

```xml
<?xml version="1.0" encoding="UTF-8" ?>
<hello>world</hello>
```

JSON was standardized much later than XML, with the specification for XML coming in 1998, whereas Ecma International standardized JSON in 2013. XML was extremely popular and seen in standards such as AJAX (Asynchronous JavaScript and XML) and the `XMLHttpRequest` function in JavaScript.

XML used by a major API standard: Simple Object Access Protocol (SOAP). This standard can be significantly more verbose than REST and GraphQL, in part due to the usage of XML and because the standard includes more information, such as describing the XML namespace as part of the envelope system. This might be a reason why SOAP usage has declined for years.

![A comparison of the percentage of the 
questions per month on Stack Overflow for the tags rest, graphql, and soap.](https://lh5.googleusercontent.com/JrBhfhC8HofWtlETuRljjGxJtF0QFaN8mDyr-G6zK7OcO2YEIG_jcaoXTZftD61JF6LKYrCwh-2RX9AXoAgQ7aRP1wxitLZsfC2tcBqo9FuI7x2tqe8s87K9ee3h01KzTCgPxqznTLyeYSt14A)

Another alternative is YAML, which is much more similar in length to JSON compared to XML, with the same example being:

```yaml
---
hello: world
```

However, unlike XML, YAML doesn’t really compete with JSON as an API data format. Instead, it’s primarily used for configuration files—[Kubernetes](https://stackoverflow.blog/2020/05/29/why-kubernetes-getting-so-popular/) primarily uses YAML to configure infrastructure. YAML offers features that JSON doesn’t have, such as comments. Unlike JSON and XML, browsers cannot parse YAML, so a parser would need to be added as a library if you want to use YAML for data interchange.

## Signed JSON {#Signed-JSON}

While many of JSONs use cases transmit it as clear text, the format can be used for secure data transfers as well. [JSON web signatures](https://datatracker.ietf.org/doc/html/rfc7515) (JWS) are JSON objects securely  signed using either a secret or a public/private key pair. These are composed of a **header**, **payload**, and **signature**. 

The **header** specifies the type of token and the signing algorithm being used. The only required field is `alg` to specify the encryption algorithm used, but many other keys can be included, such as `typ` for the type of signature it is. 

The **payload** of a JWS is the information being transmitted and doesn’t need to be formatted in JSON though commonly is. 

The **signature** is constructed by applying the encryption algorithm specified in the header to the base64 versions of the header and payload joined by a dot. The final JWS is then the base64 header, base64 payload, and signature joined by dots. For example:

```
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
```

[JSON Web Tokens](https://datatracker.ietf.org/doc/html/rfc7519) (JWT) are a special form of a JWS. These are particularly useful for [authorization](https://stackoverflow.blog/2021/10/06/best-practices-for-authentication-and-authorization-for-rest-apis/): when a user logs into a website, they will be provided with a JWT. For each subsequent request, they will include this token as a bearer token in the authorization header.

 To create a JWT from a JWS, you’ll need to configure each section specifically. In the **header**, ensure that the `typ` key is `JWT`. For the `alg` key, the options of `HS256` (HMAC SHA-256) and `none` (unencrypted) must be supported by the authorization server in order to be a conforming JWT implementation, so can always be used. [Additional algorithms are recommended](https://datatracker.ietf.org/doc/html/rfc7519#section-8) but not enforced.

In the **payload** are a series of keys called claims, which are pieces of information about a subject, as JWTs are most commonly used for authentication, this is commonly a user, but could be anything when used for exchanging information. 

The signature is then constructed in the same way as all other JWSs.

Compared to Security Assertion Markup Language Tokens (SAML), a similar standard that uses XML, JSON allows for JWTs to be smaller than SAML tokens and is easier to parse due to the use of both tokens in the browser, where JavaScript is the primary language, and can easily parse JSON.

## Conclusion {#Conclusion}

JSON has come to be one of the most popular standards for data interchange, being easy for humans to read while being lightweight to ensure small transmission size. Its success has also been caused by it being equivalent to JavaScript objects, making it simple to process in web frontends. However, JSON isn’t the solution for everything, and alternate standards like YAML are more popular for things like configuration files, so it’s important to consider your purpose before choosing.

When APIs send data, chances are they send it as JSON objects. Here's a primer on why JSON is how networked applications send data.