Let me be upfront about something: this blog is not a technical deep dive into React, and it's definitely not a tutorial. It's a long-form reflection on my personal journey with the library, from the first time I heard the name to where I am today. A story of curiosity, occasional frustration, a whole lot of learning, and ultimately, a genuine appreciation for what has become one of my most-used tools as a developer.

Note: Along the way, I'll include some code snippets to illustrate a concept here and there. That said, the overall tone is informal and reflective, but I'll also be honest when something genuinely annoyed me.

The Early Days: Merely a Word in The Wind

I first heard the name "React" sometime around November 2016, during 11th grade. At the time, I had just started dabbling in web development through a 10-week introductory HTML, CSS, and JavaScript course at Avantaj Consulting in Bucharest, which I attended on weekends. For context, I had been writing C and C++ for about two years at that point, but strictly for competitive programming and algorithmic problem-solving. Frontend development was entirely foreign to me, and the idea of building user interfaces still felt a bit like a different world.

I was learning the fundamentals: HTML structure, the DOM, CSS selectors, media queries, basic JavaScript. One thing that genuinely fascinated me early on was CSS hover states. The idea that just a few lines could make something feel alive and interactive felt almost like magic:

.button {
  background-color: blue;
  color: white;
  padding: 10px 20px;
  border: none;
  border-radius: 5px;
  cursor: pointer;
  transition: background-color 0.3s ease;
}

.button:hover {
  background-color: darkblue;
}

Simple stuff, sure. But at the time, I was hooked. I spent hours tinkering with dropdown menus, modals, and anything else I could reasonably create with vanilla JavaScript. The code was messy, inefficient, and absolutely not something I'd want anyone to see today. But I was learning by doing, and that was the point.

The screenshot above is from a project I built around that time called "Design IT", a mock design agency landing page with a hero section, services, portfolio, and contact form. Not particularly impressive by any standard, but a real milestone for me back then.

At the time, the idea of a UI library or framework was still unknown to me, and I had no idea that there were tools out there that could make building user interfaces easier and more efficient. React was just a name I had heard in passing, and I didn't really understand what it was or why it was important. Worth mentioning: I wasn't even deploying anything to a server, or using version control. Everything lived locally, written in Notepad++ and opened directly in a browser. No syntax highlighting, no live reload, no npm, no build tools. Just raw HTML, CSS, and JavaScript files sitting in a folder on my desktop.

Sounds "primitive" in hindsight, right? At the time, I genuinely didn't mind. But as I progressed through more advanced parts of the courses I was following at the time, the annoying things started to show. Managing state, handling events cleanly, keeping my code from turning into spaghetti after a week away from it... all of it became increasingly frustrating. I remember building a simple calendar widget, coming back to it a few days later, and having absolutely no idea what I had written or why.

This was 2016. No ChatGPT, no AI coding assistants, none of that. StackOverflow was the ceiling for accessible help, and while it was genuinely useful, it was leagues away from the kind of instant, contextual help that we have today. I admit, it's almost strange to think that this was the norm a decade ago.

Meet & Greet: The First Encounter with React

Fast-forward to 2018. First year of my bachelor's in Computer Science & Engineering at TU Delft, and I'm taking the Web & Databases course as part of the curriculum. We revisit some of the fundamentals I had studied back in high school (HTML, CSS, JavaScript), but naturally also get introduced to more advanced topics:

• Responsive design and accessibility
• Node.js and Express.js
• npm and basic tooling
• Brief introductions to Vue and React

It felt like a breath of fresh air. Here were actual tools built to help you manage state, handle events, and keep your codebase from collapsing in on itself. The contrast with what I had been doing before was...wow! That said, React was not really the focus of this course. The goal was broader familiarization with the modern web development ecosystem, moving beyond static pages. For our project of the web part of this course, my partner and I built a local multiplayer chess game using JavaScript, HTML, CSS, Node.js, Express.js, and WebSockets for real-time communication between clients. It was fun to build, but React never came into the picture. Looking back, it probably should have?

I was also, once again, getting quietly frustrated with JavaScript's quirks and lack of type safety. The messiness of it all was starting to annoy me. Take the following example, for instance:

// What is this? Why does this work? Why does this not work?
console.log(0 == false); // true
console.log(0 === false); // false

Note: At this point, most of my programming experience had been in C/C++ and Java, where type safety is the norm.

