DEV Community: Omaima Ameen

I Built NextProof Because Resume Match Scores Weren't Enough.

Omaima Ameen — Mon, 19 Oct 2026 05:17:39 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Let's be honest. Job descriptions can feel like someone combined five different roles into one and called it an entry-level position. 💀

Then comes the resume-editing ritual.

You read the job description, look at your resume, rearrange a few things, add some keywords, and hope the recruiter sees the connection.

But here's the thing , matching keywords isn't the same as understanding whether your experience actually demonstrates what a role needs.

And sometimes, you might already have the experience. Your resume just isn't making that obvious.

That's why I built NextProof.

NextProof is an AI-powered resume analysis tool that compares your resume with a job description and helps you understand the relationship between the two.

Instead of stopping at a generic match score, it breaks the analysis into an overall assessment, strengths, gaps, and actionable next steps.

The idea is simple: help you understand what your resume demonstrates, where evidence might be missing, and what you can work on next.

Because there's a difference between not having a skill and not showing evidence of that skill on your resume.

I wanted to build something that takes that difference seriously.

Demo

Live: https://nextproof.onrender.com/

Upload a PDF or DOCX resume, paste a job description, and run an analysis. You can then explore the assessment, strengths, gaps, and suggested next steps.

The application is deployed on Render, with server-side API routes handling the analysis and feedback flows.

Code

GitHub: NextProof repository

Tech stack: Next.js · JavaScript · Tailwind CSS · Gemma · Google Gen AI SDK · Supabase · Render

How I Built It

Here's the high-level flow:

Resume (PDF / DOCX) + Job Description
                 |
                 v
        Validate the inputs
                 |
                 v
        Extract resume text
                 |
                 v
        Send context to Gemma
                 |
                 v
       Parse and validate output
                 |
                 v
        Structured analysis
                 |
       +---------+----------+
       |         |          |
       v         v          v
  Assessment  Strengths    Gaps
                            |
                            v
                        Next steps

          Feedback --> Supabase

The frontend is built with Next.js and JavaScript. The analysis API route handles file validation, text extraction, and communication with the model.

For document processing, I used pdf-parse for PDF resumes and mammoth for DOCX files. Both formats need to be converted into usable text before the analysis can begin.

The application uses the Google Gen AI SDK to access hosted Gemma inference. The API key stays on the server instead of being exposed in the browser.

The model's response is parsed and validated before being returned to the frontend. The results interface then presents the analysis through separate sections rather than making users dig through one giant block of generated text.

I also built a feedback flow backed by Supabase, allowing users to share their thoughts on the usefulness and accuracy of the analysis.

Finally, I deployed the application as a Next.js web service on Render, so the frontend and server-side API routes can run together.

Why Gemma?

The part I wanted to explore was how an open-weight model could help turn two pieces of text—a resume and a job description—into a structured analysis that someone could actually use.

A job description contains requirements. A resume contains a candidate's description of their experience. Connecting the two requires more than looking for identical words; it requires interpreting context and producing feedback that makes sense to the user.

That's the role Gemma plays in NextProof.

The model receives the extracted resume text and the job description as context and generates the analysis that powers the results experience.

The surrounding application is responsible for everything that makes this usable as a product: accepting files, validating inputs, extracting text, handling inference failures, validating the returned structure, and presenting the results.

Gemma provides the language understanding; the engineering around it turns that capability into a usable workflow.

I'm particularly interested in open-weight models because they give developers more room to experiment with how AI is integrated into products. You're not limited to thinking about AI as a feature that sits behind a button. You can make decisions about model selection, inference, deployment, and how the rest of your system handles its output.

For NextProof, that meant treating the model as one component in a larger application rather than assuming that a successful API call was the entire product.

Why I Chose Hosted Inference Instead of Running Gemma Locally

I did consider running a model locally through Ollama.

But that introduced another setup step and a model download of around 1.5 GB before I could focus on the actual product experience.

Given the challenge timeline, I had a choice: spend more time setting up local inference, or use hosted Gemma inference and concentrate on getting the complete application working.

I chose the latter.

That let me spend my time on the parts that needed to come together for NextProof to be usable: document extraction, input validation, structured results, error handling, and the complete journey from resume upload to feedback.

