[Ricky Hanlon posted on Bluesky](https://bsky.app/profile/ricky.fm/post/3lpi3jj3jqc2s):

> what's wrong with this code:
>
> ```jsx
> if (props.wrap) {
> 	return <Wrapper>{children}</Wrapper>
> }
>
> return children
> ```

A lot of people didn't get it right away. In fact, it took me a moment thinking
about it as well, but then
[I replied](https://bsky.app/profile/kentcdodds.com/post/3lpi4rbteqs2g):

> Does it have to do with what happens when the wrap prop changes?

He said "Yes" and I knew for sure what he was talking about.

Have you ever wondered why your React component's state sometimes disappears or
resets unexpectedly? Or why two identical components don't share state? React's
approach to state is all about _where_ a component sits in the UI tree, not just
what it is. This means that state is preserved as long as the same component is
rendered at the same position—but if you swap components, change their keys, or
move them around, React may reset their state.

A common pitfall: toggling between two components (like two players in a
scoreboard) using different keys or types will reset their state every time you
switch. This is often _not_ what you want, especially if you expect the UI to
"remember" previous input or progress. The React docs show how this can trip you
up, and why relying on position and keys for state can be sub-optimal if you're
not careful.

If you've ever been surprised by disappearing form input or state that doesn't
persist the way you expect, this article is for you. It covers:

- How React decides when to preserve or reset state
- The role of keys and component types
- Practical tips for controlling state resets (and when you might want them!)

Curious to learn more and see code examples? Check out the full article:
[Preserving and Resetting State – React Docs](https://react.dev/learn/preserving-and-resetting-state)

### Spoiler Alert: How to Fix It

For Ricky's example specifically, if you want to preserve state while toggling
the wrapper, you need to ensure the component tree structure remains stable. One
way is to always render the `Wrapper`, but conditionally apply styling or
behavior:

```jsx
return (
	<Wrapper style={props.wrap ? {} : { display: 'contents' }}>
		{children}
	</Wrapper>
)
```

Or, if you want to avoid an extra DOM node when not wrapping, you can use a key
to intentionally reset state, or lift state up to a parent component so it isn't
lost when the tree changes. The key is to avoid swapping between two different
component trees at the same position if you want to preserve state.

But really, you should just read
[the whole article](https://react.dev/learn/preserving-and-resetting-state).


How React preserves or resets state depends on component position and keys. Learn why state disappears and how to fix it as well as links to more resources!

Preserving and Resetting State in React

Here's a form in `JSX`:

```jsx
function UsernameForm({onSubmitUsername}) {
  function handleSubmit(event) {
    event.preventDefault()
    onSubmitUsername(event.currentTarget.elements.usernameInput.value)
  }

  return (
    <form onSubmit={handleSubmit}>
      <div>
        <label htmlFor="usernameInput">Username:</label>
        <input id="usernameInput" type="text" />
      </div>
      <button type="submit">Submit</button>
    </form>
  )
}
```

Let's type that `handleSubmit` function. Here's how some people do it (copying this approach from some blog posts and "semi-official guides" I've seen):

```tsx
function handleSubmit(event: React.SyntheticEvent<HTMLFormElement>) {
  event.preventDefault()
  const form = event.currentTarget
  const formElements = form.elements as typeof form.elements & {
    usernameInput: {value: string}
  }
  onSubmitUsername(formElements.usernameInput.value)
}
```

The reason we have to have the `as` there is because TypeScript isn't quite smart enough to know what elements we're rendering in our form, so we have to use the type cast which I'm not a fan of, but you gotta ship right?

My first improvement to this is to change that `usernameInput` type:

```diff
-     usernameInput: {value: string}
+     usernameInput: HTMLInputElement
```

Definitely take advantage of the type it actually is rather than just cherry-picking the values you need.

The second improvement is:

```diff
- function handleSubmit(event: React.SyntheticEvent<HTMLFormElement>) {
+ function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
```

Incidentally, at the time of this writing, there's no substantive difference in those types, but I prefer to be more clear and accurate with the name of the type, so that's what we're going to go with.

So here we are now:

```tsx
function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
  event.preventDefault()
  const form = event.currentTarget
  const formElements = form.elements as typeof form.elements & {
    usernameInput: HTMLInputElement
  }
  onSubmitUsername(formElements.usernameInput.value)
}
```

But even with those changes, I'm not a fan of this for three reasons:

1. It's a bit verbose and distracts from the main purpose of the function 2. If I need to use that `form` anywhere else, I'll either have to duplicate the    code or extract the type and cast it everywhere I use the form. 3. I don't like seeing `as` in my code because it is a signal that I'm telling    the TypeScript compiler to pipe down (be less helpful). So I try to avoid it    when possible. And it is possible!

Keep in mind that _we're_ the ones telling TypeScript what that `event.currentTarget` type is. We tell TypeScript when we specify the type for our `event`. Right now that's set to `React.FormEvent<HTMLFormElement>`. So we're telling TypeScript that `event.currentTarget` is an `HTMLFormElement` but then we immediately tell TypeScript that this isn't quite right by using `as`. What if instead we just tell TypeScript more accurately what it is at the start? Yeah, let's do that.

```tsx
interface FormElements extends HTMLFormControlsCollection {
  usernameInput: HTMLInputElement
}
interface UsernameFormElement extends HTMLFormElement {
  // now we can override the elements type to be an HTMLFormControlsCollection
  // of our own design...
  readonly elements: FormElements
}
```

So in reality, our `form` is an `HTMLFormElement` with some known `elements`. So we extend `HTMLFormElement` and override the `elements` to have the elements we want it to. The `HTMLFormElement['elements']` type is a `HTMLFormControlsCollection`, so make our own version of that interface as well.

With that, now we can update our type and get rid of all the type casting!

Here's the whole thing altogether:

```tsx
import * as React from 'react'

interface FormElements extends HTMLFormControlsCollection {
  usernameInput: HTMLInputElement
}
interface UsernameFormElement extends HTMLFormElement {
  readonly elements: FormElements
}

function UsernameForm({
  onSubmitUsername,
}: {
  onSubmitUsername: (username: string) => void
}) {
  function handleSubmit(event: React.FormEvent<UsernameFormElement>) {
    event.preventDefault()
    onSubmitUsername(event.currentTarget.elements.usernameInput.value)
  }

  return (
    <form onSubmit={handleSubmit}>
      <div>
        <label htmlFor="usernameInput">Username:</label>
        <input id="usernameInput" type="text" />
      </div>
      <button type="submit">Submit</button>
    </form>
  )
}
```

So now:

1. the type information is removed from the `handleSubmit` code, allowing us to    focus on what the function is doing. 2. If we need to use this `form` somewhere else, we can give it the    `UsernameFormElement` type and get all the type help we need. 3. We don't have to use a type cast, so TypeScript can be more useful for us.

I hope that's helpful to you!

Excellent TypeScript definitions for your React forms

How to type a React form onSubmit handler

When I started at PayPal, the app I started with used Redux for its state management (like pretty much every other React app at the time). This was the first React product I'd ever worked on and I was excited to use the latest and greatest tools for state management. Unfortunately it wasn't long before I realized that Redux had some serious shortcomings and I haven't used it since.

However, this blog post isn't about Redux.

After working on that app, I had the privilege to work on the team that would rewrite [paypal.me](https://paypal.me/kentcdodds/💰) (🤑) from the ground up. As a team we knew we didn't want to use Redux, but we automatically assumed we would need _something_ to manage state, so we began the search. We eventually found a library that we thought would work out pretty well.

It did not.

I mean, it wasn't a disaster or anything, but unfortunately after a while, it was difficult for any of us to make sense of the app state. And it wasn't the fault of the library we chose. Frankly, what happened was we decided to avoid Redux, but then grabbed another library and made the same mistakes that made Redux such a problem: **Almost all state was globally managed by the library.**

So what should we have done? If I could go back in time and could only say one thing, here's what I would say:

> Server cache is not the same as UI state, and should be handled differently.

What happened to me for pretty much every app I wrote up until even this year was that I would take the data I got from the server and treat it like it was UI state. I would mix it in with the actual UI state (stuff that's not persisted. You know, the stuff that goes away when you refresh the page), and this resulted in making _both_ more complex. I would try and fail at state synchronization. Found myself in "impossible" states that were difficult to debug.

## So what now?

Honestly, if I really could go back in time and meet myself, in addition to the one thing I said, I would hand myself a flash drive with a copy of https://github.com/tannerlinsley/react-query on it (with instructions to give it to [Tanner](https://twitter.com/tannerlinsley) along with a thank you note). [React Query](https://react-query.tanstack.com/) is simply the perfect abstraction that can handle the server cache for me. It gives me all the right knobs to twist to set my caching strategy up just right.

And once my server cache is handled so perfectly by react-query, I don't have enough state left to feel like I need a library for the rest of it. React is a state management solution and it's a really good one when you componentize your state like you do your UI.

Honestly, paypal.me was a small enough app that I wish we had embraced that (given react-query didn't exist). I think the state would have been easier to maintain had we colocated our state a little better.

Luckily, now we have react-query, React hooks, and a brilliant context API and that's all most applications will ever need for server cache and UI state management. I love it. And I'll teach you all about it on [EpicReact.Dev](https://epicreact.dev) 🚀 

It wasn't a library. It was the way I was thinking about and defining state.

My State Management Mistake

React is a JavaScript library for creating user interfaces and managing user interactions. React is used primarily for building web applications in browsers, but the component model is so powerful that it can be used to create native mobile and desktop applications, images, PDFs, terminal applications, and much more.

As a result of React’s success with the component-based model of interface composition, many other UI libraries and frameworks have adopted this approach with their own flare. However, React has been *(by a large margin)* **the dominant way** to build user interfaces for many years now and will likely remain that way as long as you or I continue to develop software on the web.

Let’s go a little deeper and look at the pieces that make up React.

## React’s core building block

The foundational component of user interfaces built with React are elements:

```tsx
import { createElement } from 'react'

const element = createElement('button', { onClick: () => console.log('clicked!') }, 'Click me!')
```

If we inspect the element that React’s created, it looks like this:

```tsx
{
  "$$typeof": Symbol(react.element),
  "type": "button",
  "key": null,
  "ref": null,
  "props": {
    "onClick": () => console.log('clicked!'),
    "children": "Click me!"
  },
  "_owner": null,
  "_store": {}
}
```

This object (which I call a “UI descriptor”) is used to generated UI that’s native to the environment it’s rendered in. In our case we want to generate UI for the browser, so we use the React DOM package to convert this UI into DOM nodes that the browser can understand.

This separation between React elements and DOM elements is part of what makes your React knowledge (or even code) portable to environments other than the browser.

## JSX

Using the `createElement` API directly is not very ergonomic, so when React was initially announced it came with a special lightweight syntax addition to JavaScript to make it easier to create elements. With that syntax, you can create that same button like this

```tsx
const element = <button onClick={() => console.log('clicked!')}>Click me!</button>
```

Because this is a syntax addition that browsers don’t natively run, you need to compile your code before the browser can interpret it. You can technically do this right in the browser (I built an app I used daily for years that did things this way actually), but it’s not optimal.

In most apps, you’ll be using a tool to convert your JavaScript anyway. You’ll at least want a minifier to reduce the amount of text you send over the network and likely a bundler to reduce the number of files the browser has to load. On top of this, especially in anything serious, you’ll want to use TypeScript which supports JSX natively.

Writing UI in this way is delightful. It takes most developers just a few hours of study and practice to understand how JSX translates to regular JavaScript, then you can be highly effective working in the syntax because it’s basically just JavaScript anyway.

## Reusable elements: Components

As React is written in JavaScript, you can of course create parameterized functions which return React elements. React has formalized this in something called a component and it’s how you can create custom React elements. To top it off, you can parameterize these components using something called “props” which is an object received by your component:

```tsx
function ClickMeButton(props) {
  return <button onClick={props.onClick}>Click me!</button>
}
```

You can then create that element like other elements:

```tsx
const element = <ClickMeButton onClick={() => console.log('clicked!')} />
```

Here’s what that element object looks like:

```tsx
{
  "$$typeof": Symbol(react.element),
  "type": ClickMeButton,
  "key": null,
  "ref": null,
  "props": {
    "onClick": () => console.log('clicked!')
  },
  "_owner": null,
  "_store": {}
}
```

When React is ready to render this UI, it will call your function with the props to retrieve the other elements it needs to render.

This API enables React components to compose together in beautifully powerful ways that a decade later we’re still benefitting from. It enables us to build highly reusable abstractions. For example, you could package up all the accessibility requirements for a tabs UI in a couple components that work together and offer something like this:

```tsx
<Tabs defaultValue="account">
  <TabsList>
    <TabsTrigger value="account">Account</TabsTrigger>
    <TabsTrigger value="password">Password</TabsTrigger>
  </TabsList>
  <TabsContent value="account">Make changes to your account here.</TabsContent>
  <TabsContent value="password">Change your password here.</TabsContent>
</Tabs>
```

Composition is the name of the game when it comes to React, even between server-only code which generates the UI and client-side code which makes the UI interactive. Speaking of making the UI interactive…

## Updating UIs with React

React not only helps you generate the initial UI, but also manage changes to that UI over time. Whether you’re building an interactive experience for users, or a dashboard that updates in the background, React will help you keep your UI up-to-date.

Data is used to generate the UI. When that data can change over time, we call it state. In React, you can manage this state a number of ways, but the primary mechanism is via a function called `useState` . This function can only be used within custom components so React knows what UI to update when the state changes:

```tsx
function Counter() {
  const [count, setCount] = useState(0)
  const increment = () => setCount((c) => c + 1)
  return <button onClick={increment}>Current Count: {count}</button>
}
```

Whenever the user clicks the button, `setCount` is called which notifies React that the state value needs to be changed and React needs to retrieve the new elements based on that new value.

As mentioned, there are several ways to manage state built-into React, but the basic idea is always the same: an update happens, React calls the component again with the updated value, React compares what you return this time with what was returned last time and updates the DOM accordingly. In our case the `textContent` of the `button` will be updated each time the button is clicked.

## So, what is React?

Like I said at the start, React is a JavaScript library for creating user interfaces and managing user interactions. There are of course more things to talk about when it comes to building web applications with the most widely used tool in the business with the biggest ecosystem, but this is as far as we’ll take it today.

I’m going to be publishing a lot of articles diving deeper in these aspects and others (so sign up to be notified when they become available!).

React has evolved over the last more than decade since its original release, but the core concept of composability has remained and been pushed further and further over the years. I’ve never been more excited about building applications with React and it just keeps getting better. Thanks for joining me for the ride!

Let's contextualize the most widely used UI framework in the world: React.

Whether you're brand new to building dynamic web applications or you've been working with React for a long time, let's contextualize the most widely used UI framework in the world: React.

What is 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)**


Preserving and Resetting State in React

Spoiler Alert: How to Fix It

Get my free 7-part email course on React!

More Articles

How to type a React form onSubmit handler

My State Management Mistake

What is React?

Just Use React