And yet, somehow, I still wasn't giving React (or TypeScript) a real shot. Not for any strong principled reason. Plenty of my classmates were already using it and talking about it. I just had this vague assumption that I would end up doing backend work, and that frontend was cool to know but not really my thing. If I'm being honest, a big part of it was that I wasn't yet aware of TypeScript. In my mind, JavaScript was just what frontend (and web development) was, and if I had to deal with its limitations...well, I would just have to deal with it.

Note: I am not trying to say that JavaScript is only used for frontend development, even though my writing up until this point may give that impression. I realize that one could technically use JavaScript for backend development as well (Node.js) and that there are plenty of other languages and frameworks for backend development, but this was just the mindset I had at the time, and it influenced my decision to not give React a real shot back then.

Anyways, the course ended, and I moved on to other things. I continued to build small projects here and there, but they were mostly static websites or simple JavaScript apps. I even tried doing frontend work with Vue for a bit, but it did not click with me. I went the non-usual route, and actually did frontend work for desktop apps with JavaFX, which at first was cool and all thanks to type safety, but boy oh boy was it a nightmare to style well and write a million lines of code just to get a simple UI up and running.

You are a Senior Software Engineer (Wizard), Alex (Harry)

Let's jump to late 2024. I had finished my Bachelor's at TU Delft back in 2021, was just getting started on my Master's Thesis final project, and had been working as a software engineer at TomTom for over three years. Mostly backend work, with a healthy mix of DevOps, Cloud, and Security thrown in. Java, Python, Bash, Terraform, Docker, Kubernetes, Azure, GitHub Actions, Jenkins... you name it.

Still no React. Still no web development to speak of.

Something felt off about that. I had been promoted twice in three years and was now a Senior Software Engineer. Ooh, titles. Shiny titles. But what does "Senior" even mean, really? I had accumulated a solid breadth of experience and felt comfortable across a lot of technologies, yet there was this persistent, nagging feeling that I was missing something genuinely useful. Something that would make me a more well-rounded engineer, not just a more experienced one.

Enter React

Right before New Year's Eve 2024, I was looking at my personal website (still the static HTML/CSS/JS thing I had built back in 2019) and thinking about how overdue a "UI/UX revamp" was:

So I started researching modern web development stacks, and React was, of course, one of the first names to come up.

I read a bit about React, watched a few things, and the thought that stuck with me was something like:

This actually looks pretty cool...I've heard about it so many times, maybe it's finally time I give it a real shot? I'm a fan of functional programming, and the component-based architecture seems like it would fit well with that? Plus, the ecosystem is huge, and everyone is more or less using it, so why not?

So I decided to build my new personal website with React, TypeScript, and Tailwind CSS. I actually wrote briefly about that decision in my very first blog post on this site, if you're curious.

On another side-note, I highly recommend watching the React documentary by Cult Repo on YouTube btw!

Getting (Un)Hooked by React Hooks

So I started learning and using React, and it was...interesting. If there's one thing that defines the modern React experience (or rather the experience that I had), it's Hooks. On paper, they sounded great. In practice, they came with their own learning curve, and I picked up some "battle scars" along the way.

useState galore! Good stuff, really

useState was the first Hook I encountered, and honestly, it felt like a revelation. You get a value, a setter function, and React handles re-rendering whenever things change. Coming from vanilla JavaScript, where managing state meant juggling global variables or stuffing data into the DOM, this felt genuinely elegant:

import { useState } from "react"

const [count, setCount] = useState(0);

The honeymoon phase lasted until I started reaching for it for absolutely everything. Tracking a form? Ten useState calls. Handling an API request? A classic trio:

import { useState } from "react"

const [data, setData] = useState(null);
const [isLoading, setIsLoading] = useState(false);
const [error, setError] = useState(null);

It works, but it doesn't scale gracefully. The lesson I eventually learned: useState is perfect for simple, isolated pieces of UI state. The moment things get more interconnected or complex, it's worth looking at other state management solutions (Context, Redux, Zustand, etc.) or even just rethinking your component structure.

useEffect and the dependency array nightmare

Oh boy. If useState was the honeymoon, useEffect was the reality check.

The concept is simple enough: run some code in response to something changing. Fetch data when a component mounts, set up a subscription, clean something up on unmount. Straightforward, right?

import { useEffect } from "react"

useEffect(() => {
  fetchUserData(userId);
}, [userId]);

In theory, yes. In practice, the dependency array is where things get...annoying. Leave it empty and your effect runs only once on mount, which may or may not be what you actually want. Leave it out entirely, and it runs on every render, which is almost never what you want. Populate it incorrectly and you either get stale data or an infinite loop that will make you question your career choices.