There is a trade-off, though.

NextProof currently depends on a hosted inference service. Gemma isn't running entirely on the user's device, and the analysis requires an internet connection and an available inference endpoint.

It also means the application must account for provider errors, latency, and the costs or usage limits associated with hosted inference.

Local inference could offer different advantages, including more control over the inference environment and the possibility of processing text without sending it to an external model service. But it would also introduce model-download, hardware, and setup considerations.

For this version, I prioritised getting the complete product working over adding another inference mode.

That was a scope decision, not a claim that hosted inference is always better.

The Decisions Behind the Build

I deliberately left authentication out of the current version.

The main question I wanted to explore was whether AI could help developers understand the relationship between their resume and a job description. Sign-up and login flows wouldn't answer that question.

Authentication would also mean taking on more than a login screen: session management, account handling, and decisions about how user data should be associated with an account.

For this version, I chose to prioritise the complete resume-analysis journey over building those additional systems before validating the core experience.

That doesn't mean authentication would never make sense. If NextProof grows to support saved analyses, personal history, or persistent user accounts, those features would need to be designed alongside appropriate data-handling and privacy decisions.

For now, I wanted the core experience to work before expanding the product around it.

Why define input limits?

A resume analyser accepts files, extracts text, and sends that text through an inference pipeline. Without explicit boundaries, an unusually large document or job description can make requests slower, more expensive, or less reliable.

So I added limits to make the current implementation more predictable.

Input	Limit
Uploaded resume	5 MB
Pasted job description	30,000 characters
Extracted resume text	40,000 characters

Each limit serves a different purpose.

The file-size limit bounds the uploaded document. The job-description limit constrains the pasted input. The extracted-text limit catches documents whose extracted content is too large for the intended processing scope.

The application also checks file types and whether useful text was extracted before sending the request for analysis.

These limits aren't magic numbers that guarantee accuracy, security, or perfect performance. They're explicit engineering guardrails that help control input size and keep the current workflow within a defined scope.

They can be revisited as I test more resumes, different document formats, and longer job descriptions.

I wanted NextProof to do more than work for one ideal example. Defining what it accepts, what it rejects, and how it handles failures is part of building the product.

Where This Could Go Next

There are a few directions I'd like to explore:

Better ways to connect each finding to the evidence in a resume and the relevant job requirement.
Evaluation against a broader set of real-world resumes and job descriptions.
More user feedback to understand where the analysis is helpful, inaccurate, or confusing.
Reconsidering authentication and saved analyses if there's a clear reason to introduce persistent user accounts.
Exploring local inference if it makes sense for privacy, cost, and the experience I want to provide.

I'd rather let actual usage and testing guide these decisions than add features just because they sound impressive on a roadmap.

Why Open Innovation Matters Here

For me, the value of open-weight AI isn't simply that a model can be downloaded or that its weights are available.

It's the room it creates for developers to experiment, understand the trade-offs, and build products around models they can choose to use and adapt.

In NextProof, Gemma is a central part of the analysis pipeline. It gives me a way to explore how open-weight AI can be applied to a practical problem, while the rest of the application handles the engineering required to make that capability usable.

The hosted setup also makes the current trade-off clear: I get to focus on the product workflow, but I depend on an external inference service. A local implementation could change that balance, but it would bring its own constraints.

There isn't one approach that's right for every product. What matters is understanding what the choice gives you, what it costs you, and whether it makes sense for the people you're building for.

That's what I wanted to explore with NextProof.

Can This Become a Side Hustle?

The problem NextProof addresses is connected to a real, recurring activity: applying for jobs and trying to understand how your experience fits a role.

A future version could explore a paid tier for more detailed analysis, saved reports, or additional workflows for job seekers. But those are possibilities, not validated business results.

I haven't established willingness to pay yet, and I don't want to pretend otherwise.

Before introducing pricing, I'd want to understand whether people find the analysis useful enough to return to it, which recommendations they trust, and what they would actually pay for.

For now, the live application is a starting point for testing the idea and learning from real users.

Final Thoughts

I keep coming back to one question: how do we build AI tools that help people make better decisions instead of simply giving them another score to worry about?

