Amblem
Furkan Baytekin

Why I Hate React But Can’t Stop Using It

A critical look at React's performance tradeoffs & why developers still use

Why I Hate React But Can’t Stop Using It
187
6 minutes

I’m going to share my journey with React—how I started, fell in love with it, grew to hate it, and yet still can’t let it go.

How It All Started

I studied at the Faculty of Education, which has nothing to do with computer science. But I’ve been curious about programming since I was 12. By then, I was already good at HTML and CSS. After graduating, I decided not to pursue a master’s in education. Instead, I wanted to become a software developer (no, I’m not an engineer!).

Discovering React

I was looking for an “easy” way to land a job. I knew Python and Django, but I didn’t want to work in data analysis or machine learning. Since I had experience in web development, I researched the field and found that React was the most popular library for building websites. So, I decided to learn it.

That’s how it started for me—and probably for many others. At first, React’s JSX syntax looked like HTML, which felt familiar. I thought JSX was just a special trick for React. I kept learning, and soon, I was hooked.

💕 Falling in Love

Just two months after graduation, I got a job as a React and Next.js developer. My company asked me to rebuild their user panel web app from scratch. It was an amazing experience, and I learned how React really works.

I was a total beginner back then. Still, I built the entire app by myself in just two months. Sure, I used server-side rendering a bit too much, but I was proud. I mean, I created a whole web app on my own!

💔 Starting to Hate

At first, I didn’t care about how React’s Virtual DOM worked—it seemed to run smoothly. But then I tried a different stack for another project: Flask, Jinja2, and Web Components. That’s when I realized how fast and simple the web could be. There was no need to create a Virtual DOM, calculate differences, memoize components, or update the “real” DOM.

The real DOM is right there! With Web Components, you just change it directly using JavaScript. It’s straightforward: select elements, update them, done. React felt like overcomplicating things. And in big apps, you can really notice the performance difference.

The Performance Problem

Let’s look at some numbers for a typical e-commerce website. React does a lot of extra work, so we expect it to be slower than vanilla JavaScript. I tested a simple app with 1000 products to compare them. Here’s what I found:

Table 1: Load and Render Times

Metric React Vanilla JS Notes
First Contentful Paint ~1.5s ~0.8s React’s library (~130KB) makes loading slower than vanilla (~15KB).
Time to Interactive ~2.2s ~1.0s React’s Virtual DOM setup adds a delay.
DOM Updates (1000 products) ~150ms ~80ms Virtual DOM compares changes, which takes longer than direct updates.
Memory Usage ~200MB ~100MB React’s state and Virtual DOM use more memory.
Bundle Size (gzipped) ~150KB ~15KB React’s bundle is much bigger.

These numbers come from testing a product listing page in Chrome. React’s Virtual DOM creates a copy of the DOM, compares it to the new version, and updates only what’s changed. This “diffing” process slows things down, especially with lots of data.

Table 2: Practical Performance Comparison

Scenario React Vanilla JS
Listing 100 Products 50ms 30ms
Listing 1000 Products 150ms 80ms
Filtering (Price Range) 160ms 90ms
Adding to Cart (Single Item) 10ms 5ms
Page Reload 1.8s 0.9s

Vanilla JS is faster because it skips the Virtual DOM and updates the page directly. But there’s a catch: writing vanilla JS takes more time and effort. For example, managing state or reusing components is a hassle without React’s tools.

Table 3: Can Optimization Help?

React can be faster with tricks like useMemo and useCallback to avoid repetitive re-renders:

Metric Standard React Optimized React Vanilla JS
DOM Update Rate 150ms 90ms 80ms
Memory Usage 200MB 160MB 100MB
First Contentful Paint 1.5s 1.3s 0.8s

Optimization helps, but React still can’t match vanilla JS’s speed.

SEO Challenges

React apps are often single-page applications (SPAs). SPAs aren’t great for SEO because search engines need to run JavaScript to see the content. Static HTML is much easier for crawlers like Google to index. Yes, Google can handle JavaScript now, but it’s slower and less reliable.

That’s why Next.js is so popular. It pre-renders pages into static HTML, which helps with SEO and speeds up loading. Only the dynamic parts use JavaScript, and switching pages happens on the client side. This saves bandwidth and boosts performance. But guess what? It’s still built on React.

My Take

I still hate React because of performance issues. Over engineering should not be the solution. Maybe we can use it on React Native but not on web browsers. If you are curious about my thoughts on React Native, I can say “Just use native language for mobile development”.

❤️‍🩹 Why I Keep Coming Back

So why can’t I quit React? Because of deadlines. My company needs projects done fast, and my personal projects have limited time. React’s ecosystem and developer experience (DX) save the day. I can build an app quickly and make it work well enough.

React has awesome libraries like Formik, yup, react-hook-form, react-query, and react-router. I can create a form with validation in minutes. State managers like Zustand make handling data a breeze. The learning curve isn’t too steep—I can pick up a new library in a day.

JSX is another win. It makes code easier to read than vanilla JS, where you’re stuck manually creating DOM elements. Sure, other frameworks use JSX too, but React’s version feels polished.

💬 What’s Next?

I’m curious about Solid.js. It uses a syntax similar to React but skips the Virtual DOM. Instead, it uses “signals” to update the DOM directly—no copying, no diffing, just fast changes. Sounds promising, right?

After I learn a new backend language, I’ll give Solid.js a try. If I don’t like it, maybe I’ll check out HTMX. It lets you add interactivity with minimal JavaScript. And if that fails? I might just build my own framework. Everyone’s doing it these days, so why not? 😄


Album of the day:

Suggested Blog Posts