A Historical Overview and Fundamentals of JavaScript Frameworks

Author bio: Chen Minliang, former ByteDance front‑end engineer.

1. Introduction

There is a lot to discuss about JavaScript frameworks, and while information on how to use a specific framework or its internals is easy to find, this article approaches the topic from a different angle: by reviewing the history of JS frameworks, exploring their essence, and examining the forces that drive their continual change. By looking back, readers can gain a more comprehensive understanding of JS frameworks, grasp the unchanging logic behind their evolution, and better prepare for future shifts.

2. What Is a Framework?

Before explaining anything, we must define it precisely. First, a generic definition of a "framework":

A framework is a "box"—its constraint—and a "rack"—its support. It is a fundamental structural concept used to solve or handle complex problems.

I like this definition because it is concise and accurate; the core of a framework is its "constraint" and "support".

Understanding "Constraint"

A framework provides a systematic method for tackling complex domain problems. Because complex problems rarely have a silver bullet, each framework embodies its own philosophy, and using a framework requires following its logic and rules; solving problems within those rules is the "constraint".

Understanding "Support"

Complex problems can be broken into smaller sub‑problems. A framework's support lies in defining the problem and offering a set of methods to solve it, allowing developers to organize solutions to sub‑problems in an orderly fashion, resulting in an overall solution.

Defining a JavaScript Framework

A code‑organization framework that solves front‑end specific domain problems; its constraint is the need to structure code according to agreed conventions, and its support is the ability to efficiently implement functionality using built‑in mechanisms or capabilities.

According to this definition, JS frameworks cover many areas—front‑end application frameworks, game‑engine frameworks, back‑end service frameworks, etc.—but the term usually refers to front‑end application frameworks, which is the focus of this article. For contrast, a JS library typically solves a sub‑problem and sits on the caller side, while the framework calls the library.

Problems JS Frameworks Aim to Solve

Web front‑end technology has advanced rapidly, and new technologies constantly emerge. The underlying driver has always been how to build web human‑machine interfaces more efficiently. Building complex web applications first requires better code organization, which impacts collaboration efficiency, maintainability, and scalability—essentially a pursuit of production efficiency. The problem domain includes view construction, state management, user interaction, and server communication; as content and interaction become richer, achieving both efficiency and experience becomes a major challenge, which is precisely what JS frameworks address.

3. The Development of JavaScript Frameworks

From Tim Berners‑Lee’s 1989 proposal to the 30th anniversary of the WWW on 12 March 2019, the past 30 years have been the fastest period of technological progress in human history. As the web evolved from a simple proposal to essential infrastructure, front‑end complexity grew—more powerful features, richer content, more complex runtime environments—prompting developers to seek more efficient construction methods, which fuels front‑end evolution.

From the perspective of web front‑end forms, the 30‑year span can be divided into three periods: Read‑only Web, Interactive Web, and Web Application.

Read‑only Web (1990‑2000) : The web primarily delivered static text and images; there was no need for JS frameworks.

Interactive Web (2000‑2010) : With the rise of e‑commerce and social platforms, the web became interactive, leading to the emergence of front‑end engineers and the first wave of libraries and frameworks focused on specific problems such as compatibility or componentization.

Web Application (2010‑present) : The web is now core infrastructure for many industries; building web services now mirrors client‑side applications, and JS frameworks have expanded to cover the entire front‑end development ecosystem.

Read‑only Web Period

In 1989 Tim Berners‑Lee proposed the WWW to enable efficient information sharing among schools and research institutions. HTML 1.0 appeared in 1991, Netscape Navigator in 1993, and the W3C was founded in 1994. By 1995 the web was still static, but the need for user interaction led Netscape to release the first version of JavaScript (LiveScript) in September 1995, renamed JavaScript three months later.

The first "browser wars" saw Netscape dominate early on, followed by Microsoft IE gaining market share through Windows bundling, and later Chrome overtaking both with superior performance and standards compliance. These wars created significant compatibility challenges, prompting the creation of JavaScript libraries and frameworks.

Interactive Web Period