Job searching already involves enough uncertainty. You don't always know whether you're missing a skill, underselling your experience, or failing to make the connection obvious.

I wanted to build something that helps people examine that uncertainty more carefully.

NextProof is my attempt at that: a working product that uses Gemma to help turn resume and job-description text into a more structured, actionable analysis.

It's live, it has clear limitations, and there's still a lot I want to learn from people using it.

sooo yeah, that's NextProof!!

if you're curious, give it a try and let me know what you think. I'd genuinely love to hear what works, what doesn't, and what you'd change.

try it out: https://nextproof.onrender.com/

wanna peek at the code? GitHub repository link

and if you do try it, pls come back and tell me how it went hehe. thank you for reading this farrr!! ✨

Last Year I Thought Hacktoberfest Was Stupid. This Year, I Built Look Again💀

Omaima Ameen — Sun, 11 Oct 2026 16:15:13 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

So last year, an online dev friend introduced me to Hacktoberfest, I checked it out. A month-long event, open-source contributions, pull requests… and my first thought was: "huh, that's it? This sounds ridiculously easy. What kind of competition is this? 🥱"

I made two PRs, i think🤔, and went back to doing my own thing.

Fast-forward to 2026.

This time, I came prepared. I knew how PRs worked, I knew GitHub, and I was convinced I had this whole thing figured out.

DigitalOcean, you dig? 😶😂

but Hacktoberfest 2026 came with a different kind of challenge as we all knoww!!

The Week 1 challenges theme was Touch Grass - building with open-source AI to help people spend less time on screens and more time experiencing the world around them.

and now I had an actual question to solve: what could I build that would make sense for this theme?

I didn't want to build just another chatbot or add AI to an application for the sake of it. I wanted to build something that actually fit the challenge, that's how I started exploring an idea: what if AI could give people a reason to put their phones away, look around, and notice things they might otherwise overlook?

and that idea became Look Again. 🌱

What I Built

Look Again is an AI-powered curiosity companion that gives you a question to take away from your screen and into the real world.

The idea isn't complicated.

You open the application, choose how you want to observe your surroundings, and receive one AI-generated question, maybe the question encourages you to notice an overlooked detail, observe a change, find a connection, pay attention to people, or approach something familiar with a little more curiosity.

Then you put your phone away.

You explore the question at your own pace, when you're ready, you return and describe what you noticed.

Look Again helps turn your reflection into a Field Note - a small record of an observation you can revisit later.

The experience follows five steps:

Choose: Select an attention mode.
Discover: Receive a focused AI-generated question.
Observe: Step away from the screen and explore.
Reflect: Describe your experience in your own words.
Remember: Save the reflection as a Field Note.

That's the core idea.

I'm not trying to make people spend more time inside Look Again. I'm exploring whether a small interaction with software can encourage someone to pay attention to something outside it and I deliberately didn't build the experience around streaks, leaderboards, or endless missions.

Imagine creating an application to help people spend less time on their phones and then making them addicted to completing its daily challenges.

Congratulations, you've invented the problem you were supposed to solve , wth brooo 💀

Instead, Look Again gives people a starting point and lets them take it from there.

The application doesn't need to be the most interesting thing in the room.

Demo

Project demo: LOOK-AGAIN

Code

GitHub repository: REPOSITORY

The project brings together a React frontend, an Express backend, AI-powered generation, and journal persistence, the repository is where you can explore the implementation and how the different pieces fit together.

How I Built It

Okay, enough talking about curiosity. Let's get into the engineering. 😂

Look Again uses React and Vite on the frontend, Node.js and Express on the backend, SQLite for journal storage, and Google's Gemma model through the Google GenAI SDK.

Here's the stack:

React + Vite - Frontend application
Tailwind CSS - Styling
Motion - Interface animations
Lucide React - Icons
Node.js + Express - Backend API
Google GenAI SDK + Gemma - Prompt and Field Note generation
SQLite via sql.js - Journal storage
Render + Vercel - Backend and frontend deployment

The AI layer

I integrated Google's Gemma model through the Google GenAI SDK for two main tasks:

Generating attention prompts: The model produces a question based on the selected attention mode and relevant context.
Structuring Field Notes: The model helps turn the user's reflection into a more organized note.

