The Problem With “Clean Code” In Frontend Engineering
When readability turns into over-engineering.
“Every frontend developer wants to write clean code…”
More Files Does Not Always Mean Better Architecture
“The code looks clean from a distance. But it becomes expensive to read.”
Simple vs Over-Abstracted
More structure does not always mean more clarity.
A Simple Example
const totalPrice = items.reduce((sum, item) => {
return sum + item.price * item.quantity
}, 0)const totalPrice = calculateCartPricingStrategy(
normalizeCartItemsForPricingEngine(items)
)The second version is not always wrong.
In a large checkout system, pricing may actually need normalization, discount rules, taxes, currency conversion, and business-specific calculations.
But the problem starts when we apply that level of abstraction before the complexity exists.
Simple problems deserve simple solutions.
Complexity should appear because the product requires it, not because the codebase wants to look more advanced.
Over-Abstraction Is Technical Debt
“And every change feels risky because the abstraction is used everywhere.”
The dangerous part is that over-abstraction does not feel like technical debt at first.
It usually feels organized.
Everything has a folder.
Every logic has a helper.
Every behavior has a hook.
Every feature has a service.
But when a bug appears, the cost becomes obvious.
You are no longer debugging a feature.
You are debugging a path across abstractions.
Clean Code Should Reduce Cognitive Load
A good frontend codebase should answer simple questions quickly:
Where is the data coming from?
Where is the state stored?
Where is the API call made?
Where is the business rule applied?
Get Huseyn Ashurlu’s stories in your inbox
Join Medium for free to get updates from this writer.
Where does the UI update happen?
If answering these questions requires opening ten files, the code is not clean.
It is just fragmented.
My Rule
I prefer boring code until complexity proves itself.
Start simple.
Keep logic close to where it is used.
Extract only when repetition or complexity becomes real.
Abstractions should be earned, not assumed.
If the same logic appears in two places, I usually wait.
If it appears in three places with the same behavior, then I start thinking about extraction.
If the logic starts changing for different reasons, then I think about separation.
This keeps the codebase flexible without making it unnecessarily complex from day one.
Balance Matters
This does not mean abstractions are bad.
Good abstractions are extremely valuable.
They help teams move faster.
They reduce duplication.
They create consistency.
They make large systems easier to scale.
But abstraction is powerful only when it hides the right complexity.
If it hides the flow of the application, it becomes a problem.
Clean code is not about avoiding complexity completely.
It is about putting complexity in the right place.
Clean code should serve clarity. Not replace it.
This is why I believe readability should be measured by how quickly another developer can understand the flow.
Not by how many patterns the code uses.
Not by how many files the logic is split into.
Not by how “enterprise” the structure looks.
The best codebases are not always the most abstract.
They are the easiest to reason about.
Final Thought
Clean code is not about making code look smart.
It is about making code easier to understand, change, and trust.
The best frontend architecture is not the one with the most patterns.
It is the one where the next developer can make the next change with confidence.
