I’ve been doing web development for roughly 15 years. I remember the days before npm, the rise of jQuery, Bootstrap, the explosion of SPAs, and things in between.

I’ve seen exciting trends and helpful tools, but lately, I’ve also seen frameworks that are increasingly confusing. Today’s web development seems to be heading in an uneasy direction.

We have normalized a level of complexity that pulls developers away from the basics of the web and into a walled garden framed by build tools, transpilers, and packers.

I’m lucky to be self-employed, which gives me a unique perspective. I don’t have a boss or a job description forcing me to use a specific framework, and that gives me the freedom to build my own way.

Here is why I favor the fundamentals (HTML, CSS, JS) over the “Framework of the Month.”

The “Necessity” Trap

The biggest question I ask myself when I look at a modern package.json is: “Why would I need these dependencies?”

Is this complexity required by the Platform (the browser)? Or is it required by the Framework?

Browsers today are incredibly powerful. They support ES Modules, they handle complex DOM manipulation, and they render CSS beautifully. Yet, we often spend hours configuring Webpack, Vite, or Turbopack. We aren’t setting up these tools because the user’s browser demands them; we are setting them up because our framework can’t run without them.

We have created a world where “Hello World” requires a build step. That feels wrong.

Dependency Hell vs. Application Logic

When you install a modern framework, you often pull in hundreds or thousands of node_modules. If you look at those dependencies critically:

Are those modules helping you write your specific application logic? Or are they just the scaffolding required to hold the framework together?

If 80% of your dependencies are there just to make your build tool talk to your transpiler so your framework can render a button, we have lost the plot. I prefer to keep my dependencies limited to what the application actually needs to function.

How I Build (The “No-Build” Approach)

Because I don’t have to be restricted to work with a specific framework, I prioritize simplicity and stability for my tool choice. Here is what the “Alternative” looks like for me:

1. Server-Side Rendering (SSR) + Standard Scripts

I don’t need a complex client-side hydrator. Standard SSR (generating HTML on the server) coupled with standard <script> libraries works just fine. It is fast, the browser loves it, and SEO becomes easier.

2. ES Modules

I sometimes use ES Modules (import / export) directly. Browsers support this natively now. I don’t need a bundler to merge files together during development.

3. CSS Utilities

Going “back to basics” doesn’t mean writing every line of CSS from scratch. I like using Bootstrap, especially for the utility classes. It provides a clean grid and consistent styling which can keep CSS manageable (I can minimize my customized CSS code).

4. Components without Complexity

You don’t need a framework to think in “Components.” Whether you use web components or just structure your backend code to render reusable HTML snippets, the concept of a component is logical, not technological.

The Takeaway for Junior Developers

If I could offer one piece of advice to developers just starting their journey: Immerse yourself directly with the web fundamentals (HTML/CSS/JS).

If your job does not offer that chance, try to do it when you’re self-practicing.

Try not to let a framework abstract the world away from you. The native WebAPI, modern HTML, and JavaScript are well-designed and powerful enough to do almost everything you need.