DEV Community

Cover image for Why I Ditched React (And Why You Should Too): A Self-Taught Dev's Rant
Michael Amachree
Michael Amachree Subscriber

Posted on

Why I Ditched React (And Why You Should Too): A Self-Taught Dev's Rant

Look, I started like most of us self-taught, poking around HTML and CSS, building wonky sites by trial and error. Sure, I dipped into a Coursera course for JavaScript basics, but freeCodeCamp was the real roadmap. It took me from raw HTML to CSS, then tossed me into jQuery, and bam—React. Oh, how I regret that leap. Don't get me wrong, freeCodeCamp's solid for getting you coding, but shoving React right after jQuery? That's like handing a kid a Ferrari after training wheels. It's not their fault; it's just... wrong. React's the shiny darling of the web dev world—most jobs demand it, everyone's hiring for it—so I gritted my teeth and dove in. Big mistake. Huge.

At first, React wasn't all bad. Coming from jQuery, where every project turned into a sprawling HTML mess (one giant file per page, no components, state management via duct-taped globals), React's modularity felt like a revelation. Breaking things into reusable components? Chef's kiss. Passing state around like hot potatoes? Game-changer. And that ecosystem—endless libraries to plug in—made me feel unstoppable. But then I hit the wall: hooks. useEffect, useMemo, the whole circus. They're powerful, sure, but they're a nightmare. Infinite loops that crash your app? Dependency arrays that ghost you? I spent hours on YouTube chasing "React best practices" and "how to not screw up useEffect." Yeah, it was partly a skill issue—I toiled for years—but the fact is: a tool shouldn't demand that toil. It should make your life easier, not turn you into a debugging monk.

I chased perfection: blazing speed, killer SEO, tiny bundles, seamless DX. React laughed in my face. Client-side rendering tanks SEO out of the box (hello, empty HTML shells for crawlers). Building complex apps? Possible, but it took wizard-level skills or a whole team of them. Most devs I know—even at companies—fake it till they make it, cobbling "good enough" without ever nailing "React the right way." And React's unopinionated to a fault. No guardrails means every project devolves into opinion wars: your folder structure vs. theirs, your state solution vs. Redux/Zustand/Context hell. In open-source or team gigs, it's chaos—who are you to say your way's "right" when everything works... barely?

Take my random quote generator, for example. I built it first in jQuery: pulls quotes from an API, displays 'em with a slick UI, lets you search, filter, and fetch new ones. Added dark mode, loading spinners, dynamic backgrounds—the works. It was fast, performant, and dead simple to hack together. Sure, you hand-write HTML, and CSS collaboration was a dumpster fire back then (pre-Tailwind), but jQuery let me manipulate the DOM programmatically without the framework overlords breathing down my neck. Nothing fancy, but it did everything React could—without the paranoia of breaking changes or cryptic errors that make you question your sanity.

Flash forward three, four years of React purgatory. I sampled the flavors—Gatsby for static bliss, Next JS for server-side bandaids—but nothing clicked. Then, helping a buddy on a hackathon, I stumbled into Svelte. Front-end only me, I hit the docs: welcoming, no BS. Installed, declared a reactive state variable, and... it just worked. No ceremony, no hooks ritual. I blinked: "React would never." In React, anything ambitious meant errors on try one and prayers. Svelte? Smooth as butter. Its if/else blocks felt intuitive over JS map/filter spaghetti (personal taste, fight me). Built-ins like stores for state? Scoped CSS out of the box? No more 50 styling libraries roulette.

Svelte's mental model fit. Writing JS in HTML (not HTML-in-JS JSX drudgery) kept me close to the web APIs as-is, no abstraction leaks. onclick stays onclick; no camelCase tax. And yeah, Svelte's opinionated, but in the best way—not a tyrannical framework like some Angular flashbacks, just enough structure to prevent anarchy without stifling you. It flipped me on TypeScript too. Pre-Svelte, I was that JS purist: "Real devs don't need types!" (Cringe, I know.) But SvelteKit's auto-generated types? Client-server safety nets? Autocomplete that actually anticipates your moves? React + TS never gave me that rush—maybe I didn't dig deep enough, but Svelte made TS a superpower, not a chore.

Okay, and yeah, as I'm typing this in late October 2025, React's dropped some fresh updates just weeks ago—a stable compiler for auto-memoization, a new foundation under the Linux Foundation, and tighter AI ties like seamless Copilot integrations. Solid steps, no doubt. But do they torch the core issues? The compiler dodges some re-renders, but useEffect loops still lurk. The foundation's governance won't trim bundle bloat or simplify SSR. And AI? It'll spit out more of those same abstractions that yank you from web standards. It's polish on problems, not fixes—still fighting the tool, not the task.

It turned me into a "React dev," not a web dev. Growth stalled; I chased React's whims, not the platform's. Svelte was a breath of fresh air and Remote functions is just magic for full-stack without the boilerplate.

Svelte fixed it all. It’s not perfect, but its gaps aren't React's baggage. Vue's great too, but Svelte's syntax stole my heart. React fans will scream: "Ecosystem!", sure, it's vast. But Svelte's just enhanced JS, you can port React libs directly (even run React in Svelte via @attach).
Bottom line for a fresh 2025 start? Ghost React entirely. It's a solid library. But the baggage? Bloated bundles, SEO crutches you slap on like panic bandages, burnouts from endless hooks... you should choose the web platform, not the flavor-of-the-month library.

This is my hill: Ditch React. Build real web stuff. Your future self—and the crawlers—will thank you. Rant over. (For now.)

Photo by Rahul Mishra on Unsplash

Top comments (0)