Behind the Rise of JavaScript Front-end Frameworks

The scripting language JavaScript is a core technology in web development, along with HTML and CSS. And its surge to the top of the ranks of the world’s most prominent programming languages is tied to the rise of the World Wide Web itself.

It all began 25 years ago, when Brendan Eich, then a software engineer for Netscape Communications Corporation, was tasked to develop a language on a tight schedule for the company’s 2.0 beta release of its Navigator browser. The language had to be lightweight yet powerful enough to enable more dynamic and interactive web pages. Faced with these constraints, Eich took inspiration from Java’s syntax, the object-oriented concepts of Self, and some of the constructs of C, Smalltalk, Lisp, and Scheme, to build the JavaScript language in only 10 days.

Today, JavaScript is supported by most browsers and employed by almost every existing website. It was the most popular language used by GitHub repository contributors in 2019, when it also became the most commonly used programming language for the seventh year in a row, according to Stack Overflow’s 2019 developer survey.

With the popularity of JavaScript comes the increase in the number of front-end frameworks, the most common of which are Angular, Ember.js, Preact, React, Svelte, and Vue.js. Based on results from Stack Overflow’s survey, the most broadly used of these frameworks include React, Angular, and Vue.js, with developers ranking React and Vue.js as two of the most loved and wanted frameworks. Svelte garnered the top spot in terms of interest on the 2019 State of JavaScript report, while Ember placed highly in the awareness category and React in the satisfaction category.

Yet the front-end frameworks mentioned don’t make up an exhaustive list, as less-popular ones are also still in use. So why are there so many JavaScript front-end frameworks? Let’s take a look at what’s been behind this rise, the advantages that having multiple frameworks can bring developers (and the issues this can cause), and what to expect in the future.

Reasons behind the rising number of JavaScript front-end frameworks

To address what’s lacking in the JavaScript language

Taking matters into their own hands, developers created their own front-end frameworks to supplement what they thought was missing from the JavaScript language. The distinct ways in which these frameworks were built reflected the varied methods of developing user interfaces (UIs) and the different techniques used to address what the language lacks.

“When creating user interfaces, you can take different approaches,” says Minko Gechev, an engineer on Google’s Angular team. “Individual frameworks are seeing it from all these different angles, and they’re building user interfaces differently.”

Front-end frameworks have implemented specific features to work around the limitations of the JavaScript language and to make it easier for developers to create and manage the front-end elements of their applications. For example, data binding, a feature that enables front-end developers to focus on data manipulation instead of having to worry about the Document Object Model (DOM), isn’t natively supported or, rather, it doesn’t exist out of the box in JavaScript.

Angular uses two-way binding, which facilitates the model-view-controller (MVC) architecture. With this, when a view component changes, the state of the model changes too, with the opposite also being true, thus making for two-way data binding.

In contrast, React offers one-way data binding, which flows from an updated model to rendering the change in the view component. Implementing the opposite flow requires manually setting the value and change handler.

The changing needs of UI development

“I think the evolution of UI design is one of the main reasons why there are so many JavaScript frameworks,” says Brendan O’Leary, Senior Developer Evangelist at GitLab. “Mobile and web application development has diverged and condensed over the advancement of different devices and the ways we connect to applications.”

As a result, the requirements for implementing the way users interact with these devices started to change. What began as graphical user interfaces for desktop apps evolved into UIs for web pages. “With the web becoming much more interactive, there were increasingly diverse demands on developers to create web applications,” says O’Leary. “As JavaScript became the web’s main language, some applications needed to have extensive server-side rendering, whereas others required all client-side rendering.”

This led to a clear distinction between front end and back end, and changed how UIs are developed. With the rise of mobile apps and a demand for responsive web design to accommodate different device types, UIs became more elaborate, and many developers found that JavaScript didn’t have enough capabilities to address those complex front-end needs.

“Those various needs are enabled by, but not really native to, JavaScript itself. Thus, many frameworks have provided solutions for different parts of that spectrum,” says O’Leary.

Keeping UIs in sync with the app state

