DEV Community: Omaima Ameen

what i learned intentionally breaking hydration in next.js

Omaima Ameen — Tue, 30 Jun 2026 03:40:14 +0000

i did something dumb last month. on purpose.

i sat down, opened a next.js app, and tried to make hydration fail in every way i could think of. not because a bug forced me to. not because i was debugging something. just because i wanted to see it. understand it from the inside.

and honestly? best few hours i've spent learning anything in a while.

why i even did this

you know how you use something for months and you think you get it, but you don't really get it? hydration was that for me. i knew the surface-level thing: server renders HTML, client takes over, they gotta match. cool. got it. moving on.

except i didn't get it. i just got the vibe of it.

every time i saw hydration mismatch, i'd ask claude, fix the immediate thing, feel vaguely annoyed, and move on. i never stopped to ask why that specific thing broke it. i was treating symptoms, not understanding the actual disease.

so i decided to break it deliberately. if i caused the errors myself, i'd actually have to understand what i was doing.

the setup

basic next.js app. app router. a few pages. nothing fancy.

i wasn't trying to build anything. i was trying to destroy something, carefully, so i could see what fell apart and why.

break #1: the obvious one - new Date() on render

this is the classic. everyone's seen it.

export default function Page() {
  return <div>{new Date().toLocaleString()}</div>
}

server renders this at, say, 14:00:00. by the time react runs on the client and tries to reconcile, it's 14:00:01. the strings don't match. react screams.

thing is, i knew this would happen. what i didn't think about was why react cares.

here's the thing: react isn't doing a full diff on the entire DOM after hydration. it's trusting that the server HTML is a valid starting point and it's just attaching event listeners and state to it. but if the content doesn't match, it doesn't know what to trust. it can't partially hydrate "mostly correct" HTML. it either matches or it doesn't.

so it throws the warning, and in some cases actually re-renders the whole thing client-side. you just wasted your server render.

what i actually learned: hydration isn't "react rechecks everything." it's react skipping the DOM creation step entirely and just walking the existing DOM to attach fiber nodes. mismatch breaks that walk.

break #2: typeof window !== 'undefined' used wrong

this one's sneaky. i see this pattern everywhere.

export default function Page() {
  const isClient = typeof window !== 'undefined'
  return <div>{isClient ? 'client' : 'server'}</div>
}

server: window doesn't exist -> renders "server"

client: window exists -> renders "client"

mismatch. every time.

the fix people reach for is useEffect:

const [isClient, setIsClient] = useState(false)
useEffect(() => setIsClient(true), [])

but here's what clicked for me when i broke it intentionally: the reason useEffect fixes it is that the first render on the client still returns false. it matches the server. then after hydration completes, useEffect fires, state updates, component re-renders. by that point, react is done hydrating and owns the DOM. it can do whatever.

that timing is doing a lot of work. it's not a hack. it's actually the intended mental model - first render matches server, then client takes over.

break #3: rendering random values

export default function Page() {
  return <div data-id={Math.random()}>{Math.random()}</div>
}

i expected the hydration warning. i got it. but what surprised me was opening the react devtools and watching what actually happened.

react renders the component on the client. it walks the server-rendered DOM. it finds the div. the text content doesn't match. instead of partially fixing it, it flags the whole subtree.

in dev mode you get the warning. in production? react just silently fixes it by replacing the server content with the client render. no error. no nothing. you'd never know unless you were watching the network tab and noticed your carefully SSR'd HTML was being thrown away immediately.

that was kind of unsettling actually.

break #4: reading from localStorage on first render

export default function Page() {
  const theme = localStorage.getItem('theme') || 'light'
  return <div className={`theme-${theme}`}>hello</div>
}

this one doesn't just mismatches - it crashes. localStorage doesn't exist on the server. you get a reference error before react even gets a chance to complain about hydration.

but the lesson here was different. it made me think about what "server" actually means in this context. people say "the server doesn't have localStorage" like it's a gotcha fact. but why? because the server is node. node doesn't implement browser APIs. it's not a browser. it's just a JavaScript runtime that can render react components to a string.

