When building React applications, you'll often work with data that only exists
on the client—such as items users add to a list before saving them to a server.
These objects usually don't have a unique ID yet, but you still need one for
things like React keys, form field associations, or other DOM relationships.

## Why You Need Unique IDs

Unique IDs are essential for:

- Rendering lists with stable React keys
- Associating labels with form fields
- Managing focus or accessibility relationships

If your data comes from a backend, it often already has an ID. But for
client-only data, you need to generate one yourself.

Don't generate a new ID on every render! Instead, generate the ID once—when the
object is created—and store it on the object. This ensures the ID stays stable
and unique. You don't necessarily need to use that ID if you end up saving that
object in a database or something, but to help React keep track of the items in
the list, you need to have a unique ID for each item.

### Using the Web Crypto API

The Web Crypto API provides a simple and reliable way to generate unique IDs:

```js
crypto.randomUUID()
```

This function returns a universally unique identifier (UUID) string, which is
perfect for most use cases.

## Example: Adding Items to a List

Here's a React component that lets users add items to a list. Each item gets a
unique ID when it's created:

```jsx
import React, { useState } from 'react'

function generateId() {
	return crypto.randomUUID()
}

function ItemList() {
	const [items, setItems] = useState([])
	const [input, setInput] = useState('')

	function handleAdd() {
		if (!input.trim()) return
		setItems([...items, { id: generateId(), label: input }])
		setInput('')
	}

	return (
		<div>
			<input
				value={input}
				onChange={(e) => setInput(e.target.value)}
				placeholder="Add an item"
			/>
			<button onClick={handleAdd}>Add</button>
			<ul>
				{items.map((item) => (
					<li key={item.id}>{item.label}</li>
				))}
			</ul>
		</div>
	)
}
```

When working with client-only data, it's important to generate unique IDs at the
time you create your objects, rather than generating them on every render. The
Web Crypto API's `crypto.randomUUID()` function provides a reliable way to
generate these unique identifiers. Make sure to store the ID directly on the
object when you create it - this ensures the ID remains stable and can be safely
used for React keys and DOM relationships.

For more on accessibility and unique IDs, check out the related article on
[generating unique IDs in React](/improving-react-accessibility-with-use-id-knljs).

Also check out [Why React Needs a Key Prop](/why-react-needs-a-key-prop) for
more on why you need to use a key prop.


Learn how to generate unique IDs for client-only data in React using the Web Crypto API, ensuring stable keys and accessible, dynamic UI components.

Generating Unique IDs for Client-Only Data in React

In this post, we’re going to dive deep on how you use modern React APIs for building forms. We will not be using third party libraries or frameworks. Understanding these lower level primitives will unlock them for you when using libraries and frameworks.

I recently heard someone say that web applications are just a skin on top of a database. And that’s actually pretty accurate. Since the beginning of the web, modern web applications have had two sides to them:

1. Users view data
2. Users mutate data

Loading data into a web application is a pretty straightforward proposition. It’s only when we start talking about needing to modify that data and keep things in sync that things get more complicated.

From day 1, HTML supported mechanisms for both of these use cases.

## Viewing Data

This allows the user to navigate to another page to view more data:

```html
<a href="/remix-utah/events/301213597">Remix Meetup June 🏖</a>
```

This *also* allows the user to navigate to another page to view more data, but enables them to control the data that comes back by including the user’s input in the generated URL:

```html
<form action="/remix-utah/events/search">
	<label for="event-search">Query</label>
	<input id="event-search" type="search" name="query" />
	<button type="submit">Search</button>
</form>
```

Let’s say the user types “August” in the input and hits enter. Thanks to the `action` the user would be sent to `/remix-utah/events/search?query=August`. So by default, `<form>` is just like `<a>` with the special ability of allowing the user to provide input.

## Mutating data

For both `<form>` and `<a>`, the navigation is performed via a `GET` request, which makes sense because you’re trying to `GET` data. But what if the user is trying to *modify* the data?

For example, let’s say you want to be able to sign up for an event with `/remix-utah/events/301213597/join`. If we made that endpoint a `GET` then we could do that like so:

```html
<a href="/remix-utah/events/301213597/join">Join Remix Meetup June 🏖</a>
```

