Originally published March 2023. Updated November 2026 to add how to choose a framework, how Amplience chose its own, and how a headless CMS fits in.
A front end framework is a ready-made structure of libraries, tools and patterns for building the part of a website or app that people see and use. Angular, Vue, Svelte and Next.js are common examples. Frameworks handle components, reactivity, routing and state, so developers spend their time on business logic instead of rebuilding the basics.
Key takeaways
Most modern front end frameworks share the same building blocks: components, reactivity, routing, state handling and tooling.
A library does one job and your code calls it. A framework runs the show and calls your code.
Choose a framework on team expertise, maturity, architecture pattern, performance, integration and long-term stability.
Test performance on your own use case. When Amplience tested six frameworks, React was fastest for its project, even though Svelte had won other benchmarks.
A headless CMS such as Amplience CMS works with any framework, because content arrives as JSON through APIs.
Sculpture might not be the first thing we think of when we start talking about software. However, for the purposes of explaining what a front end framework is, we can use the work of American sculptor, Alexander Calder.
Suspended together, his colourful, well-balanced mobiles are in harmony with themselves. All the discrete elements are carefully positioned to offset each other, and move and work cooperatively to be greater than the sum of their parts.
A front end framework works the same way. It provides the structure onto which we can hang our code. By adding our own components, data services and business logic, we end up with a new and beautiful application.
Ultimately, a front end framework is a collection of libraries, tools and patterns that provide developers with a foundation on which they can build and develop complex web applications faster and more efficiently. While their processes might differ, they share some similar concepts and features.
How do frameworks use components?
The early days of the internet were a lot simpler. We had static, predominantly simple text and image-based web pages. Data was submitted with native form elements, (AJAX only arrived in 1999) so if you wanted to see the next page of data, you had to fetch the whole thing. For this reason, we thought of UIs in terms of pages.
With the introduction of AJAX, we were able to start breaking these pages apart into independently updating sections. Over time, and as more powerful browser APIs and more sophisticated frameworks started to arrive, a new method of creating UI evolved.
Component-Driven Development (CDD) turns the way of thinking about a page on its head, by allowing developers to create an interface from the bottom up. This modularization lends itself to code reuse and exemplifies the UNIX methodology of “do one thing and do it well”.
A result of the wide adoption of CDD is that all modern front end frameworks support some form of component creation. These components can be configured with attributes known as properties or “props”, and they can be composed together to make increasingly sophisticated interfaces.
Components across frameworks share a lot of similarities, but there can also be distinct differences. Some frameworks like Lit generate native web components, some frameworks like Angular give you a CLI (command-line interface) to generate the boilerplate for a new component, but they all differ in how you define your props, code, HTML and CSS.
How do frameworks handle reactivity?
The first time I was introduced to two-way data binding was through AngularJS. It felt like I had been taught some dark and powerful magic! With hardly any code, your interface could instantly update if some data changed, but also allow you to edit the same data and have it reflected everywhere in your app instantly! Doing this in native JavaScript would have been a big undertaking. It was the first taste of true reactivity, and frameworks have only got better at it since.
All frameworks have ways of generating HTML elements in any way the business logic demands, and re-rendering when needed. The way each framework renders the DOM (document object model) can wildly differ.
With React, JSX is the most popular way to define templates. It mixes JavaScript and HTML elements together, often iterated over using maps, and makes heavy use of ternary operators. React uses hooks and virtual DOM to trigger rendering updates.
Svelte, on the other hand, keeps the HTML and code separate in .svelte files which are then compiled down to native event handlers and callbacks doing the DOM manipulation - without a runtime.
How do frameworks handle routing?
A big part of the web experience is navigating between pages. We’re all familiar with the address bar and how it changes from page to page. The way a web application handles this navigation is called routing, and how it works can be very different depending on our goals.
Single page applications (SPAs) load a single application shell and emulate the traditional address bar changes and back / forward navigation. While in the background, the app is only loading the resources it needs to change the view and nothing more, giving the user a fast experience.
There are Server Side Rendering (SSR) and Static Site Generating (SSG) frameworks that use a file system-based approach to routing. They separate the code that runs during server rendering or build time, and the code that runs client-side in the browser. This results in web experiences that can be cached well, easily indexed, and quick to load. Once the first page is loaded, they can behave like a SPA, only loading what’s needed for the next page. Some are even able to preload the next view as soon as we hover over the button to navigate to it.
How do frameworks manage state?
With reactivity and data being sent all over the place, it’s not hard to imagine that if we don’t keep our state under control, bugs will be sure to follow.
Frameworks can provide the tools to reign in complexity by giving us different mechanisms to handle and distribute state. The common methods that frameworks use for this are:
Reactive stores - Objects that allow you to set and read data that trigger callbacks if the data changes.
Contextual distribution - This allows you to distribute state that’s only available to certain component hierarchies.
Prop setting - Allows for direct parent to child distribution of state.
Scoped state - State that’s only available to the individual components.
What tooling do frameworks include?
The job of a framework is to make the developer’s life easier. To this end, frameworks often come with a whole suite of tools that attempt to reduce the repetitive work of creating applications. This tooling can include help with:
Bootstrapping
Test automation
Code splitting
Dependency management
Bundling
When is a framework not a framework?
… when it’s a library of course!
Frameworks and libraries are different, but the distinction sometimes confuses even seasoned programmers.
A library performs a specific function. For example, Redux is a state management library that is a collection of classes and methods dedicated to that one purpose. Your code instantiates and makes use of a library to perform a specific task.
However, when you use a framework, it calls your code. A framework runs the show. In the sculpture analogy, you can say your code ‘hangs off’ the framework. In software engineering, this is known as the inversion of control.
So when do the lines become blurry? React is an unopinionated library, it can stand on its own and do one thing and do it well - rendering and updating the DOM. In order to build complex apps, React is combined with other libraries and will often find itself in the centre of either a custom hand-rolled framework or an off-the-shelf one like Next.js. This is why you can’t ignore React when you discuss fully-formed frameworks like Angular or Vue, even if it is a humble library.
How do you choose a front end framework?
The framework you pick shapes your application’s performance and your team’s productivity for years, so weigh six factors:
Team expertise: A new framework slows a team down while it learns. If speed matters, bring in someone who already knows it well to guide the others.
Maturity and ecosystem: A widely adopted framework with an active community and good documentation makes problems easier to solve and best practice easier to follow.
Architecture pattern: Single page applications (SPAs) suit highly interactive tools and dashboards. Static site generation (SSG) suits content-heavy sites that change less often. Server-side rendering (SSR) suits sites with frequently changing content, such as ecommerce, and helps SEO. Next.js supports both SSG and SSR, and Nuxt does the same for Vue.
Performance: Decide what matters most, such as edge rendering, low client CPU use or fast builds, then profile each framework in the environment it will run in.
Integration: Check how well the framework fits your existing stack and the tools you plan to add.
Longevity and stability: Look for a strong record of updates, a clear roadmap and backwards compatibility. An abandoned framework, or one with breaking changes, leaves teams scrambling.
Which front end framework did Amplience choose?
For one of its own projects, Amplience needed the fastest framework for a single page application. The team shortlisted Angular, React, Svelte, Vue, Preact and Lit, built a proof of concept in each, and measured how long increasingly complex views took to render and how quickly events returned from deeply nested components.
The results were a surprise. Svelte had beaten the others in earlier tests, but for this use case React was the fastest. Svelte produced the smallest files and the fewest lines of code, closely followed by Preact and React. Taking speed, team experience, maturity and stability together, the team chose React.
Your results will depend on your own use case, so run your own tests before you commit.
Which front end framework is right for you?
There is a lot of crossover in the problems that front end frameworks try to solve and the features that they provide. However, the patterns, the domain-specific language they use, and how opinionated they are all differ.
The purpose of front end frameworks is to allow developers to focus on writing business logic instead of reinventing the wheel and building from scratch every time. The structure and patterns provided result in predictability, which in turn leads to maintainable and scalable applications.
The running joke of the front end community is that a new framework is created every day (or maybe even by the time you’ve finished reading this article). In reality, I think we’re living in a golden age of frameworks where there are many mature and stable flavors to choose from. Each comes with its own strengths to suit your specific needs. So get out there and try some on for size.
Which front end framework is right for you?
A headless CMS keeps that choice open. Amplience CMS delivers content as JSON through APIs, so it works with React, Next.js, Vue, Svelte or whatever your team picks next, and the Amplience Content Delivery SDK for JavaScript simplifies the calls. See how Amplience works as a React CMS or a Next.js CMS, or read our guide to what a headless CMS is.