CSS: if you’re afraid of deleting CSS, your code is legacy. The standard is deletability (Tailwind / zero-runtime CSS-in-JS).
JavaScript: mutating objects causes most “weird” bugs. Use immutability by default.
React: stop using useEffect to calculate totals. Use derived state during render.
Career: companies don’t pay for “beautiful code”. They pay for performance and profit.
Let’s be brutally honest: your job title on LinkedIn won't protect you from the next round of layoffs.
This is not just another rant; this is a 2025 frontend career guide for those who want to survive. If your routine is still waiting for a Figma file to "translate" pixels into React and installing five libraries just to build a form, you have a target on your back.
The bubble has burst. The easy money has dried up.
Today, companies are no longer looking for "React programmers" who memorized the docs. They are looking for Product Engineers who understand that latency costs money and that bad code is debt with incredibly high compound interest.
"Beautiful code isn't code that looks good. It's code that can be deleted in 6 months without breaking the product."
Forget the "Netflix clone" tutorials. Let’s talk about the reality no one tells you in bootcamps. Let’s talk about the massive gap between amateurism and professional engineering.
If you identify with the "old way" below, don’t get mad. Evolve.
1. CSS Hell: Fear vs. "Deletability"
The biggest mistake I see in code reviews isn't a lack of flexbox or grid knowledge. It’s fear. The absolute terror of deleting a single line of CSS.
You know that global.css file with 4,000 lines that the team treats like radioactive waste? No one touches it because "it might break the Home page"? That exists because you write code coupled to context, not the component.
⛔ The old way
You think you're being "organized" by nesting selectors in SASS/SCSS, but you're creating a specificity bomb that will explode in the next developer's face.
/* The classic way to lock up project maintenance */
.dashboard-widget {
.header {
h2 {
/* If I remove the h2 from here, does the whole site break? Maybe. */
font-size: 18px;
color: #333;
}
}
}
✅ The 2025 standard
The golden rule of modern engineering is: deletability.
If I delete the .tsx component, the style must die with it. No one wants "zombie CSS" lingering in the bundle and slowing down load times. This is why Tailwind CSS won the war and why zero-runtime CSS-in-JS became the standard.
It’s not about "looking ugly in HTML." It’s about scaling without fear. Accept it.
2. JavaScript: The crime of mutation
In 2025, modifying data directly (mutation) should be a capital offense in any PR.
90% of those "weird" bugs you investigate on a friday afternoon—data changing in a table by itself or the cart showing the wrong value at checkout—come from mutating shared objects in memory.
⛔ The old way
const cart = [{ item: 'Book', price: 50 }];
function applyDiscount(list) {
// Congratulations, you just corrupted the entire app's memory
// and created a bug that will only show up in production.
list[0].price = 30;
return list;
}
✅ The 2025 standard (immutability)
Never touch the original object. Create a new reference. React thanks you, redux thanks you, and your mental sanity thanks you.
// Spread Operator isn't decoration. It's data safety.
const newCart = cart.map(product => ({
...product,
price: 30
}));
3. React: The useEffect addiction
If I had to hire a senior engineer with just one question, it would be: "show me how you calculate the total of a shopping cart based on the item list."
If the candidate opens a useEffect to update a total state, the interview is over right there.
⛔ The old way
Juniors use useEffect as a crutch because they don't understand the render lifecycle, causing Waterfall Renders.
// The "Render Spaghetti" Pattern
const [items, setItems] = useState([]);
const [total, setTotal] = useState(0);
// WRONG. This causes an extra render, content flash, and CLS.
useEffect(() => {
setTotal(items.reduce((acc, i) => acc + i.value, 0));
}, [items]);
✅ The 2025 standard
If you have the data, calculate it now. During the render. No extra state. No side effects. Simple as that.
const [items, setItems] = useState([]);
// Mathematical. Fast. Synchronous.
const total = items.reduce((acc, i) => acc + i.value, 0);
The Reality: code is cost, product is profit
Why did Amazon find that every 100ms of latency cost them 1% in sales? Because engineering isn't art; it's business.
Netflix didn’t remove React from the client-side on their homepage on a whim. They did it because JavaScript costs money on the user's CPU. Google didn't invent core web vitals (INP) to annoy you.
The difference is brutal:
- The average dev asks: "which lib should I use to animate this button?"
- The product engineer asks: "if i add this 200kb lib, how much does the conversion drop on 4G?"
"Stop optimizing for your ego. Start optimizing for the user's."
The Verdict
The time for "playing LEGO" with libraries is over.
Beautiful code isn't code full of clever abstractions. Beautiful code is what allows your company to pivot fast without breaking production.
Now I ask you: If a senior engineer looks at your code today in 6 months, will you be promoted or fired?
(If you want Part 2 covering backend-for-frontend patterns, follow me here. And if you disagree about Tailwind, let's fight in the comments).
Top comments (8)
Wanting to fight about Tailwind is the wrong hill to die on. The problem is deeper, depending on a framework to write CSS is the problem.
Sure generating CSS from classes in HTML is very convenient. But you need a framework for that convenience, and that framework can have other opinions than you about CSS.
If you are still writing, or concatenating, everything in a massive file. You haven't kept up with the HTTP protocols.
Nesting has become native to CSS, maybe not everyone finds it a bad idea.
A component doesn't need to be a javascript/typescript file.
It might be an inconvenience for you having to edit multiple files. but keeping the concerns separate is one of the ways to write maintainable code.
Tailwind and CSS-in-JS might be popular now, but what in a few years? Why set yourself up for a rewrite, when you can have a CSS file that is gradually updated when new features are added to CSS.
Boy, that is a rant. There is no new code in your post, every line you wrote is ancient. Front-end will die when humans no longer exist. Just because you recently learned the reduce function and es6 syntax, doesn't mean it's a new way as declared by AI, its only new to you man.
The other dead give away this is a rant, your stating opinions pretending they are fact. Even your evidence, doesn't support the title. When front-end dies, I will be reading your blog on CLI... but even the CLI is a front-end for the OS, it's just a texted based frontend.
Your car dashboard is a front-end. The idea front-end is dead because you have to learn new techniques and syntax and change your approach, it's click bait for fake wannabe engineers. It suggests your not a real frontend engineer, just a noob javascript programmer. It's based on what you want to be true, not what is true. We will not be running nuclear plants without front-end, using only a prompt and response, somehow magically without a keyboard, mouse or screen 🤔. Front-end is not react, front-end is not browser, a radio built in 1940 has a front-end. A text to speech machine still has a front-end. The term front-end has been around long before computers dude.
I did a quick scroll through the article and i cringed at every bit then i had to run down to the comments section. I was not disappointed. This article is a quick pass i did not even have to read it.
Well said.
Nesting is here to stay, so much so that it has become part of vanilla CSS.
It is possible to create separate, component based CSS files that also uses nesting. 2025 browsers are equipped to download multiple CSS files concurrently. This isn't even new, this has been a thing for many years now. The real question here is, are you bundling all of your CSS into a single file? That file should only contain global styles that you know you want to share on all pages, (fonts, colors, resets), the rest should be independent, component based CSS files, you delete it and it doesn't blow up your site, just that component.
The time to build LEGO component based websites is NOW. Recommending Tailwind is my way to tell if you are a basic ass dev with no style.
This whole post is written by AI, why do you have an account give it to ai , it will be you.
You look some kind of newbie to me , that 200kb line , yuck 🤮, don't you know that a project is bundled before deployed or may be you expect your client to git pull and run preview of your project 😂.
And that useEffect one specific use case bs tells me more about your knowledge of react hooks more than anything else, haven't you heard of useMemo 🤦
The only good thing in whole of the post is immutability, which also project small case.
Code has to be art because only then it will be more readable , scalable , fixable if anything goes south ways, but cursor didn't tell you that. if you are against abstraction then stop using react all together, go build in vanilla.
Thank you for saving us! 🛟
If you think like that, use HTMX. It does the same. Is faster as react. Back to HTML Fiest.