This would certainly work (you could even use a `<form>` with a submit button if you wanted. However, this would also open your users up to a potential problem: **accidental or malicious modification of data**. Since `GET` requests are designed to be idempotent (they should be callable repeatedly without observable effects), using them for state-changing actions can lead to unintended consequences.

Additionally, if you made a login form using a `GET` request, then the user submits their password and the URL looks like this: `/login?username=kody&password=kodylovesyou`! The user’s submission is in plain text in plain sight!

This is part of the reason we have `POST` requests and while you can’t make `<a>` use `POST` instead of `GET`, you can do this with `<form>`.

`POST` requests are designed for submitting data to be processed to a specified resource. There’s no feature of HTML that triggers a `POST` request without user interaction, so they can safely be used to change the state of the server, which is perfect for our scenario of joining an event. Here’s how you can use a form to `POST` data:

```html
<form action="/remix-utah/events/301213597/join" method="POST">
	<button type="submit">Join Remix Meetup June 🏖</button>
</form>
```

By using `method="POST"`, we indicate that this form is meant to modify data on the server. The server will then process this request and update its state accordingly, ensuring that the user's intent to join the event is recorded.

### Handling Data Mutations with JavaScript

While traditional form submissions cause a full page reload, modern web applications often use JavaScript to handle these actions asynchronously, providing a smoother user experience.

Here's an example of how you might handle a form submission with JavaScript:

```html
<form id="join-event-form">
	<button type="submit">Join Remix Meetup June 🏖</button>
</form>

<script type="module">
	const form = document.getElementById('join-event-form')
	form.addEventListener('submit', async (event) => {
		event.preventDefault()

		const response = await fetch('/remix-utah/events/301213597/join', {
			method: 'POST',
			headers: { 'Content-Type': 'application/json' },
			body: JSON.stringify({ /* any necessary data can go here */ }),
		})

		if (response.ok) {
			alert('Successfully joined the event!')
		} else {
			alert('Failed to join the event.')
		}
	})
</script>
```

This script intercepts the form submission, prevents the default browser behavior, and instead sends an asynchronous `POST` request to the server. This way, the page does not need to reload, and the user receives immediate feedback on their action.

You may notice the lack of `method="POST"` in this example and that’s because it’s not strictly necessary since we prevent the browser’s default behavior.

While preventing the full page refresh is great, we lose a lot of things the browser does for us automatically when we prevent that default behavior which result in bugs we find in applications all the time.

For example, race conditions and data revalidation. That said, if you have a framework that helps you with those things (like [React Router](https://reactrouter.com/)/[Remix](https://remix.run)), then the effort is worth the improved user experience.

## React Form Actions

Mutations are an important and common part of dynamic web applications. So is linking to different parts of the application. However, mutating data is complicated because as soon as the user has performed the mutation, there are parts of the UI they could be looking at that could be out of date.

Now, to be clear, with a regular browser mutation there isn’t a problem because the full page refresh means the user always sees the latest that the server has to offer. However, if we’re focused on providing the best user experience possible, the full page refresh is unacceptable. But that means we need to update the data on the page after the mutation.

Another thing that complicates both links and forms in client-side applications is managing pending states. By default, the browser will show a spinner (often in place of the favicon), but when we prevent that default behavior we need to think about giving feedback to the user during the transition.

React has a great solution [for transitions](https://react.dev/reference/react/useTransition), but that’s only half of the story for forms. Because of this added complexity, React 19 has a built-in mechanism for handling forms called “actions.”

Just like the action attribute in an HTML form, you use the action prop in a React component. However, in addition to a URL, you can instead provide a function which will be called upon submission of the form.

```tsx
function JoinEventForm() {
	function joinEvent(formData) {
		const response = await fetch('/remix-utah/events/301213597/join', {
			method: 'POST',
			body: formData,
		})

		if (response.ok) {
			alert('Successfully joined the event!')
		} else {
			alert('Failed to join the event.')
		}
	}

	return (
		<form action={joinEvent}>
			<button type="submit">Join Remix Meetup June 🏖</button>
		</form>
	)
}
```

If you’re familiar with React forms using the `onSubmit` prop, I want you to note a few key differences here:

1. There’s no need to add `event.preventDefault` because that’s handled for us by React
2. The `action` is automatically treated as a transition, so anything that happens during the action which trigger components to suspend will be a part of that same transition. More on this in a bit.
3. We can hook into the pending state of this action using `useFormStatus` .
4. React manages errors and race conditions to ensure our form’s state is always correct (no infinite spinners).

## Pending States

There are a couple ways to manage the pending states for this interaction.

### useFormStatus

If you’re familiar with how context works in React apps, think of the `<form>` component as a provider and the `useFormStatus` hook as a function which accesses that provider’s data. Fundamentally, the `<form>` in React manages state of the status of the form and we can access that in any child component of the `<form>` . So to access the pending state of our form (while the submission is in flight) we need to create a child component.

```tsx
function JoinButton({ children }: { children: React.ReactNode }) {
	const { pending } = useFormStatus()

	return (
		<button type="submit">
			{pending ? 'Joining...' : children}
		</button>
	)
}

function JoinEventForm() {
	async function joinEvent(formData) {
		const response = await fetch('/remix-utah/events/301213597/join', {
			method: 'POST',
			body: formData,
		})

		if (response.ok) {
			alert('Successfully joined the event!')
		} else {
			alert('Failed to join the event.')
		}
	}

	return (
		<form action={joinEvent}>
			<JoinButton>Join Remix Meetup June 🏖</JoinButton>
		</form>
	)
}
```

The cool thing about [the `useFormStatus` hook](https://react.dev/reference/react-dom/hooks/useFormStatus) is that it also gives you access to other things about the form (including the submitted data). So if you’re building a login form, you could have the pending state say: `logging you in as {data.get('username')}` .

One thing I don’t love about it though is the requirement to make an entirely new component to consume the form’s state, so let’s look at an alternative approach.

### useActionState

It’s easiest to explain [`useActionState`](https://react.dev/reference/react/useActionState) with an example:

```tsx
const JOIN_URL = '/remix-utah/events/301213597/join'

async function joinEvent(
	previousState: { joined: boolean },
	formData: FormData,
) {
	const response = await fetch(JOIN_URL, {
		method: 'POST',
		body: formData,
	})

	if (response.ok) {
		return { joined: true }
	} else {
		return { joined: false }
	}
}

function JoinEventForm() {
	const [state, formAction, isPending] = useActionState(
		joinEvent,
		{ joined: false },
		JOIN_URL,
	)

	return (
		<div>
			{state.joined ? (
				<p>See you there!</p>
			) : (
				<form action={formAction}>
					<button type="submit">
						{isPending ? 'Joining...' : 'Join Remix Meetup June 🏖'}
					</button>
				</form>
			)}
		</div>
	)
}
```

Alright, so what’s going on here is `useActionState` accepts a function (`joinEvent`), some initial state (`{ joined: false }`), and optionally a permalink URL (`JOIN_URL`). It then returns an array with the current state (`state`), a function you can call to trigger the action (`formAction`), and whether the form submission is pending (`isPending`).

The `joinEvent` function accepts the previous state. In a way you can think of it as a reducer a la `useReducer`. When our form is submitted, it’s `action` is called with the `formData`. Our `action` is the `formAction`. The `formAction` function will call `joinEvent` with the current state followed by any arguments it’s called with. I understand that may be a little confusing, so let me illustrate by being obnoxiously verbose:

```tsx
function JoinEventForm() {
	const [state, formAction, isPending] = useActionState(
		(prevState, ...args) => joinEvent(prevState, ...args),
		{ joined: false },
		JOIN_URL,
	)

	return (
		<div>
			{state.joined ? (
				<p>See you there!</p>
			) : (
				<form
					action={(formData) => {
						const args = [formData]
						formAction(...args)
					}}
				>
					<button type="submit">
						{isPending ? 'Joining...' : 'Join Remix Meetup June 🏖'}
					</button>
				</form>
			)}
		</div>
	)
}
```

The `action` prop is called with the `formData`, we then make an array called `args` with only one element of `formData` which we then spread into a call of `formAction`. `formAction` then calls our inline function with the `prevState` and the rest of the args (in our case that’s just the `formData`, but as far as `useActionState` is concerned, it doesn’t have to be. It just forwards along whatever arguments there are.

From there, our `joinEvent` function performs whatever async stuff it needs to do, and then it returns a value which ends the transition and triggers our form to rerender with the `state` being equal to our returned value.

Of course during the transition, `isPending` will be `true` so we can show our pending state. However, we don’t have access to the `formData` outside our `action` so we wouldn’t be able to use the form submission as part of our pending UI like we could with `useFormStatus`. But there’s even more we can do!

Before we talk about that, I’ll just briefly mention that the third argument to `useActionState` is called a `permalink` and it’s there for server rendering and progressive enhancement. What React does with that is set the `action` to the URL you provide during server rendering. That way if the form is submitted before React has a chance to load on the page, the regular browser behavior will take over and submit the form with the full-page refresh functionality we’re used to (you’ll just want to make sure your server can handle the form submission properly). Hooray for progressive enhancement!

### useOptimistic

Showing the user feedback of pending tasks is important and useful. It’s awesome if the pending state actually looks like the finished state (maybe with a subtle indicator that it’s not actually complete). A good example of this is when you send a Slack/Discord message. The message appears in the messages list, but it’s slightly transparent to give you the sense that it’s an incomplete mutation.

You can do this with [`useOptimistic`](https://react.dev/reference/react/useOptimistic):

```tsx
// ...

function JoinEventForm() {
	const [state, formAction] = useActionState(
		joinEvent,
		{ joined: false },
		JOIN_URL,
	)
	const [optimisticJoined, setOptimisticJoined] = useOptimistic(state.joined)

	return (
		<div>
			{optimisticJoined ? (
				// show faded a bit if we've not yet finished joining...
				<p style={{ opacity: state.joined ? 1 : 0.8 }}>See you there!</p>
			) : (
				<form
					action={(formData) => {
						setOptimisticJoined(true) // Optimistically set the state to joined
						return formAction(formData)
					}}
				>
					<button type="submit">
						Join Remix Meetup June 🏖
					</button>
				</form>
			)}
		</div>
	)
}
```

The `useOptimistic` hook allows you to immediately update the UI to reflect the user's action before the network request completes. If the actual request fails, the state is reverted to the previous state. This provides a smoother user experience by reducing the perceived latency of the action.

We can even remove the pending UI from the button, but we add a little transparency to the success message to give the impression things are not completely settled. You may want to consider the experience for non-seeing users as well. React provides us with all we need to build this kind of experience!

You can even perform multiple steps and keep the user up-to-date with what’s happening with `useOptimistic`. It’s awesome:

```tsx
// ...

function JoinEventForm() {
	const [state, formAction] = useActionState(
		joinEvent,
		{ joined: false },
		JOIN_URL,
	)
	const [optimisticMessage, setOptimisticMessage] = useOptimistic("")

	return (
		<div>
			{state.joined ? (
				<p>See you there!</p>
			) : (
				<form
					action={async (formData) => {
						setOptimisticMessage("Joining meetup...")
						await formAction(formData)
						setOptimisticMessage("Sending notifications...")
						await sendNotification()
					}}
				>
					<p>{optimisticMessage}</p>
					<button type="submit">
						Join Remix Meetup June 🏖
					</button>
				</form>
			)}
		</div>
	)
}
```

In this example, we use the `useOptimistic` hook to provide feedback to the user at multiple stages of the form submission process. Initially, we set the optimistic message to "Joining meetup...", then await the `formAction`. Once that completes, we update the message to "Sending notification..." and await the `sendNotification` function.

## Conclusion

I think it’s awesome that we’ve not needed to reach for any libraries other than React to have all of this functionality. Really, what’s cool is what you *don’t see* but get like declarative management of errors and pending transitions and proper management of race conditions. And a great Optimistic UI story is also awesome. We also didn’t get to talk much about how this integrates with the server via the [`"use server"`](https://react.dev/reference/rsc/use-server) directive, but that’s a huge win as well which we’ll have to explore in the future.

I hope this article helped you get a more clear picture of what’s possible with React 19’s form primitives.

React 19 introduces terrific primitives for building great forms. Let's dive deep on forms for the web with React.

A deep dive on forms with modern React

# JUST USE REACT

_(OR ANY MODERN FRAMEWORK, ESPECIALLY FOR COMPLEX PROJECTS)_

---

NOTE: This post is adapted from [justf***ingusereact.com](https://justfuckingusereact.com/). The original uses strong language for humorous emphasis. That's really the whole point. That said, there are interesting points in the post so this version aims to convey the core message without profanity or rude language. I basically just gave the original to AI and asked it to make it nicer. I'm posting it here partly as a joke, and also because reading curse words hurts my head.

Credit to original creators is noted at the end.

With that said, let's get into it:

---

It's understandable. You might have seen discussions championing "pure HTML," "keeping it simple," or noting how "My GeoCities page from '98 still loads faster than your SPA." These are valid points in many contexts, and the desire for simplicity is commendable.

It's a nice sentiment, much like wishing for simpler economic systems. However, the web today often hosts more than just static informational pages. It's a platform for dynamic applications, collaborative workspaces, and rich interactive experiences. These often require a different set of tools and approaches than a "Very beautiful button" on a static page.

## SO, WHAT'S THE POINT HERE?

The idea is to acknowledge that <mark>sometimes, complexity in a project isn't an arbitrary choice, but a genuine requirement of the features being built.</mark> When these complex requirements arise, trying to manage everything with direct DOM manipulation and standalone JavaScript files can become akin to building a sophisticated machine with only the most basic hand tools. You might achieve the goal, but the process can be challenging, and the result harder to maintain or scale.

This is an invitation to consider the powerful tools developed by many talented engineers. These tools are designed to handle common complexities, allowing development teams to focus on unique application logic and user experience, rather than repeatedly solving foundational problems.

## WHY MIGHT ONE CONSIDER MOVING FROM "PURE HTML" TO JAVASCRIPT FRAMEWORKS?

Because often, the goal is to build more than a static document. You're looking to create something interactive, dynamic, and user-friendly—an *application* that offers a rich experience, not just a digital flyer.

Here's why using React (or Vue, Svelte, Angular, or a similar modern framework) can be beneficial, especially as project complexity grows:

### HTML'S BUILT-IN INTERACTIVITY IS A GREAT STARTING POINT, BUT MAY NOT SUFFICE FOR RICH APPLICATIONS.

"But HTML has `<details>`, `<dialog>`, and forms!" Absolutely, and these are fantastic for many use cases. They are essential building blocks. However, are they always sufficient for a real-time collaborative editor, a dynamic trading dashboard, or an enterprise-grade project management tool?

When building such applications, the native interactive elements of HTML, even with vanilla JavaScript, might require a significant amount of custom code to orchestrate complex user workflows and manage state. What HTML provides are the fundamental elements; frameworks often provide the structure and machinery to build more elaborate systems on top of those fundamentals.

### EFFECTIVE STATE MANAGEMENT IS KEY.

Managing the state of a simple "like" button by toggling a class is straightforward. But consider a dashboard with multiple filters, real-time data from various sources, user-specific preferences, and perhaps even collaborative editing features. A "simple" JavaScript approach here can quickly lead to a tangled web of interconnected logic that's difficult to debug and maintain. Frameworks offer structured and often more intuitive ways to manage this kind of application state. Without them, developers might find themselves navigating a tricky path, hoping to avoid global variable conflicts or hard-to-trace bugs.

[The interactive demo on the original site provides a good visual for this point!](https://justfuckingusereact.com/#state-management)

### COMPONENTS: BUILD ONCE, USE EVERYWHERE.

Remember the times you might have copied and pasted HTML for a navigation bar across many pages, only to update each instance when a new link was needed? It's a common early approach, and understandable at the time.

Frameworks like React encourage (or enforce) thinking in terms of reusable, encapsulated components. A button, a form field, or an entire user profile card can be built once—its structure, style, and logic defined in one place—and then reused wherever needed. A change in the component's definition updates it everywhere. This isn't just about convenience; it's about maintainability, consistency, and sanity, especially as applications grow or are worked on by teams.

### SMARTER, MORE EFFICIENT UI UPDATES.

Manually updating many parts of a page when a single piece of data changes can be error-prone. One might find themselves meticulously telling each `<span>` and `<div>` to refresh, hoping not to miss anything or cause inefficient re-renders of the entire page.

Frameworks are designed to be intelligent about UI updates. You declare what the UI *should* look like based on the current data (state). When that data changes, the framework efficiently determines the minimal set of changes needed in the actual DOM. It's like having a highly optimized assistant that only repaints the necessary parts, rather than redecorating the whole house when one picture is moved. This declarative approach often leads to cleaner code and better performance.

### ACCESSIBILITY AT SCALE: A STRUCTURED APPROACH.

"Just use semantic HTML!" is excellent advice and a cornerstone of web development. That's Web Dev 101.

But what about complex, custom UI elements that go beyond standard HTML tags? Consider custom data grids with sorting and filtering, accessible comboboxes with type-ahead features, or navigable tree views. Simply adding `role="button"` to a `<div>` is a start, but true accessibility for such components involves careful management of ARIA attributes, focus, and keyboard interactions. Implementing this correctly and consistently across many instances with vanilla JavaScript can be a significant undertaking.

Frameworks allow you to build an *accessible component* once, encapsulating all the necessary ARIA attributes and behaviors. This component can then be reused, promoting consistency and making it easier to maintain high accessibility standards. Would one prefer to manually manage `aria-expanded` and related states on 50 different accordion instances, or define it once in a reusable component? For complex UIs, relying solely on basic HTML can sometimes inadvertently lead to experiences that aren't fully accessible to all users.

### THE "SIMPLE" HTML FAÇADE CAN SOMETIMES HIDE A LOT OF MANUAL JAVASCRIPT WORK.

Phrases like "No hydration errors! No tree-shaking!" might sound appealing, framing these as complexities to be avoided. However, these are often sophisticated solutions to real problems that arise when building substantial client-side applications.

Opting out of a framework doesn't make these problems disappear if the application's requirements inherently involve them. It often means that the developer or team is now responsible for manually implementing solutions for DOM diffing, state propagation, code splitting for performance, and other optimizations—tasks that frameworks have evolved to handle effectively. It's not always about choosing "simplicity" over "complexity," but rather choosing to leverage well-tested solutions for common complex problems, or to build those solutions from scratch. The latter can be like choosing to manually craft every part of a complex machine when pre-fabricated, optimized components are readily available.

### RELYING ON HTML'S ID-BASED GLOBAL JAVASCRIPT VARIABLES: A HISTORICAL CURIOSITY.

It's true that HTML elements with `id` attributes can sometimes become global JavaScript variables. This was a "feature" from an earlier era of the web. Relying on this today can be risky.

It can pollute the global namespace, lead to hard-to-debug naming collisions, and contribute to a fragile, less maintainable codebase. This can cause significant frustration for future developers (including your future self!).

Frameworks guide developers towards more robust patterns: scoped components, explicit data flow (like props), and dedicated state management solutions that don't depend on the chance that `window.myButton` hasn't been overwritten. This isn't HTML "lending crutches"; it's frameworks helping to avoid potential pitfalls inherent in some older browser behaviors.

### DEVELOPER EXPERIENCE (DX) MATTERS FOR PRODUCTIVITY AND ENJOYMENT.

Consider features like Hot Module Replacement (seeing UI changes instantly without losing application state during development), the safety net of TypeScript, a vast ecosystem of libraries for tasks from internationalization to animation, and robust linters, formatters, and debuggers.

Frameworks, especially mature ones like React, come with an ecosystem that can make the development process more productive and enjoyable. This often translates to building better applications, faster. Pretending that grappling with browser inconsistencies and older JavaScript patterns is inherently more virtuous can be a less efficient path for complex projects.

### PERFORMANCE IS MORE THAN JUST INITIAL LOAD; IT'S ABOUT THE ENTIRE USER EXPERIENCE.

"My HTML site loads in 50ms!" That's great for initial delivery. But what happens when you add user login, dynamic content fetching, client-side filtering and sorting, and real-time updates without causing the page to become unresponsive or slow?

Frameworks, particularly when combined with their meta-frameworks (like Next.js or Remix for React), provide tools for a holistic approach to performance. This includes code-splitting (loading only necessary JavaScript), server-side rendering (SSR) or static site generation (SSG) for fast initial loads *combined with* dynamic capabilities, and smooth client-side navigation. The goal is to build a high-performance *application*, not just a document that loads quickly but offers limited interactivity.

## BUT WHAT ABOUT THE "BLOAT"? THE JAVASCRIPT OVERHEAD?

It's true: a "Hello World" application in a framework will likely have a larger initial JavaScript footprint than a plain HTML "Hello World." That's to be expected. But are most production applications "Hello World" simple? If you're building a very simple, mostly static, five-page brochure website, then yes, HTML and CSS are likely perfectly sufficient and the most efficient choice. The "other site" makes a good point here. One doesn't need a bulldozer to plant a flower.

However, if the project involves:

*   A SaaS platform
*   An e-commerce site with a complex shopping cart and user accounts
*   A dynamic social media feed
*   A feature-rich project management tool
*   An interactive data visualization dashboard
*   Anything with significant client-side interactivity and state that needs to function reliably and be maintainable

...then the initial JavaScript "cost" of a framework can be seen as an investment in the infrastructure needed to build and manage that complexity. Modern tools like tree-shaking, code-splitting, and lazy loading help significantly in mitigating this cost. It's about selecting the appropriate tool for the task, rather than sticking to a familiar tool when a more specialized one would be more effective for the scale of the project.

## SO, WHEN MIGHT IT BE A GOOD IDEA TO USE REACT (OR A SIMILAR FRAMEWORK)?

Consider a modern framework when:

*   Your application has **non-trivial client-side state** that needs to be managed effectively.
*   You need **reusable UI components** to build a consistent, maintainable, and scalable interface.
*   You're developing a **Single Page Application (SPA)** or an application that aims for a fluid, app-like experience rather than a series of document loads.
*   You're working in a **team** and need shared structures, patterns, and a common vocabulary.
*   The **complexity of user interactions** would likely lead to difficult-to-manage "spaghetti code" if built with vanilla JavaScript alone.
*   You want to leverage a **rich ecosystem** of well-tested libraries, tools, and community support.
*   **Developer velocity** and the ability to efficiently build complex features are more critical than minimizing every last kilobyte for a largely static page.

## THE REAL CHALLENGE ISN'T THE FRAMEWORK ITSELF, BUT HOW WE CHOOSE AND USE OUR TOOLS.

The challenge often lies in selecting the right tool for the job. Sometimes, a simpler solution is indeed best. Developers might occasionally use an overpowered tool for a simple task, or adopt new technologies without fully evaluating their fit for the problem at hand. It can be like using a high-powered industrial tool for a delicate home repair—perhaps overkill.

However, let's not dismiss powerful tools simply because they can be misapplied. React and similar frameworks are capable tools that solve real, complex problems effectively. The issue isn't usually the tool itself, but ensuring it's wielded appropriately for the task.

So, for your next complex, interactive, data-driven web application, <mark>CONSIDER USING REACT (OR A SIMILAR FRAMEWORK).</mark> It's not about purity, but about pragmatism and choosing tools that can help you and your team build robust, maintainable applications. Your users (and your future self, tasked with maintaining the codebase) will likely appreciate the structure and capabilities these frameworks provide.

Now, go forth and build something amazing, leveraging the best tools for your specific challenges, rather than creating an HTML solution that might not scale with your ambitions.

---

_This content is adapted from [justf***ingusereact.com](https://justfuckingusereact.com/) to present its arguments in a different tone. Original credit to its creators._

**Original Creators:**

Omercan ([GitHub](https://github.com/obsfx) / [X](https://x.com/obsfx) / [Bluesky](https://bsky.app/profile/omercan.io))

Burak ([GitHub](https://github.com/burakcan) / [X](https://x.com/neoberg) / [Bluesky](https://bsky.app/profile/burakcan.me))

Inspired by [justf***ingusehtml.com](https://justfuckingusehtml.com/)

**[View the source code of the original on GitHub](https://github.com/burakcan/just-fucking-use-react)**


Just Use React

When was the last time you saw an error and had _no idea_ what it meant (and therefore no idea what to do about it)? Today? Yeah, you're not alone... Let's talk about how to fix that.

## A story

A while ago, I got a new faucet. It's one of those cool ones where the head of the faucet could come off so we could direct the water's flow and would automatically retract back into the neck when you're done. Unfortunately, it wasn't long before we had a problem:

![Faucet with the head not retracting into the neck](/articles-images/requisite-react/broken-faucet.png)

The head of the faucet wouldn't automatically go back into the neck! And we couldn't even push it back in. It just hung there. Like a sad flower 🥀

So we called the plumber who had installed it for us to have them come look at it and see if they could fix it or give us a replacement. A few days later was the day of our appointment. A few hours before he arrived, I looked frustratingly at the faucet and wondered... So I looked under the sink, and this is what I saw:

![Under a sink a faucet hose is tangled in itself](/articles-images/requisite-react/tangled-hose.png)

That's the hose for our faucet. It turns out there's a simple weight that goes on the hose and that weight is what pulls the head of the faucet into the neck. Because it was tangled in itself, the weight wasn't pulling the hose down. So I reached in and untangled the hose:

![Under a sink a faucet hose is untangled](/articles-images/requisite-react/untangled-hose.png)

And like a miracle, it suddenly worked! I called the plumber to cancel as quickly as I could to avoid revealing my shame. Can you imagine if I hadn't discovered the problem and they came over, untangled the hose, and gave me an invoice for their trouble. I don't know if I could have taken that hit to my ego. The embarrassment would have been too much 🙈

So what does a faucet problem have to do with React? A faucet is an abstraction. We don't have to have faucets. We could just pull the hose straight out of the wall and use that instead, but we put the faucet in place because it makes the water more useful. Normally it works fine, but when there's a problem, if you don't understand how the abstraction works, it's difficult to figure out what went wrong and how to resolve the problem.

## A universal truth

React is an abstraction too. And here's a universal truth about abstractions:

https://twitter.com/kentcdodds/status/1074724545003581440

Abstractions are all around us. Your phone is an abstraction. Your car is an abstraction. And the better we understand how those things work, the better we are able to use them. And that's not to say that you _can't_ use the abstraction if you don't know how they work. I drive my car all the time and I have no idea how it works. But whenever something goes wrong with it, I'm at a total loss (and that's just the way my mechanic likes it 🤑).

You can use React without a good foundation in the fundamentals and that's totally fine. You can ship really amazing things without a solid foundation. But if you'd like to level-up on your capabilities and productivity with React, then digging in and gaining an understanding in how they work is the way to do it.

## A simple example

There's a fun site [YouMightNotNeedjQuery.com](http://youmightnotneedjquery.com/) which shows common jQuery functions and the code needed for that same functionality based on the browser support you have (up to IE10).

So let's imagine that you needed [jQuery's `toggleClass` functionality](https://api.jquery.com/toggleclass/) so you copy/pasted the code from YouMightNotNeedjQuery.com and built this function so you don't have to bring all of jQuery into your app:

```javascript
function toggleClass(el, className) {
  if (el.classList) {
    el.classList.toggle(className)
  } else {
    var classes = el.className.split(' ')
    var existingIndex = -1
    for (var i = classes.length; i--; ) {
      if (classes[i] === className) existingIndex = i
    }

    if (existingIndex >= 0) classes.splice(existingIndex, 1)
    else classes.push(className)

    el.className = classes.join(' ')
  }
}
```

What you've created is your own little abstraction. But actually, you're also _using_ an abstraction: the DOM. And if you knew a little bit more about that abstraction, you'd know that browsers (including IE10) have support for this built-in. So that function could be simplified... a lot:

```javascript
function toggleClass(el, className) {
  el.classList.toggle(className)
}
```

So by understanding the abstraction we're using (the DOM in this case), we're able to drastically simplify our code which ultimately [impacts our users](https://kentcdodds.com/blog/why-users-care-about-how-you-write-code).

## A problem with learning abstractions

These days not many people build an application without using a soup of tools and libraries to do so. Unfortunately, if you skip over the fundamentals of each tool, it's easy for your understanding of each to become muddled. Is React managing my state or React Query? Is Babel compiling my JSX or React? Do I need PropTypes if I'm using TypeScript? Isn't redux required if you're building a React app? (That last one is a definite no).

One of the biggest causes for people's struggle at understanding abstractions is they struggle to draw lines around the abstractions. When you're not sure which abstraction should do which job, it's very easy to use the wrong tool for the job. Sure you can get it working eventually, but you may be left with a solution that causes you and ultimately your users some real pain.

So a great first step to understanding your abstractions better is to learn them in isolation from one another and only add them to your learning when you run into the problem they actually solve.

Too many people start learning and using React with Webpack, Babel, React Router, Redux, Jest, React Testing Library, Material UI, etc. etc. This makes it really difficult to draw lines around these abstractions and really understand the purpose of each.

## A different approach

This is why [EpicReact.Dev](https://epicreact.dev) introduces one concept at a time. And we don't skip anything. As you just get started, we literally write JavaScript in a script tag of an HTML file. We don't even write React first. We start with regular DOM nodes. Then we add `React.createElement`. Then we add JSX. And we methodically add more and more concepts over time so you get a good idea of what tools are responsible for what so you can use each as effectively as possible.

This is why people who have been using React for _years_ tell me that they _still_ learn new things from my beginner material. Because we so often skip over that methodical approach when we're in a rush to ship something.

## Time to level-up

If you're tired of seeing errors pop up in your console and not understanding what to do about them, then gaining a deeper understanding of the fundamentals of how things work is the best thing you can do to get over that. If you're tired of fumbling around with wiring things together and praying that nobody blows your house of cards over, then taking a bit to sharpen your understanding of your primary abstractions (like React) will go a long way.

And this is exactly why I created [EpicReact.Dev](https://epicreact.dev): To help you level-up your professional React knowledge and productivity.

When was the last time you saw an error and had no idea what it meant (and therefore no idea what to do about it)? Today? Yeah, you're not alone... Let's talk about how to fix that.

Requisite React

## Introduction: The Async UI Challenge in React

Fetching data in React is easy—handling the user experience while waiting for
that data is not. Spinners, loading states, and error messages often clutter our
components and make code harder to maintain. Wouldn't it be great if React could
handle async UI declaratively, just like it does with everything else?

That's exactly what React Suspense is designed to do. Let's look under the hood
at how it works, why it's so clever, and how you can use it to simplify your
async UI.

## What is React Suspense?

React Suspense is a mechanism that lets you declaratively specify loading and
error states for components that depend on asynchronous data. Instead of
manually tracking loading and error state, you wrap your component tree in
`<Suspense>` and let React handle the rest.

Here's the wild part: Suspense works by catching thrown promises 😱. When a
component needs data that isn't ready, it throws a promise. React catches that
promise, pauses rendering, and shows the fallback UI you provided to
`<Suspense>`. When the promise resolves, React tries rendering again.

This is possible because in JavaScript, you can synchronously stop a function by
throwing. React leverages this to "pause" rendering until the data is ready.

## How the `use` Hook Works with Suspense

The `use` hook in React 19+ is the key to this pattern. Instead of using
`await`, you pass a promise to `use`, and it either returns the resolved value
(if ready) or throws the promise (if not):

```tsx
function PhoneDetails() {
	const details = use(phoneDetailsPromise)
	// details is ready here!
}
```

But where does `phoneDetailsPromise` come from? You should trigger the fetch
outside the render, so you don't start a new request on every render. For
example:

```tsx
// this could be in an event handler or something, just not within the body of
// a client component (server components can't use `use` and can just use
// `fetch` directly).
const phoneDetailsPromise = fetch('/api/phone-details').then((res) =>
	res.json(),
)
```

If the promise isn't resolved, `use` throws it, triggering Suspense. If it's
resolved, you get the value.

## Error Handling with Suspense and Error Boundaries

If the promise rejects, React will look for an Error Boundary and render its
fallback. This lets you handle errors declaratively, just like loading states:

```tsx
import { Suspense } from 'react'
import { ErrorBoundary } from 'react-error-boundary'

function App() {
	return (
		<ErrorBoundary fallback={<div>Oh no, something bad happened</div>}>
			<Suspense fallback={<div>Loading phone details...</div>}>
				<PhoneDetails />
			</Suspense>
		</ErrorBoundary>
	)
}
```

## Practical Example: Building a Simple Suspense Data Fetcher

Let's build a simple Suspense data fetcher from scratch:

```tsx
let userPromise
function fetchUser() {
	userPromise = userPromise ?? fetch('/api/user').then((res) => res.json())
	return userPromise
}

function UserInfo() {
	const user = use(fetchUser())
	return <div>Hello, {user.name}!</div>
}

function App() {
	return (
		<Suspense fallback={<div>Loading user...</div>}>
			<UserInfo />
		</Suspense>
	)
}
```

Notice how there's no manual loading or error state in `UserInfo`. Suspense and
Error Boundaries handle it all.

You could imagine how to expand this example to be more complex (parameterized,
cached, etc.), and I'll invite you to join me in the
[Epic React Suspense Workshop](https://www.epicreact.dev/workshops/react-suspense)
to dive deeper into all of that 😉. In fact, we build our own implementation of the `use`
hook **from scratch** so you really *understand* what's going on under the hood.

## Conclusion

This pattern is powerful because it is:

- **Declarative:** No more manual state management for loading/errors.
- **Composable:** Works with any async resource—data, images, even code.
- **Scalable:** Suspense boundaries can be nested for fine-grained control.
- **Future-proof:** This is the "blessed" way React handles async UI in the
  client.

React Suspense is great for async UI. By "throwing promises" and using the `use`
hook, you can write cleaner, more declarative components that handle loading and
error states automatically. Try it out in your next project and see how much
simpler your code can be!


Discover how React Suspense leverages thrown promises and the `use` hook to simplify async UI, manage loading and error states, and improve user experience.

Generating Unique IDs for Client-Only Data in React

Why You Need Unique IDs

Using the Web Crypto API

Example: Adding Items to a List

Get my free 7-part email course on React!

More Articles

A deep dive on forms with modern React

Just Use React

Requisite React

How React Suspense Works Under the Hood: Throwing Promises and Declarative Async UI