My solution to this? Avoid it as much as possible. If possible, sometimes delegate to custom hooks or even just move logic outside of the component to avoid the need for effects altogether. Both of these approaches bring their own drawbacks, but so does the dependency array, so it's a matter of choosing your poison.

useContext and the "prop drilling" solution

At some point in my React journey, I encountered the infamous "prop drilling" problem: passing props down multiple levels of the component tree just to get data from point A to point B.

Thankfully, I found out about React's answer to this: useContext. You define a context, wrap part of your tree in a provider, and any component inside that tree can access the value directly, no matter how deep it sits:

import { createContext, useContext } from "react"
const UserContext = createContext(null);

function UserProfile() {
  const user = useContext(UserContext);
  return <div>{user.name}</div>;
}

For global concerns like themes, authentication state, or language preferences, this is genuinely useful and I have no complaints. Where it gets tricky is when people start using context as a general-purpose state management solution. Context is not a replacement for something like Zustand or Redux; every time the context value changes, every component consuming it re-renders. I learned this the slightly painful way before reaching for a proper state management library for anything more complex.

useMemo, useCallback, and much more.

React provides a whole suite of Hooks beyond the basics, and they can be genuinely powerful tools for optimizing performance and managing complex logic. That said, as with any other language or framework, knowing when to reach for them matters just as much as knowing how to use them.

In the beginning, I was guilty of using useMemo and useCallback far too eagerly, trying to micro-optimize things before I even had a clear picture of the actual performance implications. This is a bit out of character for me, honestly. I'm usually a firm believer in writing clear, straightforward code first and only optimizing once there's a real reason to. Something about React just made it tempting to tinker with every render, even when nothing was actually wrong. For production code, though, I was and still am deliberate about when these hooks genuinely earn their place.

Atomio: Building a Company From the Ground Up with React at the Core

In August 2025, I somehow ended up co-founding Ptolemy, a company that, after a pivot and several conversations, I rebranded to Atomio in early 2026. I won't go into the details of the company or product here, but what's worth noting is that React has been the core frontend technology across all of our web applications from the very beginning. From the initial MVP app to the waitlists to the core product itself, React has been the backbone of our frontend development. The frameworks changed along the way (Next.js, and occasionally Vite), but React remained the constant throughout.

Pretty cool how a library that I was initially curious, yet hesitant to even try, ended up being such a fundamental part of my work and the company I eventually built. The screenshot above is from our homepage, which is built with Next.js and React, and styled with Tailwind CSS.

Conclusion

Looking back at this journey, from Notepad++ and raw HTML files on my desktop to building many apps, and even a company, with React as the core frontend technology, the proverbial distance I traveled is pretty impressive (at least to me). In a decade, the tools that I use changed drastically:

• from Notepad++ to VSCode and IntelliJ
• from StackOverflow to GitHub Copilot and Claude Code
• from plain HTML, CSS, and JavaScript to Next.js, React, TypeScript, and Tailwind CSS.

Where I once dropped in a script tag and called it a day, I now navigate npm packages, linters, formatters, and a whole ecosystem of tooling like Prettier, ESLint, and Biome. It's clear that the journey has been as much about timing and context as it has been about the technology itself.

I didn't pick up React when it was "the right time" by any conventional measure. I heard about it in 2016, walked right past it in 2018, and for many years ignored it, only giving it a real shot in late 2024. And honestly? I think that worked out fine. By the time I actually put my mind to it, I had enough context, enough frustration with the alternatives, and enough general engineering experience to appreciate what it does well and to recognize where it gets in your way.

React is not by any means perfect. The useEffect hook will probably always be a source of mild annoyance for me (and many others). Also, the web ecosystem as a whole moved fast enough even before the LLM boom, let alone after it, that it can be hard to keep up with all the new tools, libraries, and best practices that emerge around it. But who says you have to keep up with everything? Not everything that is hype is actually worth your time, and I learned that it's perfectly fine to pick a tool, learn it well, and stick with it for a while, even if the world around it is changing rapidly.

Hopefully, though, React is here to stay. At least so far, it has shown absolutely no signs of going down in popularity. If anything, with LLMs and AI coding assistants being mainstream, the popularity of React has only increased. I just hope that people (developers) will actually take the time to learn it properly, and read the code which coding agents generate for them, rather than just copy-pasting snippets without understanding them, but that is a topic for another blog post, I guess.

Well, this is the end of this long-form reflection on my React and web development journey. If you made it this far, I genuinely applaud your patience and interest in my story and ramblings.

This one was brought to you by a sleepless night and some unreasonably delicious Moldovan "brânzoaice":