“The holy grail of UI development has always been how to create some sort of view that can be bound to some state,” says Marvin Hagemeister, a JavaScript developer and Preact core team member. “In the past, this was done by creating the DOM structure by hand and pulling out the necessary bits and pieces via document.querySelector() to find an input element, for example, and updating its state as needed. That approach works, but it’s error-prone, verbose to write, and can lead to bad performance if done incorrectly.”

As GitHub Actions engineer Alberto Gimeno illustrates in this DailyJS blog post, implementing web applications using only what JavaScript offers can be tedious. “These days, we’re building complex UIs, and keeping the DOM coherent with the data you get from XHR [XMLHttpRequest] objects or user interaction and other sources can be challenging,” he says.

Without the help of any framework, updating the state itself might be easy, but updating the UI each time the state changes is difficult. JavaScript front-end frameworks solve the fundamental problem of keeping the UI in sync with the state of the app by devising more efficient ways to update the DOM.

“I think the biggest challenge solved by most front-end frameworks is the ability to manage the state and the interaction between the DOM and back-end services,” says O’Leary. “Those services may contain data or other critical items that are required for first-class user experience, and front-end frameworks provide a paradigm for delivering that into the DOM in a consistent way.”

React provides a virtual DOM—a lightweight, cached version of the real DOM—and updates it when the state of a component changes. Through a process known as reconciliation, React then computes the difference between the current version of the virtual DOM and its previous version, and applies those changes to the real DOM, allowing for effective DOM updates.

Vue.js utilizes a similar virtual DOM, as does Preact, which owes its speed and size to a virtual DOM implementation that’s as close to the actual DOM as possible. Meanwhile, Angular uses change detection to perform DOM updates, detecting changes to component data and automatically re-rendering the view to reflect those changes. Svelte takes a compiler approach, shifting the browser’s work of transforming declarative code into DOM operations to a compiler that builds the app and converts components into imperative structures that update the DOM.

To find a component-based, complete, and consistent solution

Certain frameworks, especially opinionated ones that support a set of design principles, provide an organized structure that allows for consistency and better code maintainability. “Another problem that frameworks solve is dividing the complexity into components—smaller units that you can reuse and test,” says Gimeno. “Using components helps with implementing atomic design.”

For instance, Angular employs a component architecture, in which building a web app entails defining components and composing them together. This modular approach even extends to the entire framework.

“We aim to provide the entire stack to build a production-ready application from end to end,” says Gechev. “We bring together all the pieces you need, starting with a command-line interface [CLI], a component toolkit, a router, a forms module, and progressive web application support through service workers, among others. We make sure these products integrate well so you won’t have to assemble different parts from across the web.”

Ember does the same with its complete front-end stack. It comprises its CLI, which provides an out-of-the-box development experience including auto-reloading, code generators, a standard file and directory structure, and a test runner; Ember Data to manage an app’s data layer; and the Glimmer rendering engine to speed up rendering performance.

But this adherence to convention over configuration means frameworks such as Angular and Ember lose out on the flexibility provided by less-opinionated ones such as React. “The kind of quiet productivity you get from Ember may not be as exciting as the cutting-edge features of other frameworks,” says Melanie Sumner, an Ember core team member and LinkedIn senior software engineer. “But we’re stable and a lot more in-depth.”

Collaboration and community

Most front-end frameworks have an established set of design patterns, which makes it easier for developers to learn a new code base and fosters collaboration, especially among large development teams or those building large-scale apps. Popular frameworks also have extensive documentation, as well as resources such as tutorials, forums, meetups, events, and a dedicated community to support developers.

For Ember, this community is one of its key strengths. “We’re the ‘together framework,’” says Sumner. “We have such a sense of togetherness that it’s the core principle of Ember itself. We’re more than just a JavaScript framework—we’re also building a sense of community.”

The benefits and drawbacks of having multiple JavaScript front-end frameworks

Having lots of JavaScript front-end frameworks can be advantageous for developers. “It’s a positive thing because it helps us explore a problem in a lot more depth,” says Gechev. “Having such healthy competition across frameworks is good—it helps us grow and learn new things.”

