What is a JavaScript Frontend Framework?

The Web evolved fast in the last couple of decades. What we build in the browser now has to compete with mobile and desktop apps, and that raised the bar a lot.

Over time, organizations and individuals created an incredibly large number of tools and libraries. Some never got popular. Some saw incredible adoption.

That’s the case of React, Vue.js, Angular, Ember, Svelte, Preact, and many more.

A JavaScript frontend framework helps you build those apps. Most of that work still lives on the Web. The same ideas also power a lot of desktop and mobile apps.

A short history

Until the early 2000s, browsers didn’t have the capabilities they have now. Building complex applications inside them was not feasible performance-wise, and nobody thought about tooling.

Everything changed when Google unveiled Google Maps and GMail, two applications that ran inside the browser. Ajax made asynchronous network requests possible, and developers started building on top of the Web platform while browsers, standards, APIs and the JavaScript language itself caught up.

jQuery and Mootools were the first big libraries. They gave you a nicer API over the browser, and they smoothed out bugs and inconsistencies between browsers.

Then came the first wave of frameworks: Backbone, Ember, Knockout, AngularJS.

The second wave, which is still the current one, brought React, Angular and Vue, with Svelte and smaller tools like Preact alongside. As of September 2026, React is at version 19 and Vue at version 3.

jQuery and those older projects are still used and maintained. Millions of sites still rely on them. As a JavaScript developer today, you are more often asked for React, Vue, Angular, or Svelte.

Imperative DOM vs declarative UI

Frameworks abstract the interaction with the browser and the DOM. Instead of finding nodes and mutating them by hand, you declaratively describe what the UI should look like for a given state, and the framework updates the page.

Using a framework is like using the C programming language instead of Assembly to write system programs. It’s like using a computer to write a document instead of a typewriter. It’s like having a self-driving car instead of driving the car yourself.

Well, not that far, but you get the idea. Instead of using the low-level APIs offered by the browser to manipulate elements, you use tools built by very smart people that make our life easier.

Let’s see the difference. Here is the imperative style with plain JavaScript. We keep a count in a variable, then write into the DOM ourselves:

<button id="plus">Add</button>
<span id="count">0</span>

let count = 0
const button = document.querySelector('#plus')
const label = document.querySelector('#count')

button.addEventListener('click', () => {
  count += 1
  label.textContent = String(count)
})

You do every step yourself: find the nodes, listen for the click, update the text.

With a framework you describe the state and the UI together. The syntax depends on the tool, here is the same counter in React:

import { useState } from 'react'

function Counter() {
  const [count, setCount] = useState(0)

  return (
    <>
      <button onClick={() => setCount(count + 1)}>Add</button>
      <span>{count}</span>
    </>
  )
}

You declare what the UI looks like for a given count, and React updates the DOM when it changes. You never touch #count yourself.

On a small page the difference does not matter much. It starts to matter when the UI has shared state, routing and many components that depend on each other.

When a framework helps

A framework helps when the UI has real state, repeated components and a lot of user interaction: forms with validation, dashboards, anything that feels like an app rather than a page.

For a mostly static page with a few event listeners, plain HTML and a bit of JavaScript are enough. A framework would only add a build step and things to learn.

Want me to talk about your product? You can sponsor this site.