when you think about it that way, the rule becomes obvious instead of arbitrary. don't use browser APIs in code that runs on the server. window, document, localStorage, navigator - all of these are browser things. next.js might be doing SSR but the "S" is still a server.

break #5: conditional rendering based on props that differ server/client

this one was more subtle.

// some parent component
<UserCard showEmail={Math.random() > 0.5} />

the prop itself is random. so the server might render the email field, the client might not (or vice versa). the child component is "correct" in isolation but the inputs it's receiving are inconsistent.

i'd never thought about hydration errors being caused outside the component that shows the error. react points at the component that rendered the mismatched output, but the actual bug is in the parent.

this one burns people in the wild when they're doing things like passing Date.now() as a prop, or any calculation that produces different values between server and client execution.

the part that actually messed with my head

at some point i started reading through how react's hydration works internally. like actually reading the source, not just blog posts.

react has this function hydrateRoot. when you call it, react starts a "hydration pass" where instead of creating new DOM nodes, it reads existing ones. it's walking your real DOM and building its fiber tree from the DOM, not to the DOM.

but here's the thing - it still runs your component functions. it still calls useState, useEffect setup (well, in terms of registering effects), all of it. it just doesn't write any DOM.

except when there's a mismatch. then it has to write DOM. and it has to figure out what to write, because the existing DOM is wrong. which means in a bad case, hydration is actually more expensive than a fresh client render because it tries the fast path first, fails, and then falls back to the slow path anyway.

i genuinely did not know this before i started breaking things.

break #6: using suppressHydrationWarning everywhere

okay this one was me being chaotic.

<div suppressHydrationWarning>
  {Math.random()}
</div>

this is a real prop. it tells react "i know this might not match, don't warn me." it's meant for timestamps, dynamic ids, things like that.

i started slapping it everywhere to see what would happen. and the answer is: everything looks fine. no warnings. but the content is still wrong. react silently accepts the server content for those nodes and doesn't re-render them from the client. so if you're using this as a way to "fix" hydration mismatches on important content, you're not fixing anything. you're just hiding it.

the actual content on screen is whatever the server rendered. if that's stale, it stays stale until something triggers a re-render.

what breaking things taught me that reading docs didn't

docs tell you the what. "hydration mismatch occurs when server and client render different content." yeah, i knew that.

breaking things showed me the how and why:

hydration is a read-then-attach operation, not a render-then-replace
the first client render must match the server render, always, no exceptions
useEffect is specifically useful here because it runs after hydration completes
production hides a lot of pain that dev mode surfaces as warnings
the error often points to the symptom, not the cause

i think there's something genuinely underrated about intentionally making things break. not finding bugs by accident. deliberately causing failures to understand what the system's failure modes are.

it's a different kind of learning. you're not reading about edge cases. you're creating them.

one thing i'd try next

i want to do the same thing with suspense + streaming SSR. intentionally break the boundary conditions, see when react flushes what, figure out the actual mental model instead of the "here's when you'd use " tutorial version.

probably gonna do it this week if i stop getting distracted by other things.

(okkay i won't stop getting distracted, but i'll try.)

A beginner-friendly mental model of HTTP, HTTPS and how the web communicates

Omaima Ameen — Thu, 14 May 2026 04:11:36 +0000

Hiee🥂!!
Lately I’ve been diving deep into web internals and honestly the deeper I go, the crazier it feels.

So I thought of documenting whatever I’m learning and understanding along the way , not as an expert, but as a curious developer trying to connect the dots.
This is one of those notes.

I know there’s already a lot of content on HTTP and web architecture out there, but I still wanted to write this because writing things in my own words helps me understand them better

Will probably keep writing more about web internals, React internals and low-level web stuff as I learn :)

(Note that Networking goes wayyy deeper than this ,this is just me trying to understand and explain the core ideas in simple human language while learning)

So here we goo,

Every time we open a website, click a button or log into an app, there’s a silent conversation happening between the client and the server.

HTTP is basically the medium that makes this conversation possible.

