DEV Community: Pranav Sindura

Stop Abstracting Your Frontend

Pranav Sindura — Sun, 29 Jun 2025 14:03:16 +0000

TL;DR:
We treat frontend like backend - abstracting UI into patterns that don’t match how designs actually evolve. Stop trying to make your UI scalable. Instead, make it adaptable. This post breaks down why your frontend abstractions keep failing — and what to do instead.

After working across several UI applications from scrappy personal projects, startups-scale mobile applications and to Big Tech enterprise CRMs, one thing keeps bothering me: we treat frontend like backend.

I’ve studied all the usual design patterns to clear interviews: factory, strategy, builder, proxy, facade... the works. And I’ve seen these abstractions leak into frontend codebases where they don’t belong.

We try to scale, abstract, and over engineer - and we forget that UI doesn’t reward elegance. It rewards the ability to iterate, and to adapt.

The issue? People are too eager to treat UI the same way they treat backend systems - with abstraction, encapsulation, and DRY principles - without acknowledging that the rate and nature of change in UI is fundamentally different.

UI is Designed to Break

The most fragile part of your stack is your UI. One small tweak in Figma can undo days of “architectural scaffolding”. Yet people still keep trying to create “smart” abstractions: reusable components, nested sections, configurable UIs with metadata-driven rendering.

It sounds elegant. Until it isn’t.

Yes, you should abstract at the foundational level: design tokens, layout primitives, interaction patterns - the building blocks that rarely change.

I love:

Tailwind for utility-based layout
Fluent UI v9 for structured component reuse

That’s where abstraction belongs.

Figma Doesn’t Care About Your Abstractions

Designers don’t think in patterns.

They think in flow, hierarchy, narrative. When they move a section around, introduce a banner between specific bullets, or redesign one screen - your abstraction breaks.

So you patch it. You add metadata. You build config-based rendering. You invent more patterns. Before long, you’ve created a custom CMS inside your React app.

Before your content payload looked like -

[
    "This is point #1",
    "This is rendered as bullet point list within a section",
    "Great!"
]

Now it looks like -

[
    { type: "BULLET", content: "This is point #1" },
    { type: "BANNER_SMALL", image: "https://link.to/the/small/banner", alt: "this is an image of your small banner", maxVersionToShowOn: "1.9.0" },
    { type: "BULLET", content: "Not so great :(" }
]

Then the new engineer arrives. They need to implement a small change. But first, they have to reverse-engineer your abstraction. They ask:

“How is this page rendered again?”
“Why is the footer wrapped inside a section factory?”
“Why is the banner conditionally injected via content metadata?”

The answer is: because the team prematurely abstracted everything into patterns that looked elegant once, but are painful forever.

The Cost of Abstraction is Underestimated

Design changes more frequently than business logic.

Your database schema might stay stable for months. Your Figma file changes every 2 weeks.

But frontend abstraction assumes the opposite: that content is stable, and structure is sacred.

That’s just not how UI works. The result?

Engineers fear touching the UI
Pages get rebuilt from scratch
Abstractions go stale
Designers are told: “This isn’t feasible”
Innovation slows down

UI is a Canvas to Iterate, not a System to Scale

We need to stop over-engineering the frontend. Your UI doesn’t need to be scalable. It needs to be navigable, editable, and fast to iterate on.

Favor composition over abstraction
Favor readability over DRY
Favor changeability over structure

KISS - Keep It Super Simple.

Treat design as the primary driver. Build for change, not for elegance. Your abstraction won’t save you when the banner moves.

💡 Takeaways:

Abstract slowly, especially in the UI.

Prioritize readability and adaptability.

Align your component design with the rate of change in design, not backend logic.

KISS still wins — even in 2025.

10 Reasons why your Documentation sucks

Pranav Sindura — Wed, 25 Jun 2025 15:36:07 +0000

You love writing docs, don’t you?

You drop the link in chat - “hey, wrote this up.”

Your team gives you a 👍, maybe even a “nice one.”

But nobody actually uses it.

A week later, they ask you the same question.

6 months later, even you stop trusting what you wrote.

Here are 10 reasons why your documentation sucks.

1.

You open three docs for the same system.
Each one says something slightly different.
You don’t know which is right, so you ask someone.
Now there are four sources of truth.

2.

The most reliable signal in a doc isn’t the content.
It’s the last modified date.
If it hasn’t been touched in 6 months, odds are it’s lying to you.

3.

Everyone says “just write it down.”
Nobody says who’s supposed to clean it up.
So your wiki grows.
And trust shrinks.

4.