From 2000 onward, the rapid growth of the internet and the rise of e‑commerce and social platforms increased user expectations for interaction. Browsers added capabilities such as asynchronous requests, providing fertile ground for JavaScript libraries and frameworks.

During this era, server‑side rendering was dominant, and JavaScript was used for localized interactions (form validation, AJAX, carousels, tabs). Libraries focused on componentization, compatibility, and tooling.

Componentization

Because the web lacked standardized UI component libraries, frameworks like Dojo (2005) and ExtJS (2007) offered "all‑in‑one" widget sets with a desktop‑style feel.

Compatibility

The "browser wars" created a fragmented environment, leading to the birth of jQuery (2006) which abstracted away many compatibility issues and introduced a convenient CSS‑selector‑based DOM API.

<script>
$("div span:first-child")
  .css("text-decoration", "underline")
  .hover(function() {
    $(this).addClass("sogreen");
  }, function() {
    $(this).removeClass("sogreen");
  });
</script>

As browsers began to implement many of jQuery's features natively and the paradigm shifted toward declarative programming, jQuery's usage declined.

Tool Libraries

Early JavaScript lacked many high‑level features, so tool libraries such as PrototypeJS (2005), YUI (2006), and MooTools (2007) wrapped primitive capabilities to improve productivity.

/* PrototypeJS example */
// Object‑oriented class
var FirstClass = Class.create({
  // The initialize method serves as a constructor
  initialize: function() {
    this.data = "Hello World";
  }
});

// Asynchronous request
Ajax.Request = Class.create(Ajax.Base, {
  // Override the initialize method
  initialize: function(url, options) {
    this.transport = Ajax.getTransport();
    this.setOptions(options);
    this.request(url);
  },
  // ...more methods ...
});

// DOM and events
$$('#items li').each(function(item) {
  item.observe('click', function(event) {
    doSomethingWith(event.target);
  });
});

// Array iteration
myArray.each(function(item) {
  // Your code working on item here...
});

These libraries illustrate early attempts to provide structure, but many later frameworks adopted layered, modular designs that combined these concerns.

Web Application Period

In the past decade, front‑end teams have gained influence and explored more efficient development models such as front‑back separation and engineering tooling. This shift expanded front‑end responsibilities from localized interactivity to full‑scale application construction, introducing challenges in collaboration and maintainability.

Traditional GUI architectures (MVC, MVP, MVVM) introduced the concept of "separation of concerns". Front‑end frameworks adopted these patterns, providing structured ways to organize code.

Backbone.js (2010) introduced view and model concepts but retained an imperative style. AngularJS (2010) borrowed MVVM from WPF, offered two‑way data binding, and provided a comprehensive set of features for building SPAs, though its large API surface increased the learning curve.

React (2013) focused on view rendering, while Vue (2014) combined Angular‑like architecture with a lightweight, declarative approach. Both frameworks are more flexible and easier to adopt than AngularJS, leading to their dominance in recent years.

Two key trends emerge from the last decade: declarative programming has proven more efficient than imperative approaches, and progressive frameworks (which can be adopted incrementally) have outperformed monolithic "all‑in‑one" solutions.

4. Looking Forward

The past 30 years show a clear trajectory: the web evolved from static pages to professional front‑end engineering, with shifting challenges from DOM efficiency and compatibility to large‑scale collaboration and maintainability. Future framework evolution will depend on upcoming front‑end challenges.

Web vs. Native

Early mobile experiences relied on web‑based m‑sites, but native apps soon dominated due to performance and capability advantages. Hybrid approaches have re‑introduced web technologies into mobile development, and future work will focus on how web and native can complement each other.

Smart Terminals

With 5G and IoT proliferation, new device categories will emerge beyond PC and mobile. Determining whether web technologies can efficiently serve GUI needs on IoT devices will be a key consideration for future frameworks.

Low‑Code Development

Low‑code/no‑code platforms are poised to handle many repetitive web‑development tasks, especially for operational and management systems. This may reduce the importance of choosing a specific framework for such scenarios, while general‑purpose frameworks will remain critical for non‑templated, highly customized applications.

All images in this article are sourced from the internet; please contact us for removal if needed.