Skip to content
← All posts

By VONA

Vanilla JS vs. Frameworks: The Honest Trade-Off

React, Vue, Svelte — great tools. But not always the right tool for the job. When we deliberately decide against them and why.

In web development, there is hardly a question that gets debated as regularly and as passionately as the choice of JavaScript framework. React evangelists, Vue enthusiasts, Svelte fans — they all have their arguments, and many of them are valid. What rarely happens: a sober assessment that takes the task itself as its starting point, not personal preference or the trend on Twitter.

Our stance is pragmatic: we use frameworks when they make the work easier — and do without them when they don’t. That sounds obvious, but in practice it isn’t. The reflex to automatically start a new project with the familiar framework stack is strong. But it leads to a simple landing page being built with the same effort as a complex web application — and performing worse in the end, because it loads a hundred-kilobyte JavaScript bundle it simply doesn’t need.

When Frameworks Are Worth Their Price

Complex, interactive web applications with shared state across many components, dynamic data that is updated in real time, or teams that want to build on a common framework standard — those are legitimate reasons for using React, Vue or similar tools. In these contexts, the abstractions these frameworks offer make development faster, the code more structured and collaboration within the team easier.

For content-focused websites, marketing sites, blogs or portals with mostly static content, on the other hand, the overhead is often not justified. Here, server-side rendering with a static site generator — or simply plain HTML — does more: faster load times, better search engine indexing, simpler caching strategies and significantly fewer dependencies that have to be maintained.

What Vanilla JS Can Do Today

Anyone who hasn’t written native JavaScript in years underestimates what the platform now offers. ES6+ with modules, destructuring, async/await, Fetch API, IntersectionObserver, Custom Elements — much of what you still needed libraries for five years ago is available natively today. Browser support is better than ever. If you know these tools, you can achieve a surprising amount without external code.

  • Native ES modules for clean code organization without a build step
  • IntersectionObserver for scroll animations without a library
  • Fetch API for HTTP requests without Axios or the like
  • Custom Elements for reusable components without a framework

The conclusion is simple: the choice between vanilla JS and a framework should depend on the task, not on force of habit. If you truly master both options, you make this decision better — and in the end deliver products that fit the problem, not the favored technology.

← Back to overview