If you've ever used a native `<select>` and `<option>` in HTML, you've already
experienced the power of **compound components**—even if you didn't know the
name.

But what if you could bring that same flexibility and declarative power to your
own React components? That's what the Compound Components pattern is all about.

## What and Why: Compound Components in React

Compound components are a set of components that work together to form a
complete UI, implicitly sharing state and behavior. Think of them as a family:
each member has a role, but they all work together seamlessly.

The classic example is HTML's select:

```html
<select>
	<option value="1">Option 1</option>
	<option value="2">Option 2</option>
</select>
```

The `<select>` manages the state, and the `<option>`s are just configuration.
You don't have to wire them up manually—they just work.

You _could_ build a custom select like this:

```tsx
<CustomSelect
	options={[
		{ value: '1', display: 'Option 1' },
		{ value: '2', display: 'Option 2' },
	]}
/>
```

But what if you want to add custom attributes to an option, or change how it's
displayed when selected? You'd have to keep adding more props and configuration,
making your API more complex and less flexible.

Compound components let you keep your API simple and declarative:

```tsx
<CustomSelect>
	<CustomOption value="1">Option 1</CustomOption>
	<CustomOption value="2">Option 2</CustomOption>
</CustomSelect>
```

Now, you can pass _anything_ as children, and each option can be as flexible as
you need.

The parent component (like `<CustomSelect>`) manages the shared state and passes
it down to its children using React's context API. The children (like
`<CustomOption>`) consume that context and interact with the parent as needed.

This pattern lets you build components that are:

- **Flexible:** Users can compose your components however they want.
- **Declarative:** The structure of the UI matches the structure of the code.
- **Extensible:** Add new features without breaking existing APIs.

## Real-World Impact & When to Use