Designer and developer Sacha Greif, who runs the State of JavaScript Survey, views the soaring number of front-end frameworks as more of an evolution than a growth. This could be beneficial in the long run, with the latest frameworks being an improvement on established ones. “You have frameworks that are mainstays, such as React, Angular, and Vue.js,” he says. “Then, new entrants like Svelte come in. At the same time, older frameworks such as Backbone fall by [the wayside]. If you’ve tried to keep up with everything, it seems like it’s growing, but I think it’s almost like a ‘survival of the fittest,’ where new entrants come in and older ones go away, and you end up with this healthy ecosystem where everyone can find the best tool for their need.”

Moreover, challenging the status quo is essential. “It’s always good to reevaluate and find better ways to do things,” says Hagemeister. “I think what’s beautiful about the JavaScript community is that we’re not afraid to experiment and try out new things. I see frameworks as a test run for new ideas, and these ideas would trickle down to other frameworks.”

The rise in JavaScript front-end frameworks might also be the push needed for clearer standards in the language. “Without strong leadership from the JavaScript community itself, we might still live in a world of separate code paths for every major version of every major browser on the market,” says O’Leary. “At the same time, each release of JavaScript has added functionality that previously might have only been possible through a framework. For example, although jQuery is still widely used, many modern JavaScript tools eliminate the need for a third-party DOM-querying tool.”

Despite this, Greif notes that the language shouldn’t try to do what a framework does. “Frameworks can highlight needs that the language isn’t currently fulfilling, but that doesn’t mean the language should try to copy the framework’s features,” he says. “Frameworks aren’t so much a driving factor as what apps need to be complete, and the language will adapt to those needs. As apps become more complex and as we do more in the browser, requirements evolve. Then, the frameworks evolve to meet those requirements, and later on, the language can evolve in the same direction to streamline things.”

The downside of having different options to choose from is JavaScript fatigue—the confusion of not knowing which framework to learn and the burnout associated with trying to keep up with what’s new. Foundational JavaScript knowledge could also get lost along the way as newer concepts take precedence over the basics.

“There’s a challenge in having many solutions,” says Gechev. “It’s definitely a hard choice. I would recommend developers stick to the approach that seems more reliable to them in the long term and they feel most comfortable with.”

Hagemeister echoes this advice: “Each framework makes different choices and different trade-offs, but you can’t go wrong with any of them. It’s just a matter of picking one and going with it.”

The future of JavaScript front-end frameworks

When contemplating what the future holds for JavaScript front-end frameworks, Gechev envisions a focus on performance improvements, more robust server-side rendering solutions, and incrementally streaming scripts, depending on user interactions. Hagemeister, meanwhile, foresees an increase in compiler-based approaches, akin to what Angular is doing with Ivy, its next-generation compiler and runtime engine.

JavaScript front-end frameworks could also influence and improve browser compatibility and performance. “Apps built with any of the major frameworks make up an increasingly large portion of JavaScript applications out there, which gets the attention of browser engineers,” says Hagemeister. “They typically spend time optimizing their JavaScript engines according to what features we use the most. For us [at Preact], that means creating and sharing sample code where we feel like the browser’s JavaScript engine is slower than expected. This helps them prioritize performance topics and make the engines even faster.”

In terms of the number of JavaScript front-end frameworks, Gechev believes a decrease is on the horizon. “Based on the past couple of years, the growth of new frameworks slowed down. So I think this will continue,” he says.

This slowdown could benefit the JavaScript community, especially when it comes to standardizing the specifications. “JavaScript is still trying to figure out what that spec is like. It’s evolving and changing, which is why you have all this churn,” says Sumner. “I hope, in the coming years, JavaScript gets to a place where it has good base APIs that we can build on top of, and that we’ll see more flexibility in browsers as a result. I’d like a future where frameworks aren’t even necessary because JavaScript already gives us everything we need.”

This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!

Want to contribute? Get published!

Follow us on Twitter to stay tuned!

Illustration by Victoria Roussel