Its through which client and server talks to each other as a means of request , as the name suggests already that request means asking something from someone , and response again as the name suggests its giving an answer to someone’s call (in this case the request’s call)

So a request is basically asking something from the server , and the response is what the server gives us (client) in the form of whatever we intend to see on the internet.

I hope you get the idea right..don't you?

Now what exactly is HTTP?

It’s a protocol , basically a defined set of rules for how requests and responses should happen between the client and the server.
And a request message usually looks something like this:

Request Line Headers Optional Message Body

alright?

Now obviously every request to the server cannot mean the same thing :}

Sometimes you want to fetch data.
Sometimes you want to create something.
Sometimes, update it.
Sometimes delete it.
So for that, HTTP provides different methods to tell the server what action the client actually wants to perform.

Some common HTTP methods are:

GET
POST
PUT
PATCH
DELETE
HEAD
OPTIONS
TRACE
CONNECT

For me, the most fascinating (and honestly crazy) thing was knowing that HTTP is a stateless protocol.

Meaning?

You send a request.
The server processes it.
Give a response.
And then suddenly…

“Who are you again?”

So in this case, you’d basically have to log in on every single page again and again because somehow the server has to remember the context of YOU, right? 😭

Like imagine opening Amazon.com, logging in, doing your shopping, ordering earpods, paying for them and everything is done,

then 2 hours later or maybe the next day , you open the app again and the website suddenly goes:

“Who are you babe?” 💀

Wouldn’t that be complete chaos?

There had to be something which could tell the server:
“ this is the same person, don’t you dare forget them ”

And that “noble job” is basically being done by Cookies and Session Storage.

Cookies: a small piece of text stored in the user’s device by the browser , which consists of name-value pairs containing bits of information about the user, so the web experience doesn’t reset every five seconds.

But remembering the user wasn’t the only challenge with HTTP
There was another problem too, speed and connection efficiency.

Pipelining, Multiplexing and the emergence of HTTPS

HTTP/1.0 was pretty straightforward:

One request.
One response.
Connection closed.

and then again,
new request = new connection setup every single time!!

which was obviously kinda slow and tiring.

So HTTP/1.1 introduced something called Pipelining.
Meaning?
The client could send multiple requests together without waiting for the previous response to arrive first.
Sounds cool, right?

but there was still a problem.

The server still had to return responses in order:
response 1 -> response 2 -> response 3 ...
So if request 1 became slow for some reason, the further requests had to wait too.

This problem was called HOL Blocking (Head Of Line Blocking).
and that’s where Multiplexing entered the chat !!

Multiplexing basically means sending and receiving multiple requests and responses simultaneously over the same connection.

Then came HTTP/2 which introduced proper multiplexing over a single connection along with header compression.

And later HTTP/3 came into the picture, running over UDP with faster connection setup and better performance during packet loss.

Then comes HTTPS (Secure HTTP).

Now obviously sending sensitive stuff like passwords, payment details and tokens in plain text over the internet would be a terrible idea💀

So HTTPS adds encryption to the communication between the client and the server.
Meaning?
Even if someone somehow intercepts the data in between, they still won’t be able to understand it.

Think of it like this

HTTP:
Client -> “my password is 12345” -> Network
HTTPS:
Client -> encrypted unreadable gibberish -> Network
Server -> decrypts -> “my password is 12345”

and behind the scenes, things like TLS and digital certificates help establish this secure communication channel.

That’s basically the core idea behind HTTPS.

the deeper I go into web internals, the crazier the internet starts feeling,

Like imagine billions of devices continuously talking to servers through requests, responses, protocols, encryption, cookies, packets and what not !!!

and somehow all of this works so smoothly that we casually open Instagram while eating chips :)

Just curious hat was the first web/internet concept that completely blew your mind?

(If I misunderstood something anywhere, I’d genuinely love corrections or deeper insights from y’all🙌)

[Boost]

Omaima Ameen — Sat, 09 May 2026 08:28:27 +0000

Unofficial invite-only group for creators

FrancisTRᴅᴇᴠ (っ◔◡◔)っ for The DEVengers

May 8

