I thought it was over, but they still throw frontend in the trash...
I've recently felt the pain again. A specific one, not named yet.
I'll try to describe it to you. Close your eyes and imagine something between watching someone pour orange juice in their cereal and reading a codebase where every variable is named data2, data2Final, or data2FinalActual.
You have it ? Good.
Well, I've worked in that painfull company where frontend is like a ugly cousin you keep close to the emergency exit at the wedding, just in case. Even some talented engineers, PMs, stakeholders, sometimes, collectively decide that frontend isn't really important. It is decoration. The thing you do at the end, when the real work is done.
In that company, every time I pushed back, I got the same look. "Why would we allocate time to frontend? It's just the UI."
It's fine. I only cried a little. Or maybe it's not, as I am currently writing this article, which is arguably worse...
So, first of all, a kind reminder to all frontend infidels.
We're not in 2005 anymore. Frontend isn't a few jQuery scripts held together by hope and css !important rules. Modern frontend handles authentication, business logic, state management, real-time data, offline support, routing, permissions, i18n, a11y, and approximately 47 other things that get dismissed as "just the UI" in planning meetings.
Here's the thing people miss: everything else in your stack runs on infrastructure you control. Your servers, your environment, your memory. Frontend runs on everyone else's everything — their devices, their connections, their contexts. And it still has to work.
This is why architecture matters. A frontend without structure doesn't just become hard to maintain, it becomes hostile to the people working in it, and eventually to the users experiencing it. Business rules scattered across utility functions named handleStuff.js. Feature flags bolted onto a monolithic component tree. These aren't hypotheticals. These are pull requests I have reviewed with my own eyes.
Good architecture, proper separation of concerns, clear data-fetching patterns, scalable folder structures, isn't bureaucracy. It's how you stay sane at scale, onboard developers without a two-week archaeological expedition, and ship a new feature without breaking the login page. Again.
Remember: Users only see one layer. One.
Here's something nobody in the room wants to say out loud:
Users will never know what's under the hood.
They won't compliment your infrastructure choices. They won't tweet about your data model. They won't leave a five-star review because your architecture is elegant.
What they will do is abandon your app in seconds if they can't find what they're looking for. They'll churn, quietly and permanently, if your interface makes them feel stupid.
Frontend is the layer your users actually live in. The only one they touch, see, or judge. And they judge it constantly, ruthlessly, and without reading the Jira ticket explaining why the button is in that exact position.
A good frontend is fast, clear, accessible, and forgiving of mistakes. That's a craft. With real tradeoffs, real complexity, and real consequences when it's treated as an afterthought, regardless of how clean everything else is.
What good Frontend actually brings to the table.
Still not convinced? Let's talk business.
Conversion rate. Your frontend is directly responsible for whether users complete actions: signing up, buying, subscribing, engaging. A poorly designed form, a confusing flow, or a slow page are leaks in your funnel. Each one costs money. Measurably.
NPS and retention. Happy users, the ones who find what they need, accomplish their goals without friction, and feel like the product works for them. These are the users who come back, recommend, and evangelise. Net Promoter Score is a frontend problem as much as anything else. Maybe more.
Time to Market. A well-architected frontend moves fast. New features slot in easily. Experiments can be run without excavating the entire codebase. A messy one means every sprint is a negotiation with technical debt, and your TTM creeps up until "two-week feature" becomes the standing joke in planning meetings.
Support costs. Bad UX creates confused users. Confused users create support tickets. Support tickets cost money and CSM mental health. A frontend that communicates clearly, handles edge cases gracefully, and guides users through errors is a support cost reduction strategy. Unglamorous but true.
Developer retention. Nobody wants to work in a nightmare codebase. Senior engineers leave. Junior engineers get stuck. Recruiting becomes harder, and onboarding becomes a hazing ritual. Good frontend architecture is a hiring and retention strategy disguised as good engineering.
Brand perception. Your frontend is your brand, to 99% of your users. They will never meet your CEO, read your notion values page, or attend your all-hands. They will use your app. And that experience, fluid or frustrating, is what your brand actually means to them.
So please. Stop throwing Frontend in the trash.
It's not decoration. It's not the thing you do at the end. It's one piece of a larger puzzle, alongside backend, design, product thinking, business direction, and it deserves the same attention as everything else. No more, no less.
Frontend is where your users live. Where your business outcomes are made or broken, one poorly-labelled button at a time.
I'll keep writing about this. I'll keep pushing.
To my fellow frontend developers: you are not alone. I see you. I am with you. We cry in the same room.
PS: The button is still misaligned.