❌ Stop Returning 200

One habit that makes debugging APIs much harder is returning HTTP 200 OK for every request.

An HTTP status code tells the client what happened before it even reads the response body.

Examples:
200 → Success
201 → Resource created
400 → Client sent invalid data
401 → Authentication required
403 → Authenticated, but not allowed
404 → Resource doesn't exist
500 → Server failed unexpectedly

If every response is 200, frontend developers have to inspect every response body just to know whether something failed.

Let HTTP do its job. That's what it was designed for.

Why React Hydration Exists

When a server sends HTML to your browser, the page already looks complete before any JavaScript finishes loading.

But looks can be misleading. Buttons don't respond. Forms don't submit. Dropdowns don't open.

Hydration is the process where React attaches JavaScript to that existing HTML, making it interactive instead of rebuilding the page from scratch.

This is also why JavaScript bundle size matters so much. The browser can't hydrate components until it has downloaded, parsed, and executed their JavaScript.

That's why modern frameworks push more work to the server. Not because JavaScript is bad, but because sending less of it usually means users can interact with the page sooner.

📌 React Isn't the Problem

A React app doesn't become slow overnight. It becomes slow when unnecessary render accumulates overtime.

A render is React running a component again to determine what should appear on the screen.

Most developers reach for useMemo, useCallback, or another optimization as soon as performance drops. That's often treating the symptom.

The better question is:
Why did this component render in the first place?

Open React DevTools and enable Highlight updates. Click around your app.

If your navigation bar flashes every time you type into a search box, you've already found a performance issue.

Your useEffect Might be Doing Too Much

An effect is code that runs after React updates the screen, usually for interacting with things outside React.

Examples: Fetching data, Subscribing to events, Updating the document title.

The problem starts when developers use it for normal calculations.

Example:

useEffect(() => {
  setTotal(price * quantity)
}, [price, quantity])

This creates unnecessary work. total can already be calculated during rendering.

The effect adds another state update, another render, and another thing to debug.

A useful question:

Does this code synchronize with something outside React?

If not, it probably doesn't belong inside useEffect.

📘 You Don't Know JS Yet: Async & Performance

✍️ Author: Kyle Simpson

🗓 Year: 2015

📄 Pages: 296

🧠 No matter how much experience you have with JavaScript, odds are you don't fully understand the language. As part of the "You Don't Know JS" series, this concise yet in-depth guide focuses on new asynchronous features and performance techniques - including Promises, generators, and Web Workers - that let you create sophisticated single-page web applications and escape callback hell in the process.

#JavaScript