Welcome to the DEVengers Organization! A group of extraordinary individuals who have shaped Dev.to like no other! 🚀

#discuss #community #meta #programming

2 min read

(Avengers Already Warned You) CS Isn’t Dead. You’re Just Watching It Mutate

Omaima Ameen — Wed, 01 Apr 2026 13:54:58 +0000

Okay so let’s drop the fake motivation for a second.

The shift is real and yeah - it’s uncomfortable (as hell).

People are getting laid off.
Tools are evolving faster than we can even process.
Stuff that took weeks now takes hours.

and then someone casually says: just understand problems deeply bro

like that explains anything.

Zoom out for a second

10–15 years ago?

one smartphone per family, one computer in the whole locality, internet felt like a luxury

and still, the software industry was growing.

NOW?

Every person has a device
Every business runs on software
Entire economies are digital

and some people are saying:

“CS is dead”

that’s not just wrong ,that’s lazy thinking.

What’s actually happening?

Computer Science and technology is mutating into something we don’t fully have a name for (yet) and no this is not a “new tool” phase.
this is a new layer of reality being added.

Like avengers, it’s no longer just humans, it’s AI ,enhanced beings, agentic stuff , old rules stop applying

That’s where we are !!

The old definition of a “developer” is breaking.

Not slowly. Rapidly.

Earlier:

I can code = value

Now:

I can prompt, glue APIs, ship fast, leverage AI = baseline

and even that baseline is shifting every few months.

So yeah - if someone built their entire identity around:

syntax
frameworks
memorizing patterns

They will feel like the ground is disappearing.

because IT IS !!

People keep calling it “evolution”.

No.

This feels more like when Tony discovered JARVIS.

We’re not just improving workflows.

We’re changing:

how software is built
who can build it
how fast things move
what skill even means
Why the usual advice feels boring now

so now you need to:

adapt faster than tools change , unlearn aggressively , build with things you barely understand yet , stay calm when nothing feels stable

This wasn’t required before at this level.

basically you’re closer to Tony Stark in a lab than a traditional coder.

So what now?

Not “grind harder”.

Not “just learn DSA”.

Not “just build projects”.

That advice alone won’t cut it anymore.

What actually matters now:

Can you move with uncertainty without freezing?
Can you learn tools faster than they become obsolete?
Can you ship even when you don’t feel ready?
Can you stay in the game while others quit out of confusion?

Because that’s what’s filtering people right now.

Not intelligence.

Adaptability.

This phase is messy & undefined and bit scary ,exactly like every major shift ever.

but calling it “the death of CS” is just people panicking because:

the game they learned is not the game being played anymore.

The industry didn’t die, it just turned into something more powerful and harder to recognize.

and yeah, it does feel like Avengers.

not the calm parts.

the chaotic ones where nobody knows what’s going on,
but the people who stay in the fight end up shaping what comes next !!

let me know in the comments how you see this whole thing ?

[Boost]

Omaima Ameen — Fri, 16 Jan 2026 09:43:13 +0000

TheBitForge

Jan 10

Stop Overengineering: How to Write Clean Code That Actually Ships 🚀

#discuss #javascript #programming #webdev

41 min read

Freelancing was going fine… until

Omaima Ameen — Mon, 05 Jan 2026 07:39:54 +0000

Heyy geniuses
(don’t know if that’s the right word, but hoping at least two people read this )

So,
I’ve been freelancing for the past few months, mostly building conversion-focused websites and animations, and getting clients through LinkedIn and Instagram.

Everything was going fine… until curiosity kicked in.

For the last month or so, I’ve been wanting to understand how things actually work internally - not just what works, but why it works.

So alongside client work, I started digging into React internals, purely because it’s fun to know why things behave the way they do under the hood.
and honestly… it’s been pretty fun.

Just learning, building, breaking things, fixing them, and enjoying the process.

This is my first post here on Dev Community - mostly to see if my kind of people are around.

People who genuinely love code.
People who have something more interesting to say than “huhh AI will replace developers.”

Curious to know 👀
What’s been the real reward for you of posting here and being present in this community?