React with TypeScript: A Backend Engineer’s Descent into Madness

It’s been quite a while since my last rant here right?

I have a confession to make: I tried React with TypeScript. Not because I wanted to, mind you, but because someone, somewhere, said it was “the future.” So here I am, a backend software engineer dragged kicking and screaming into the front-end jungle, where logic goes to die and syntax gets sacrificed on the altar of “developer experience.”

Let me start with props. Oh, the props. What an absolutely brilliant invention — because obviously, we couldn’t just call them parameters like sane people. No, we needed a special term so everyone could feel like they’re acting in a low-budget off-Broadway production. “Pass the props!” they say, as if throwing data between components is akin to preparing a Shakespearean soliloquy. And heaven forbid you forget to type your props in TypeScript. “Expected {name: string} but got {name: any}.” Oh, I’m sorry! I didn’t realize I needed to grovel at the feet of the TypeScript compiler for daring to pass a simple value.

And then there’s the useThis and useThat nonsense. React must think it’s Oprah handing out hooks like free cars. “YOU get a useEffect! YOU get a useState! EVERYONE gets a useSomething!” Except it’s less “free car” and more “rusty tricycle with three broken wheels.” Need state? Better useState. Need lifecycle methods? That’s useEffect. Want to feel like a complete fool? That’s useRef. And of course, the golden rule of hooks: never, ever, ever call them conditionally. Oh no, React will throw a hissy fit because apparently, these magical “hooks” are more fragile than the average JavaScript developer’s ego.

Speaking of fragility, let’s talk about JSX. Whoever thought it was a good idea to mix HTML and JavaScript into one unholy abomination should be tried for crimes against humanity. Every time I open a .tsx file, my eyes bleed. “It’s declarative,” they say. Sure, but it’s also an unreadable mess of angle brackets and curly braces. Heaven forbid you need a conditional class. Ternary operators nested in curly braces nested in parentheses — it’s like writing hieroglyphs but less intuitive.

Oh, but wait! TypeScript will save you, right? WRONG. TypeScript doesn’t “save” you; it traps you in an endless purgatory of type gymnastics. Want to pass a simple object as a prop? Better define an interface. Forgot a single optional key? Whoops, the entire thing collapses like a house of cards. And god help you if you decide to use generics. Suddenly, your code reads like an excerpt from a cryptography textbook. “Component<Props extends DefaultProps>.” Sure, why not? I didn’t need to understand what my own code does anyway.

And let’s not forget the npm ecosystem, the gift that keeps on giving. Want a dropdown component? Congrats, you now have to install 47 dependencies and pray to the Node gods that none of them breaks in production. Oh, and while you’re at it, enjoy updating them weekly because some bored developer in Idaho decided to introduce a breaking change for fun.

Meanwhile, back in the land of backend sanity, we deal with things like business logic and actual problems. You know, things that matter. But no, React devs are too busy inventing new state management libraries every three weeks. Redux? Too bloated. Context API? Too basic. Zustand? Too niche. Can we pick ONE and stick with it? No, of course not, because React is all about options — whether they work or not.

And yet, React continues to dominate. Why? Because it’s “popular.” Because someone once said it was “scalable.” Never mind that it turns your codebase into a dumpster fire of spaghetti logic and cryptic hooks. But sure, go ahead and build your “modern web app” while I sit here in my backend ivory tower, shaking my head in disgust.

In conclusion, React with TypeScript is the software equivalent of a Rube Goldberg machine: overly complex, needlessly convoluted, and designed to solve problems that no one outside of Silicon Valley actually has. If you love suffering, by all means, enjoy. But for the rest of us who value our sanity, let’s stick to real programming, where functions are functions, parameters are parameters, and no one calls them “props.”