XDEFiANCE Online Shop

Look at the two implementations above. The code is roughly the same length. They do exactly the same thing. One was written with a framework from 2010, the other with a framework that’s had countless developer hours and a massive ecosystem behind it for over a decade.

The interesting part is not how much better React is—it’s how little progress we’ve actually made.

React looks cleaner. It reads better at first glance. But that readability comes at a cost: you’re trading explicit simplicity for abstraction complexity.

The React code hides a lot. And once you move past simple examples, you hit problems that don’t make sense until you understand React’s internals.

Your input mysteriously clears itself. Turns out you switched a list item’s key from a stable ID to an index, so React thinks it’s a completely different component and remounts it, wiping state. Or maybe you forgot that value can’t be undefined—React saw it flip from uncontrolled to controlled and reset the input.

Your click handler sees old state even though you just set it. That’s a stale closure—the function captured the value from when it was created, and later renders don’t magically update it. You either need to put the state in the dependency array (creating a new handler every time) or use functional updates like setState(x => x + 1). Both solutions feel like workarounds.

These aren’t edge cases. They’re normal problems you hit building moderately complex apps. And debugging them requires understanding reconciliation algorithms, render phases, and how React’s scheduler batches updates. Your code “just works” without you needing to understand why it works, which is nice until it breaks.

People say “you need to rebuild React from scratch to really understand it,” and they’re right. But that’s kind of damning, isn’t it? You shouldn’t need to understand virtual DOM diffing, scheduling priorities, and concurrent rendering to build a password validator.

Backbone might be tedious, but it doesn’t lie to you. jQuery is hackable. You can view source, understand it, and add to it easily. It’s just DOM methods. React’s abstraction layers make that much harder.

We understand the problem: event + state = UI. That’s it. That’s what both of these implementations are solving.

Is there a better model? Something feels as hard and steady as the DOM, but still feels intuitive to write? Something hackable like Backbone and jQuery were, where you can pop open devtools and understand what’s happening?

React App Code Backbone App Code

The Backbone code is brutally honest about what it’s doing. An event fires, a handler runs, you build some HTML, you put it in the DOM. It’s verbose, sure, but there’s no mystery. A junior developer can trace exactly what happens and when. The mental model is straightforward: “when this happens, do this.”

You add a useEffect to fetch data, and suddenly your app is stuck in an infinite loop. The dependency array includes an object that gets recreated every render, so React thinks it changed and runs the effect again. Now you need useMemo and useCallback sprinkled everywhere to “stabilize identities,” which is a thing you never had to think about before.

For massive apps with 1,000 components on the same page, maybe React’s complexity is justified. But what the other 99% of apps? What about small apps that just want to do a job and don’t need all the magic?