Most people won’t navigate your folder structure.
They search keywords.
And if nothing useful shows up in 30 seconds, they ask in Slack.
Your structure doesn’t matter if it’s invisible.

5.

Docs don’t age like wine.
They age like milk.
If there’s no owner, no expiry date, and no signal of freshness - assume rotten.

6.

You find a README.
It looks promising.
But the person who wrote it left the company last quarter.
You still read it - but you don’t rely on it.

7.

Even broken docs help sometimes.
They point you to someone who knows more.
That’s faster than digging through repos.
Wrong docs can still move things forward.

8.

Nobody wants to update a doc they didn’t write.
So people fork it.
Now there are two similar-but-not-same versions.
Both kind of wrong in different ways.

9.

People love structure - until they’re allowed to create folders.
Now there are 12 levels, and nobody knows where anything lives.
You end up searching by memory.
Good luck with that.

10.

Most documentation systems aren’t broken.
They’re just neglected.
It’s not a mess - it’s slow abandonment.
You don’t notice it… until you really need something.

You can’t fix what nobody owns. And most docs? Nobody owns them.

What can you do instead?

Consistency Means Having Fun

Pranav Sindura — Sun, 08 Jun 2025 13:45:37 +0000

Everyone says consistency is everything.

“1% improvement every day.”
“Discipline over motivation.”
“Show up even when you don’t feel like it.”

I believe that. I’ve lived that.

But here’s something that hit me recently:
What’s the point of consistency if it stops being enjoyable?

If you keep showing up to a system that drains you, at some point you’ll either break the system, or it’ll break you.

A few weeks ago, my routine was solid.
Morning learning work > Office > Evening personal work. I was working on learning about Azure AI Search, and Power Automate - pace was flowing.

And then it collapsed. Not all at once. Just... gradually.

In the mornings, I had my learning routine—exploring Power Automate and Azure offerings, which I accessed through my work laptop because of enterprise subscriptions.
Then came regular office work. In the evenings, I’d return to the learning track.

On weekends, I had to work on a Tally project that also needed a Windows setup.

At that point, I found myself juggling everything - learning, office work, and project tasks - on the same laptop.

The boundary between work and “my time” started to blur. I’d wake up, open the laptop, and I was already in work mode—before I even got a chance to think about my learning, my reflections, my plans.

That small shift threw everything off.

I stopped checking my reflection board.
Stopped working on my learning items.
Didn’t even open my todo doc for days.

And suddenly, the thing I was looking forward to every morning… wasn’t something I wanted to touch anymore.

Instead, I binged 24 episodes of "The Apothecary Diaries" (enjoying it!) in two days. Didn’t plan to. Just... did.
I told myself I was tired. But I wasn’t.
I was bored. Burnt, maybe. But mostly bored.

That’s when this clicked:
I stopped because I wasn’t having fun anymore.

Now - when I say “fun”, I don’t mean dopamine-chasing, scrolling, or sugar-hits.
I mean aliveness. Flow. That sense of rhythm where something clicks and time just moves.

Fun can be walking around the lake near my house.
Watching trees move. Seeing birds messing around by the water.
Or fixing a small piece of my wardrobe.
Or trying a weird side idea that wasn’t on the plan.
Not because it’s productive. But because it feels like me.

And maybe - maybe, that isn’t a break from the system.
That is the system.

So I added a new question to my weekly retrospection:

“Did I have fun this week?”

Not “Was I entertained?”
Not “Did I rest?”

But: Did I enjoy something deeply enough to want to keep coming back to it?

If the answer is no for too many weeks in a row, something’s off.
Even if the routine looks good from the outside.

So I’ve added two more:

Am I feeling burnt out?
Do I need a distraction?

Sometimes, I just need to do the same task differently.
Sometimes, I need to switch tasks entirely.
And sometimes, I need to walk away, reset, and come back with fresh eyes.

The big shift here is this:

Consistency doesn’t mean doing the same thing the same way every day.
It means continuing to show up in a way that works for you.

That might look like switching mediums.
That might look like skipping a day and reflecting instead.
That might look like changing the weight, the reps, the pace—just enough to keep it interesting.

I’m starting to think that variety isn’t the enemy of consistency.
It’s how you sustain it.

I was hitting most of what I wanted. Checklists were clearing. I even tweaked my retrospection process to better suit how I think.

Because consistency isn’t about how hard you grind.
It’s about how long you’re willing to keep showing up.
And you’re not going to show up for something that doesn’t feel good, at least some of the time.

So yeah—consistency means having fun.
Not always. Not recklessly. But enough to make you want to do it again tomorrow.

Have you ever burnt out from something you actually loved? What brought you back?
Tell me your story, I’m genuinely curious.