When I started learning web development, everyone told me the same thing: learn React. Learn Next.js. Learn Vue. The internet was flooded with tutorials jumping straight into component-based architecture, state management, and build tools.
But something felt off. I was writing JSX before I truly understood HTML. I was importing CSS modules without knowing how the cascade actually worked. I was using useState without grasping what the DOM was doing behind the scenes.
So I made a decision that felt counterintuitive at the time: I went back to basics.
The Temptation of Frameworks
There's a real pressure in the developer community to use frameworks. Job listings mention React and Angular. Twitter threads celebrate the latest meta-framework. YouTube tutorials are built around the newest tool, not the fundamentals.
I get it. Frameworks are powerful. They solve real problems at scale. But here's what nobody tells beginners: frameworks are tools for specific problems. If you don't understand the problem, the tool becomes a crutch.
You can't appreciate what a framework does for you if you don't know what life looks like without it.
I watched classmates copy-paste React components without understanding why the JSX looked like HTML but wasn't. They'd import useState without knowing what a closure was. When things broke, they had no mental model to debug with — they'd just delete everything and start over.
What Fundamentals Taught Me
When I committed to learning HTML, CSS, and JavaScript deeply — really deeply — everything changed. Here's what I gained:
HTML: The Architecture of the Web
HTML isn't just tags. It's a semantic system. When I learned to choose <article> over <div>, to use <nav> instead of a styled list, to structure headings hierarchically — my sites became accessible, SEO-friendly, and meaningful to screen readers.
<!-- Before: div soup -->
<div class="header">
<div class="nav">
<div class="link">Home</div>
</div>
</div>
<!-- After: semantic HTML -->
<header>
<nav aria-label="Main navigation">
<a href="/">Home</a>
</nav>
</header>This isn't about being pedantic. It's about building things that work for everyone — not just sighted users on modern browsers.
CSS: The Art of Constraints
CSS frustrated me for months. Centering a div was a meme for a reason. But once I understood the box model, flexbox, and grid — not just the syntax, but the mental model — I stopped fighting the browser and started working with it.
I learned that display: grid isn't just a layout tool. It's a way to think about spatial relationships. I learned that position: relative and position: absolute are about establishing context, not just moving things around.
/* My go-to pattern for centered layouts */
.container {
display: grid;
place-items: center;
min-height: 100vh;
padding: 2rem;
}Understanding CSS custom properties — real understanding, not just "it's like variables" — transformed how I architect stylesheets. The cascade isn't a bug. It's a feature.
JavaScript: Thinking in Code
Vanilla JavaScript taught me to think. Not to think in React hooks or Vue composables, but to think in logic. How do you manipulate the DOM? How do you handle events? How do you fetch data and render it?
When I built a todo app with vanilla JS, I understood every line. When I later built one in React, I understood what React was doing for me — and where it was adding complexity I didn't need.
// Vanilla JS: Direct, transparent, learnable
const button = document.querySelector('#add-btn');
button.addEventListener('click', () => {
const item = document.createElement('li');
item.textContent = input.value;
list.appendChild(item);
input.value = '';
});I'm not saying vanilla JS is always the answer. I'm saying you should understand what's happening before you let a framework abstract it away.
How It Helps Me Now
Today, I use React and Next.js professionally. But I use them differently than I would have if I'd started with them:
- I know when NOT to use a framework. Not every project needs React. Sometimes a static HTML site with a bit of vanilla JS is the right call.
- I debug faster. When a React component re-renders unexpectedly, I can trace it back to the DOM. I understand the lifecycle because I learned the vanilla equivalent first.
- I make better architecture decisions. I can evaluate whether a problem needs a framework's solution or if it's overkill. I've seen both sides.
- I communicate better with designers. Understanding CSS deeply means I can implement designs faithfully, not just approximate them with Tailwind classes.
The fundamentals gave me a foundation that frameworks sit on top of. Without that foundation, every new framework feels like learning from scratch. With it, picking up a new tool takes hours, not months.
Advice for Beginners
If you're just starting out, here's what I'd tell you:
- Spend 2-3 months on pure HTML, CSS, and JavaScript. Build 5-10 small projects without any frameworks. A landing page. A portfolio. A todo app. A weather dashboard using an API.
- Read the documentation. MDN Web Docs is the best resource on the internet for web developers. It's free, comprehensive, and accurate.
- Build things that break. The learning happens when you debug, not when you follow a tutorial. Push yourself into problems you don't know how to solve.
- Learn semantic HTML from day one. Don't wait. Accessibility isn't an advanced topic — it's a fundamental one.
- Then, and only then, learn a framework. When you do, you'll appreciate it 10x more. You'll understand the problems it solves because you've felt those problems firsthand.
The web platform is incredibly powerful on its own. Frameworks are built on top of it. Understanding the foundation first isn't a detour — it's the fastest path to becoming a developer who truly knows what they're doing.
I'm Umaer Islam, a full stack developer and creative designer based in Dhaka, Bangladesh. I write about web development, design, and the developer journey. Follow my work on GitHub or connect with me on LinkedIn.
