The Real Cost of Abstractions in JavaScript & When to Ditch Them

Well let’s be honest… as developers, we love abstractions.

• Hooks

• Helpers

• Custom utilities

• Fancy HOCs.

They feel smart. Clean. DRY.

But here’s the thing.. not all abstractions are good abstractions!!

Some make your code harder to understand. Slower to run. Painful to debug and way harder to onboard new devs onto.

The Abstraction Trap

You start with good intentions → “let’s just extract this logic into a helper so we can reuse it.”

But fast forward 6 months.. now that helper calls another helper, which calls a config file, which pulls data from a global context, which is memoized, but also conditionally async…

And you’re stuck reading 5 files just to figure out what’s happening in one line.

That’s not abstraction. That’s obfuscation.

What We Forget

Every abstraction you create:

• hides logic

• introduces coupling

• makes debugging harder

• adds cognitive load

• assumes future use cases (that may never come)

And worst of all → they’re hard to delete.

Because once it’s used in 6 places, nobody wants to touch it.

When Abstraction Makes Sense

I'm not saying “never abstract.” I’m saying be ruthless about when and why you do it.

Here’s my rule of thumb:

Don’t abstract until the pain of duplication is greater than the cost of hiding the logic.

In other words:

• If it’s used once → don’t abstract it.

• If it’s used twice → wait.

• If it’s used 3+ times and identical → fine, maybe abstract.

• But test it in production first.

Abstraction should emerge organically from usage, not be prematurely imposed.

Real Talk: React and the Abstraction Rabbit Hole

React apps are especially prone to this.

You see it all the time:

• useCustomHook() that returns 5 things but you only need 1

• Overengineered context providers for “flexibility”

• HOCs that wrap HOCs that wrap wrappers

I've worked on codebases like this.

Everything is “clean.”

And nothing makes sense.

Don’t build a design system for one screen.

Start small, then write real code for real use cases.

Let patterns emerge.

So What Do You Do Instead?

• Write simple code first. Inline logic is not evil.

• Duplicate when it’s clearer, it’s cheaper than the wrong abstraction.

• Name things precisely. if your helper is vague, your abstraction will be worse.

• Refactor only when real friction emerges.

This is the senior mindset.

It’s not about writing clever code. It’s about writing code that survives the real world → team growth, deadlines, onboarding, bugs and burnout

You don’t need a clever utils folder.

You need a codebase that performs under pressure.

And sometimes?

That means throwing away the abstraction and writing the damn logic.

---

I’m Miraya. I design and build high-performance frontend experiences where UX, UI, and engineering actually align.

Let’s build smarter.

🔗 www.miraya.tech