This isn't just a theoretical pattern. It's used in some of the most popular UI
libraries, like
[Radix UI Tabs](https://www.radix-ui.com/primitives/docs/components/tabs) and
[Radix UI Accordion](https://www.radix-ui.com/primitives/docs/components/accordion).
In fact, most of [Radix UI](https://www.radix-ui.com/primitives) is built on
this pattern.

Reach for compound components when:

- You want to give users maximum flexibility in composing your UI.
- You want to avoid prop explosion and keep your API clean.
- You want your components to "just work" together, like native HTML elements.

Want to master patterns like this—and many more?
[EpicReact.dev](https://epicreact.dev) is packed with hands-on workshops,
real-world examples, and deep dives into the patterns that make React apps
scalable and maintainable. Whether you're a beginner or a seasoned pro, you'll
find something to level up your React skills.


Build flexible, declarative UIs like native HTML with Compound Components—a powerful React pattern you’ll master at EpicReact.dev.

Compound Components: Truly Flexible React APIs

I've been riding the CSS-in-JS train for years (I was even a significant contributor to the "movement"). It's awesome. I've never been so productive working with CSS than when I added the power of JavaScript to it.

I'm still a fan of CSS-in-JS, and in recent years, the CSS spec has evolved and improved a lot and modern browsers have too (unfortunately, Internet Explorer is NOT a modern browser in this or any context). Often I'd use a `ThemeProvider` (like those found in emotion), but turns out there aren't a whole lot of advantages to that kind of component for many use cases and there are several disadvantages.

Let's look at a simple example of "Dark Mode" and compare differences in API (developer experience) and performance (user experience). We'll keep the example simple, and in both the before/after, we'll be using emotion's `styled` utility. Keep in mind that with the `ThemeProvider` you can consume the values using the `useTheme` hook, with a styled component, or with the `css` prop. With CSS Variables, you can get the values in your CSS with `var(--css-variable-name)` and in your JavaScript using `getComputedStyle(element).getPropertyValue('--css-variable-name')` (which you really don't need to do...)

Ok, let's look at some code. Here's an approach to using emotion's `ThemeProvider`:

```javascript
import * as React from 'react'
import styled from '@emotion/styled'
import {ThemeProvider} from 'emotion-theming'

const themes = {
  light: {
    colors: {
      primary: 'deeppink',
      background: 'white',
    },
  },
  dark: {
    colors: {
      primary: 'lightpink',
      background: 'black',
    },
  },
}

const PrimaryText = styled.div(({theme}) => ({
  padding: 20,
  color: theme.colors.primary,
  backgroundColor: theme.colors.background,
}))

function ThemeToggler({theme, onClick}) {
  const nextTheme = theme === 'light' ? 'dark' : 'light'

  return (
    <button onClick={() => onClick(nextTheme)}>
      Change to {nextTheme} mode
    </button>
  )
}

function App() {
  const [theme, setTheme] = React.useState('light')
  return (
    <ThemeProvider theme={themes[theme]}>
      <PrimaryText>This text is the primary color</PrimaryText>
      <ThemeToggler
        theme={theme}
        onClick={(nextTheme) => setTheme(nextTheme)}
      />
    </ThemeProvider>
  )
}

export default App
```

What's cool about this is it's "just JavaScript" so you get all the benefits of variables etc. But we're not really doing all that much with this other than passing it around through the ThemeProvider. (To be clear, the way the ThemeProvider works is it uses React's Context API to make the theme accessible to all emotion components without having to pass props all over the place).

Let's compare this with the CSS Variables approach. But before we get to that, I need to mention that there's no "ThemeProvider" for this. Instead, we define the variables in regular CSS that will get applied based on a `data` attribute we apply to the `body`. So here's that css file:

```css
body[data-theme='light'] {
  --colors-primary: deeppink;
  --colors-background: white;
}

body[data-theme='dark'] {
  --colors-primary: lightpink;
  --colors-background: black;
}
```

Alright, so with that, here's the implementation of the exact same UI:

```javascript
import * as React from 'react'
import './css-vars.css'
import styled from '@emotion/styled'

const PrimaryText = styled.div({
  padding: 20,
  color: 'var(--colors-primary)',
  backgroundColor: 'var(--colors-background)',
})

function ThemeToggler() {
  const [theme, setTheme] = React.useState('light')
  const nextTheme = theme === 'light' ? 'dark' : 'light'

  React.useEffect(() => {
    document.body.dataset.theme = theme
  }, [theme])

  return (
    <button onClick={() => setTheme(nextTheme)}>
      Change to {nextTheme} mode
    </button>
  )
}

function App() {
  return (
    <div>
      <PrimaryText>This text is the primary color</PrimaryText>
      <ThemeToggler />
    </div>
  )
}

export default App
```

Let's first compare what it's like to _use_ these values:

```javascript
// ThemeProvider:
const PrimaryText = styled.div(({theme}) => ({
  padding: 20,
  color: theme.colors.primary,
  backgroundColor: theme.colors.background,
}))

// CSS Variables:
const PrimaryText = styled.div({
  padding: 20,
  color: 'var(--colors-primary)',
  backgroundColor: 'var(--colors-background)',
})
```

There's not really much of a difference from a DX (development experience) standpoint here. One point for the CSS Variables approach is not having to create a function that accepts the theme and returning styles (and no need to even learn about that API).

One point for the `ThemeProvider` approach is if you're using TypeScript you could get type safety on your theme... But ummm... [Check this out](https://twitter.com/chochihim/status/1324182272304537600):

```javascript
// src/theme.js
const theme = {
  colors: {
    primary: 'var(--colors-primary)',
    background: 'var(--colors-background)',
  },
}
export {theme}

// anywhere-else.js
import {theme} from 'theme'

const PrimaryText = styled.div({
  padding: 20,
  color: theme.colors.primary,
  backgroundColor: theme.colors.background,
})
```

BOOM. Static typing-friendly.

Either way, that's really the only significant DX difference. Let's consider the UX (user experience) difference. Why don't you play around with it:

<iframe   src="https://codesandbox.io/embed/df90h?view=Editor+%2B+Preview&module=%2Fsrc%2Findex.js"   style={{     width: '100%',     height: '500px',     border: 0,     borderRadius: '5px',     overflow: 'hidden',   }}   title="CSS Variables vs ThemeProvider"   allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"   sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts" ></iframe>

You'll notice there's not really any observable UX difference, and there's not for this simple example. But why don't you try this with me:

1. pop open the React DevTools Profiler 2. Start a profiling session (click the little circle) 3. Click the toggle button for each 4. Stop the profiling session 5. Compare the two commits

Here's what I see:

**ThemeProvider:**

![Profiling session showing everything rendered](/articles-images/css-variables/theme-provider.png)

**CSS Variables:**

![Profiling session showing only one component rendered](/articles-images/css-variables/css-vars.png)

I don't want you to get hung up on the number of milliseconds to rerender. This isn't a controlled benchmark (we're in React's dev mode for one thing). The thing I want you to consider is how many components needed to re-render for this change. Let's consider the `ThemeProvider` approach first. The main reason for this is the way we've structured our state ([we could restructure things](https://kentcdodds.com/blog/optimize-react-re-renders) and improve it a little bit). But even if we restructured things, when the theme changes, _every_ emotion component needs to be re-rendered to account for the theme change.

Turning to the CSS Variables approach, you'll notice the only component that re-rendered was our `ThemeToggler` component responsible for updating the `body`. And yet the user experience works perfectly! This is the magic behind CSS variables. With the `ThemeProvider` approach, we have to update the styles of every component, and then the browser paints those updates. But with the CSS Variables approach, we update the styles to a single component (the `body`) and then the browser paints those updates. The browser paint should theoretically take the same amount of work on the part of the browser, so the only difference is how much work we're making the browser do to have React re-render all our components and get emotion to update the styles of every component.

This _can_ have negative performance implications as your app grows. Considering the DX isn't objectively better or worse either way, but the UX is quite possibly better with CSS Variables, I feel comfortable recommending CSS Variables over using Context to share a theme like this.

Oh, and consider also that CSS Variables are part of the browser spec and the ThemeProvider isn't. That's another solid point for CSS Variables 😉

This is one standard I'd suggest you embrace.

One last piece of nuance here. What if you not only want to change styles but _also_ want to change component implementations based on the theme? In this case... [YOU CAN DO BOTH](https://twitter.com/sebmarkbage/status/1324097255557767173)! The benefit of doing this is the only components that need to consume the context value are those that need to render differently based on the theme (which is likely a small subset). Most components can use the css variables for styling purposes only, so you'll still get the aforementioned benefits. If you don't _need_ components to render differently based on the theme then I wouldn't bother with this, but if you do, then it's pretty simple to do. There are several ways to accomplish this, I've done one implementation in [the codesandbox](https://codesandbox.io/s/css-variables-vs-themeprovider-df90h?file=/src/both/index.js). Enjoy exploring that.

CSS variables (custom properties) are awesome. Give them a look. Good luck!

How and why you should use CSS variables (custom properties) for theming instead of React context.

Use CSS Variables instead of React Context

Focus management is one of those things you don't think about until it's broken.
But when it is, it can make your app feel clunky, inaccessible, or just plain
wrong. Let's talk about a little-known React API that can help you nail focus
management: [`flushSync`](https://react.dev/reference/react-dom/flushSync).

## Why focus management is tricky in React

React is fast and smart about how it updates the DOM. When you call a state
updater like `setShow(true)`, React doesn't immediately re-render your
component. Instead, it batches up state updates and processes them all at once,
after your event handler finishes. This is great for performance, but it can
trip you up when you need to interact with the DOM _right after_ a state change.

Here's a classic example:

```tsx
function MyComponent() {
	const [show, setShow] = useState(false)

	return (
		<div>
			<button onClick={() => setShow(true)}>Show</button>
			{show ? <input /> : null}
		</div>
	)
}
```

Suppose you want to focus the input as soon as it appears. You might try this:

```tsx
function MyComponent() {
	const inputRef = useRef<HTMLInputElement>(null)
	const [show, setShow] = useState(false)

	return (
		<div>
			<button
				onClick={() => {
					setShow(true)
					inputRef.current?.focus() // This probably won't work!
				}}
			>
				Show
			</button>
			{show ? <input ref={inputRef} /> : null}
		</div>
	)
}
```

But this doesn't work! Why? Because when you call `setShow(true)`, React
_schedules_ the update, but doesn't apply it until after your handler finishes.
So when you try to focus the input, it doesn't exist in the DOM yet.

## Why not just use setTimeout or requestAnimationFrame?

Early in my career, I tried to work around this by wrapping my focus call in a
`setTimeout` or `requestAnimationFrame`. Sometimes it worked, sometimes it
didn't. The timing depended on the device, the browser, and what else was
happening in the app. It was unreliable and hacky.

```tsx
onClick={() => {
	setShow(true)
	setTimeout(() => {
		inputRef.current?.focus()
	}, 10) // 🤞
}}
```

But this is a guessing game. You don't want to rely on magic numbers or hope
that the browser is fast enough. You want a guarantee.

## Enter `flushSync`

[`flushSync`](https://react.dev/reference/react-dom/flushSync) from `react-dom`
is your escape hatch. It tells React: "Hey, I know you like to batch updates for
performance, but I need you to process this update _right now_." Any state
updates inside the `flushSync` callback are applied immediately, so the DOM is
up-to-date as soon as the callback finishes.

Here's how you'd use it:

```tsx
import { flushSync } from 'react-dom'

function MyComponent() {
	const inputRef = useRef<HTMLInputElement>(null)
	const [show, setShow] = useState(false)

	return (
		<div>
			<button
				onClick={() => {
					flushSync(() => {
						setShow(true)
					})
					inputRef.current?.focus()
				}}
			>
				Show
			</button>
			{show ? <input ref={inputRef} /> : null}
		</div>
	)
}
```

Now, when you click the button, the input appears and is immediately focused. No
hacks, no guessing, just reliable focus management.

## Real-world example: EditableText

Let's look at a more practical example from the
[Epic React Advanced React APIs workshop](https://www.epicreact.dev/workshops/advanced-react-apis/).
This specific component was borrowed from
[Ryan Florence](https://x.com/ryanflorence) (thanks Ryan!). We have an
`<EditableText />` component that lets users edit a piece of text inline. When
the user clicks the button, it turns into an input. When they submit, blur, or
hit escape, it turns back into a button. We want to:

- Focus the input and select its text when editing starts
- Return focus to the button when editing ends (by submit, blur, or escape)

Here's how we do it:

```tsx
import { useRef, useState } from 'react'
import { flushSync } from 'react-dom'

function EditableText({
	initialValue = '',
	fieldName,
	inputLabel,
	buttonLabel,
}: {
	initialValue?: string
	fieldName: string
	inputLabel: string
	buttonLabel: string
}) {
	const [edit, setEdit] = useState(false)
	const [value, setValue] = useState(initialValue)
	const inputRef = useRef<HTMLInputElement>(null)
	const buttonRef = useRef<HTMLButtonElement>(null)

	return edit ? (
		<form
			onSubmit={(event) => {
				event.preventDefault()
				flushSync(() => {
					setValue(inputRef.current?.value ?? '')
					setEdit(false)
				})
				buttonRef.current?.focus()
			}}
		>
			<input
				required
				ref={inputRef}
				type="text"
				aria-label={inputLabel}
				name={fieldName}
				defaultValue={value}
				onKeyDown={(event) => {
					if (event.key === 'Escape') {
						flushSync(() => {
							setEdit(false)
						})
						buttonRef.current?.focus()
					}
				}}
				onBlur={(event) => {
					flushSync(() => {
						setValue(event.currentTarget.value)
						setEdit(false)
					})
					buttonRef.current?.focus()
				}}
			/>
		</form>
	) : (
		<button
			aria-label={buttonLabel}
			ref={buttonRef}
			type="button"
			onClick={() => {
				flushSync(() => {
					setEdit(true)
				})
				inputRef.current?.select()
			}}
		>
			{value || 'Edit'}
		</button>
	)
}
```

This approach ensures that focus is always exactly where the user expects it to
be, no matter how quickly they interact with the UI.

## Keyboard accessibility: Not just for some users

Why go to all this trouble? Because keyboard accessibility matters for everyone.
Some users rely on the keyboard due to disabilities, but many power users (like
me and probably you!) just prefer it. If your focus management is broken,
keyboard navigation becomes frustrating or impossible. Good focus management
means:

- When you tab into the editable text, pressing Enter or clicking it should
  focus the input and select the text.
- When you finish editing (by submitting, blurring, or pressing Escape), focus
  should return to the button so you can keep tabbing through the UI.

This is the kind of polish that makes your app feel great for everyone.

## When should you use `flushSync`?

- **Focus management**: When you need to move focus to an element that only
  exists after a state update.
- **Third-party integrations**: When you need to coordinate React updates with
  browser APIs or other libraries that expect the DOM to be updated immediately
  (e.g., `onbeforeprint`).

But be careful! [`flushSync`](https://react.dev/reference/react-dom/flushSync)
is a performance de-optimization. Use it sparingly and only when you really need
synchronous DOM updates. Most of the time, React's normal async updates are
exactly what you want.

## Wrap-up

Focus management is a subtle but critical part of building accessible,
delightful React apps. `flushSync` is a powerful tool for those rare cases when
you need to break out of React's normal update flow and make something happen
_right now_. Use it wisely, and your users will thank you.

Want to learn more? Check out the
[official flushSync docs](https://react.dev/reference/react-dom/flushSync) and
the
[Epic React Advanced React APIs workshop](https://www.epicreact.dev/workshops/advanced-react-apis/).


Master focus management in React with flushSync. Learn why batching matters, when to use flushSync, and how to create accessible, keyboard-friendly UIs.


Mastering Focus Management in React with `flushSync`

# 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

If you've been building for the web for a while, you probably remember the days
when making a page interactive meant sprinkling `<script>` tags throughout your
HTML, hoping everything loaded in the right order, and wrestling with global
variables. If you wanted a dynamic search box or a fancy dropdown, you'd either
write a bunch of jQuery or wire up some custom JavaScript, and then cross your
fingers that it played nicely with your backend-rendered HTML.

Fast forward to today, and React's new Server Components model takes a
completely different approach. Now, you can compose your UI out of both server
and client components, letting each do what it does best. And the best part? You
get to include interactive client components _right in your server-rendered
UI_—no script tag gymnastics required.

Let's dig into why this is such a big deal, and how it works in practice.

## The Old Way: Script Tag Soup

Back in the day, if you wanted a page that showed a list of products (rendered
on the server) and let users filter them with a search box (handled on the
client), you'd end up with something like this:

```html

<input type="search" id="search" />
<ul id="products">
	<li>Product 1</li>
	<li>Product 2</li>
	
</ul>


<script src="/static/search.js"></script>
<script>
	window.initSearch({ selector: 'ul' })
</script>
```

You had to make sure your scripts loaded after the HTML, and that your
JavaScript could find and hook into the right DOM nodes. If you wanted to pass
data from the server to the client, you'd often have to serialize it into a
`<script>` tag or a `data-*` attribute. It worked, but it was fragile and hard
to scale.

## The React Server Components Way: Seamless Composition

With React Server Components (RSCs), you can build your UI as a tree of
components, some of which run on the server (fetching data, rendering markup),
and some of which run on the client (handling interactivity, managing state).
The magic is that you can _compose_ these together—server components can render
client components as children, and everything just works.

Here's what that looks like in practice:

```jsx
// Server component
import { SearchBox } from './search-box.js' // a client component

export default async function ProductList() {
	const products = await fetchProductsFromDatabase()
	return (
		<div>
			<SearchBox>
				<ul>
					{products.map((product) => (
						<li key={product.id}>{product.name}</li>
					))}
				</ul>
			</SearchBox>
		</div>
	)
}
```

The `SearchBox` is a client component—maybe it uses state, effects, or context.
But you can include it directly in your server-rendered UI. No need to wire up
script tags or global variables. React takes care of sending just the code
needed for `SearchBox` to the client, and hydrates it so it's fully interactive.

## Why This Is Awesome

- **No More Script Tag Indirection:** You don't have to manually connect your
  server-rendered HTML to your client-side code. Just compose components.
- **Encapsulation:** Each component (server or client) owns its own data
  fetching, state, and logic. No more prop drilling or global variables just to
  get data where it needs to go.
- **Performance:** Only the interactive bits get sent to the client as
  JavaScript. The rest is just HTML, streamed from the server. Less JS = faster
  loads.
- **Streaming and Suspense:** You can use React's streaming and Suspense
  features to show loading states for slow data, and have parts of your UI load
  in as they're ready. This used to be a nightmare with traditional server
  rendering.

## A Real Example: Ships, Search, and Streaming

In the
[EpicReact.dev Server Components workshop](https://www.epicreact.dev/workshops/react-server-components/intro-to-server-components),
we build a UI that lets users search for spaceships and view details. Here's how
the composition works:

- The **server component** fetches the list of ships and renders the overall
  layout.
- The **client component** handles the search box, managing its own state and
  updating the UI as the user types.
- When the user searches, the server streams back the updated list, and the
  client component stays interactive the whole time.

No script tags. No manual hydration. Just components.

## Juxtaposition: How Far We've Come

Let's compare the two approaches:

| Old Way (Backend Framework)            | React Server Components                  |
| -------------------------------------- | ---------------------------------------- |
| Server renders HTML                    | Server renders UI (as React elements)    |
| Client JS finds DOM nodes              | Client components are included directly  |
| Data passed via script tags or data-\* | Data fetched where it's needed           |
| Manual hydration                       | Automatic hydration of client components |
| Hard to scale, fragile                 | Encapsulated, composable, robust         |

## Bonus: No More Prop Drilling

One of the biggest pain points in React apps has always been prop
drilling—passing data through layers of components just to get it where it's
needed. With RSCs, you can fetch data _right where you need it_ (thanks to async
server components), and you can use platform features like Node's
`AsyncLocalStorage` to avoid prop drilling for global values. (Check out the
[workshop exercise on this](https://www.epicreact.dev/workshops/react-server-components/server-context)
for more.)

## Conclusion

Composing server and client components together is the modern React's
superpower. You get the best of both worlds: fast, data-rich UIs from the
server, and rich interactivity from the client—without the pain of the old days.
If you haven't tried building with React Server Components yet, now's the time.
Your future self (and your users) will thank you.

---

_Want to learn more? Check out the
[EpicReact.dev Server Components workshop](https://www.epicreact.dev/workshops/react-server-components)
for hands-on exercises and deep dives into these concepts._

How React's new model lets you build interactive, data-rich UIs without the pain of old-school script tags and prop drilling.

Compound Components: Truly Flexible React APIs

What and Why: Compound Components in React

Real-World Impact & When to Use

Get my free 7-part email course on React!

More Articles

Use CSS Variables instead of React Context

Mastering Focus Management in React with `flushSync`

Just Use React

Composing Server and Client Components: The Modern React's Superpower