The idea is that the AI shouldn't invent the observation, it shouldn't pretend it experienced the user's surroundings or write a fictional reflection on their behalf.

The user provides the actual experience. The model helps shape the interaction around it.

The AI is the guide, not the protagonist.

The trade-off is that AI generation depends on network access and the availability of the external service. API credentials, rate limits, and usage costs also need to be considered.

Why Does Open Innovation Matter?

I didn't want to use AI just to put an AI label on a project, i wanted to explore how an open-weight model could support a particular experience: helping someone approach their surroundings with fresh curiosity.

Gemma gave me a way to experiment with generated prompts and reflections while concentrating on the product itself.

Open-weight models and open-source tooling give developers more freedom to experiment, learn, and make informed technical decisions.

There's an important distinction, though: Look Again uses hosted inference, so the current implementation isn't entirely offline. The model integration depends on network access and the external service.

But that doesn't diminish the value of the experiment. It makes the architectural trade-offs clearer.

For me, open innovation is about being able to explore what technology makes possible and then decide how to use it meaningfully.

Prize Categories

Best Use of Gemma - Integrated Google's Gemma model through the Google GenAI SDK to generate attention prompts and help transform users' reflections into meaningful Field Notes.

What I Want to Explore Next

Look Again is an experiment, and there are still things I'd like to improve, i want to explore how Field Notes could connect observations across different moments, making it easier to revisit an experience and discover patterns over time.

also want to strengthen persistence and deployment reliability.

Most importantly, I want to find out whether the idea actually works for people.

Do the prompts lead to observations they wouldn't otherwise have made? Does reflecting on those observations feel meaningful? Can the experience encourage curiosity without becoming another obligation?

Those questions matter more to me than adding features simply to make the application bigger.

One Last Thing, DigitalOcean...

Last year, I came here thinking, "PR count? Easy."

This year, I came back wanting to win and ended up building something that made me think differently about the purpose of an application.

I still want to win, by the way. Let's not get too philosophical here. 😭😂

But the interesting part of this challenge has been having a reason to build something beyond the usual portfolio checklist.

Look Again explores a simple idea: technology doesn't always need to demand more of our attention. Sometimes, it can give us a reason to direct that attention somewhere else.

A question. An observation. A Field Note worth remembering.
and then, the freedom to close the app.

Happppy Hacktoberfest!✌

Beyond AI: Rethinking What It Means to Be a Human Developer

Omaima Ameen — Tue, 29 Sep 2026 05:56:30 +0000

I sometimes think about building a programming language that only humans could understand and work with but then that thought takes me back to the same point:
as we all know, almost everything we do online, and even parts of what we do offline, can become data used to train AI models.

So the idea of building something that only human intelligence could interpret or work with starts to feel a little vague.

Isn't it crazy that we are now questioning whether we can build something purely for human intelligence to interpret, as if our intelligence is no longer the only thing capable of understanding the things we create?

For some people, this is exciting.
They believe curiosity will lead the way, and everyone will eventually be able to build whatever they want, with the right tools at their fingertips.

but as a software engineer, i have mixed feelings about that.

I don't want everyone to build whatever they want just because the tools have made it possible.
I don't want a complex, deeply technical field like software engineering to become something that anyone can casually master overnight !!

and no, this isn't about gatekeeping knowledge or wanting people to stay away from technology , it's about the value i associate with the process of becoming an engineer.

I wish I could have experienced an era of software engineering where building something meaningful required an incredible amount of human intelligence, patience, curiosity, and effort.

An era where developers spent hours understanding systems, finding mistakes, experimenting with solutions, and learning things that couldn't be understood just by copying a few lines of code.

I wanted to experience that kind of engineering.

But let's come back to reality.

Time is limited. There are too many things to learn, too many tools to explore, and too many ideas waiting to be built.

We are living in an era where shipping fast, adopting tools before everyone else, building in public, networking relentlessly, and finding opportunities before the market gets crowded are becoming increasingly important.

maybe if we can put our brain power into a different layer of technology, to explore unconventional niches, combine ideas from different fields, and build things that aren't just another version of something that already exists.

