Frameworks change.
This is not a complaint. It’s just a fact.
In frontend development, frameworks come and go, evolve, split, merge, and sometimes disappear. New ones promise better performance, cleaner code, and easier mental models. Old ones get rewritten, renamed, or replaced.
I’ve learned frameworks. I’ve enjoyed some of them. I still use them every day.
But over time, I realized that frameworks are not the most important thing in my work anymore.
There are a few things I care about more.
I Care About Understanding Over Memorizing
Earlier in my career, I thought being good at frontend meant remembering a lot of things.
- Which hook to use
- Which option to pass
- Which pattern is considered correct
When something broke, I searched for the right syntax or copied examples.
Now, I care more about understanding what is actually happening.
Not:
“Which function fixes this?”
But:
“Why is this behaving this way?”
Frameworks give you tools, but they also hide details. That’s useful, but it can also create confusion when something goes wrong.
Understanding how things work underneath helps me reason about problems instead of guessing.
I Care About Clarity More Than Cleverness
I used to enjoy writing clever code.
- Short functions
- Tricky logic
- One-liners that felt smart
It looked impressive, especially to my past self.
Then time passed.
I came back to that code weeks later and struggled to understand it. Sometimes I had to read my own code slowly, line by line, to remember what I was thinking.
That was a turning point.
Now, I care more about clarity than cleverness.
If the code is obvious, even if it’s longer, that’s a win.
I Care About Code I Can Change Without Fear
Most frontend work is not about building something once.
It’s about changing it.
- Design changes
- Requirements shift
- Users behave differently than expected
Code that is hard to change creates stress.
Earlier, I didn’t think much about change. I assumed future work would fit the structure I created.
It rarely does.
So now I care about writing code that makes change feel safe.
Not perfect.
Just manageable.
I Care About Predictable Behavior
Frameworks often abstract away behavior.
That’s helpful until it isn’t.
I care a lot about knowing:
- When something updates
- Why something re-renders
- What causes a side effect
Unpredictable behavior makes debugging painful.
When something feels random, it’s usually because I don’t understand it yet.
So I slow down. I trace the flow. I log values. I try to understand what the system is doing instead of blaming the framework.
I Care About Fewer Assumptions
Earlier, I made many assumptions.
I assumed:
- This state won’t change here
- This component will only render once
- This logic will never need to change
Most bugs come from assumptions that didn’t age well.
Now, I care about reducing assumptions.
I try to write code that makes fewer promises and leaves more room for change.
I Care About Simple Mental Models
Complex mental models are expensive.
If I need to keep too many rules in my head to understand a piece of code, that code will cause problems later.
I care about:
- Simple data flow
- Clear ownership of state
- Obvious responsibility boundaries
This has nothing to do with which framework I use.
I Care About Reading Code, Not Just Writing It
Writing code feels productive.
Reading code feels slow.
But reading code is where most understanding comes from.
I care about writing code that future me can read without context.
That means:
- Clear names
- Small responsibilities
- Fewer surprises
Frameworks don’t enforce this. Developers do.
I Care About Being Honest About Trade-offs
No framework solves everything.
Every choice has downsides.
Earlier, I tried to hide those downsides, even from myself. I wanted to believe my choices were the right ones.
Now, I care about being honest.
If something is complicated, I accept that.
If a solution has limitations, I acknowledge them.
That honesty makes future decisions easier.
I Care About Stability Over Novelty
New tools are exciting.
But excitement fades quickly when real work begins.
I care more about stability now.
Tools that:
- Are well understood
- Have predictable behavior
- Don’t surprise me often
Novelty can wait. Stability helps me deliver consistently.
I Care About Real Users
Frameworks don’t experience the product. Users do.
I care about:
- How fast the UI feels
- Whether interactions make sense
- Whether errors are understandable
These things matter more than technical purity.
I Care About Long-Term Pace
Burnout is real.
Chasing every new thing creates constant pressure.
I care about building a pace I can maintain.
That means:
- Choosing familiar tools
- Avoiding unnecessary complexity
- Saying no to unnecessary changes
Frameworks are part of that choice, but not the main part.
I Care About Communication
Frontend work is not just code.
It’s:
- Explaining decisions
- Reviewing changes
- Discussing trade-offs
I care about writing code that supports communication instead of making it harder.
Clear code leads to clearer conversations.
I Care About Learning That Sticks
Frameworks change fast.
Principles change slowly.
I care about learning things that last:
- How to reason about state
- How to manage complexity
- How to debug systematically
These skills move with me, no matter the framework.
Why Frameworks Matter Less Over Time
Frameworks are important.
But they are not the foundation.
They sit on top of:
- Clear thinking
- Good habits
- Honest decision-making
Without those, no framework can save a codebase.
With those, most frameworks work just fine.
Final Thought
Frameworks are tools.
Useful ones. Powerful ones.
But the things I care about most:
- Clarity
- Predictability
- Simplicity
- Changeability
Those don’t come from frameworks.
They come from how we think while writing code.
And that matters far more than which framework name appears in the project.
☕Did you like the article? Support me on Ko-Fi!