but more than that, i wish we could reach a level of technology where human intelligence isn't constantly being measured against what AI can understand, replicate, or produce.

I wish we could build things that emerge from the parts of being human that cannot be reduced to patterns in data - our consciousness, our lived experiences, our ability to feel, to question our own existence, and to develop an understanding of the world through experiences that are uniquely ours.

Imagine building a technology that goes beyond simply processing information - something whose meaning is deeply rooted in the human experience behind it, something that cannot be fully understood just by observing the data it produces.

I know this might sound vague, maybe even impossible to define precisely. But I think these are questions we need to start asking.

Somewhere along the way, we've started treating what AI is capable of as the boundary of what we should build next, as if the limits of AI should also define the limits of human imagination.

and I don't consider they should.

I don't want the future of technology to be determined entirely by how much AI can learn, how much it can replicate, or how much of human intelligence it can imitate.

I want us to have control over what we allow AI to become, what we allow it to access, and what parts of human life we choose to keep beyond its reach.

Not every human capability needs to become a machine capability. Not every experience needs to be translated into data. And not every idea needs to be made accessible to an intelligence that can process it without having lived it.

maybe the next big leap in software engineering won't be about making AI understand more of us.

maybe it will be about creating technologies that protect the things that make us human, while pushing the boundaries of what human beings themselves can create.
and that is the kind of future I want to explore.

A future where we aren't simply building technology that gets closer to replicating us, but technology that allows us to go beyond what we currently understand about ourselves.

because I don't want to spend the next few decades asking how much of our intelligence AI can take over. I want to ask how far human intelligence can go when we stop treating AI as the ultimate boundary of our imagination.

P.S. I've been thinking about these questions, and I want to know what other developers think, too.

If you could build a technology that protects something fundamentally human, what would you build?

I'm collecting ideas from developers who are willing to think beyond what AI can already do. Maybe one of these ideas will become something we build together.

-> Share your idea in The Human-Only Frontier: Google Form

Drop your thoughts in the comments. I'd genuinely love to hear your ideas ✨

I Went Down the React Hydration Rabbit Hole

Omaima Ameen — Wed, 16 Sep 2026 03:48:36 +0000

Okay, I went down the React hydration rabbit hole and, I think the way we usually talk about hydration makes it sound much simpler than what is actually happening.

For manyy many many many manyyy years, whenever performance came up, the conversation was mostly about the network. Compress your HTML. Cache your assets. Split your bundles. Ship less JavaScript, don't make the user download half the internet just to see a landing page. All good advice👍 but eventually the JavaScript reaches the browser. AND THEN WHAT?
The browser still has to parse it, compile it, execute it, and React still has to do its own work on the main thread. That part doesn't disappear just because your bundle arrived quickly.

and hydration is not some magical lightweight operation where React looks at the HTML and says, "yep, looks good 👍" and walks away.

there's actual CPU work happening.

The browser already has the DOM because the server sent HTML. React now has to come in and understand that existing DOM, build its Fiber representation, reconcile what it expects with what is already there, attach the necessary behavior, and make that server-rendered UI something React can actually control.

So when I started reading about React 18, the interesting question for me wasn't really "Did React make hydration faster?"

It was more like:

"Wait... what if the problem isn't only how fast we hydrate, but how we schedule the work?"

And THAT is where React 18 gets interesting.

First, React isn't just "attaching event listeners"

This was one of those things that sounded obvious until I actually looked closer.

We casually say:

React hydrates the server-rendered HTML.COOOOL, but internally, React isn't simply wandering through the DOM attaching onClick handlers like some extremely determined intern. 😂

The server has already produced HTML. The browser has parsed that HTML and created actual DOM nodes. React then has to reconcile its expected component structure with those nodes and determine whether the existing DOM can be reused.

That's where Fiber becomes important.

During a normal client-side mount, React is creating host nodes as part of rendering the UI. During hydration, those nodes already exist. React has to match its work against something that the browser has already created.

So conceptually, if the server gave us a <div> and React expects a <div> in that position, React can claim and reuse that existing node rather than treating the whole thing like a fresh client render.

And this is why hydration mismatches are more interesting than just "oops, React printed a warning."

React is basically trying to reconcile two realities:

What the server already put in the DOM

AND

What the client-side React tree says should be there.

If those realities don't agree, React has a problem.

You're not just dealing with ugly console output. You're dealing with React failing to establish the relationship it expected between the Fiber tree and the existing DOM.

That little hydration warning suddenly looks a lot less innocent. 😭

then I reached Suspense and things got even weirder because I think a lot of us learn Suspense as basically:

something is loading
|
show fallback

which is technically useful, but it completely hides the interesting part.

Suspense is not just your fancy loading spinner wrapper.

It's a boundary around rendering work.

Take something like:

const Chart = lazy(() => import("./Chart"));

at that moment, React doesn't have the component implementation available immediately. The dependency is still loading and React has a mechanism for dealing with that unfinished work, during rendering, the lazy component can suspend. React then looks for the nearest Suspense boundary and renders the fallback instead of pretending that the component is ready.

The part I find really interesting here is that React hasn't "crashed."

Nothing went wrong in the traditional sense.

The renderer basically encountered work it couldn't finish right now and said:

okay, I can't continue with THIS part. I'll handle the boundary instead.

That's a very different mental model from thinking of Suspense as merely a component that displays "Loading...".

The fallback is the visible part, the boundary is the interesting parta and then there's Selective Hydration.

This is where React 18 starts making a loooooooooooooooooooooot more sense.

Imagine your page has a comments section, and that section is behind a Suspense boundary.

The page is visible. The HTML is already there. But maybe the Comments subtree hasn't finished hydrating yet.

Then the user comes along and immediately clicks something inside it.

Which is basically the most annoying thing a user can do from the perspective of your carefully scheduled rendering work. 😂

The user does not care that React is currently busy hydrating something else.

They clicked.

And this is where the React 18 scheduling model matters.

Instead of treating hydration like one giant checklist that must be completed from top to bottom before anything else can happen, React can prioritize work associated with an interaction.

The click is important.

The Suspense boundary containing the target can become a higher-priority hydration target.

React can work on getting that part of the tree ready, and once the necessary React tree is available, the queued event can be replayed.

And I really like this distinction:

The click didn't disappear. React just wasn't ready to process it yet.

That's a very different thing.

The browser received the event.

React's job was figuring out when the corresponding React tree was ready to handle it.

This is one of those details that makes "Concurrent React" sound a lot less mysterious once you stop thinking about it as React doing five things at exactly the same time.

It isn't.

The main thread still exists.

Your CPU did not suddenly grow another brain because you upgraded React. 😭

Which brings us to the browser and this is probablyyyy my second favorite part.

the browser doesn't know React exists, it doesn't care about Fiber it doesn't care about lanes.

It doesn't care that somewhere inside your node_modules there is a Scheduler having an existential crisis.

The browser knows JavaScript.

That's it.

React's scheduler is running inside JavaScript execution.

So when people say React can "interrupt rendering," don't take that too literally.

React can't just freeze arbitrary JavaScript halfway through a function and say, "brb, user clicked."

JavaScript execution is still happening on the main thread.

What React can do is structure its rendering work into units and decide when it should yield control back to the browser instead of continuing to consume the thread.

That distinction matters, React isn't preempting JavaScript.React is cooperating with the browser by yielding.

So the mental model becomes less:

React renders everything simultaneously.

and much more:

React has a bunch of work to do, but not all work deserves to block the user right now.

I think that's the more interesting idea behind Concurrent React, it isn't really about making the CPU magically faster, it is about making React's work interruptible, prioritizable, and schedulable.

That's a much bigger idea than "React 18 made hydration faster."

Because the CPU work still exists.

The JavaScript still exists.

The hydration still exists.

React just got much better at deciding:

"Okay, this can wait. The user just did something." and for a UI library, that's a pretty damn important distinction.

The more I dig into React internals, the more I realize that a lot of the things we use every day as developers are hiding some seriously interesting engineering underneath.

i'm still figuring a lot of this out, so if I've misunderstood something here , please tell me !! I'd genuinely rather be corrected than confidently post something wrong. 😭

would love to know how you think about hydration and Concurrent React, or what React-internals rabbit hole you've fallen into recently.

Drop your thoughts below amazing people 🙌

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?