DEV Community: Paweł Żurawski

Angular SSR: Your server-side rendering implementation guide

Paweł Żurawski — Wed, 24 Jul 2024 09:46:11 +0000

In version 16, Angular received official support for Server-Side Rendering. Let’s look at the possibilities offered by Angular SSR, and its implementation.

For a long time now, Frontend Developers have mostly used the popular CSR (client-side rendering) technique of page rendering in which most of the application logic is transferred from the server to the client’s (i.e., the recipient of the content) web browser. However, we are currently observing a fundamental change in the approach to application development. The teams behind popular frameworks such as React – and recently, as of version 16, also Angular – increasingly encourage using the so-called SSR (server-side rendering).

What caused this shift? What is SSR, and how does it differ from other page rendering techniques such as ISR or SSG? What are the best scenarios for using each of these approaches? And finally, how does SSR work in Angular, and how to implement it properly? Read on to find out.

👴Still using the legacy Angular JS? Learn how to upgrade AngularJS to the new Angular

Web page rendering – A little bit of history

Before we move to other topics, let's stop for a moment and talk about how web applications are created now and how they were created in the past.

MPA (multi-page application)

The old approach – before the dawn of CSR, SSR, etc. – is now referred to as MPA (multi-page application), and the name is directly connected to how websites created in this way work. Each page the user sees is a separate entity, delivered by the server to the client each time an action occurs (e.g., form submit, GET request for new data, changing a tab, etc).

For this reason, each time we perform an action, the server provides us with completely new HTML code that refreshes the page and replaces the existing code. This approach means that the browser does not have to perform any actions. Instead, everything happens on the server side. You can probably see some of the basic problems already, such as

Since nothing is happening on the user’s side, you can’t add interactive elements to your website
The HTML itself is static, so to add dynamic elements, you need to use, for example, JavaScript

Below, you can find a graphic showing how such a website works:

SPA (single-page application)

The real revolution came with the appearance of SPA (single-page application), which I discussed in more detail in my Angular vs. React article. These applications are made using libraries and frameworks such as Angular, allowing the creation of pages supporting all actions on the client's side. This makes it possible to include fully-dynamic elements, resulting in completely interactive pages.

However, this also translates into reduced use of the server's extensive resources to support operations – instead, users mostly use it to download data from (in the form of JSON files, for example). The entire logic is executed on the client's target device. This approach is still very popular and many new pages are still being created using it. Below is a graphic that illustrates this approach’s operation:

The return of server-side rendering

However, a question may arise: if the transition to client-side operations is now so popular and allows the support of interactive elements, what motivates creators to return to server-side rendering? The reason is the constantly growing size of currently created applications and the much-improved data transmission we now have.

Because SPA applications use more resources, the load on the end-user’s device (the client) increases. This means it runs slower and needs more time to perform the required operations. At the same time, the resources provided by the server, which are usually much larger than those available to the user, are not used. As a result, the quality of the end-user experience declines over time as the apps become bigger.

Over the years, various ideas have emerged to solve the above-mentioned problems. The applications and libraries used were constantly optimized, and over time, creators realized that some websites could benefit from moving away from the CSR technique. For this reason, it was decided to combine CSR (client-side rendering) with greater use of server resources, as was the case in the past, and this is how the idea of SSR (server-side rendering) emerged.

Different web page rendering techniques

Nowadays, websites implement very different business scenarios and, therefore, have completely different needs, which caused various solutions to appear. Below is a graphic comparing each of these approaches, detailing which technique requires how much work to deliver the application to the end user.

As you can see, each solution has a different approach to application rendering. There are three stages in this process:

Client – work performed by a web browser
Server – work performed by the server from which the application is delivered
Build – work performed as a result of running the application-building script

The current trend is to reduce the amount of work the client performs while maintaining the ability to include dynamic content on pages. Moreover, the fact that the application building stage is performed only once (when changes are made to the application), is increasingly being used to shorten the time needed to deliver the application to the client. So, let's move on to a detailed discussion of these techniques and the benefits of using them.

“Pre Client Side Rendering” – Default technique for the MPA

Pre CSR is a term I use for the technique of rendering page content on the server side before sending it to the client browser (it’s often called “traditional server-side rendering”, but it differs a lot from the current iteration of SSR that is the main topic of the article, so I decided to call it differently here to avoid confusion). This is the traditional method of creating websites in which all content is ready to be displayed as soon as the page is loaded.

Pre CSR is characterized by static content, which means that the page is rendered in advance and does not allow active interaction on the part of the customer. The advantage of this technique is the speed of page loading and ease of caching content, which translates into better performance and SEO.

The limitations of such websites – lack of interactivity and personalization – make this approach work mainly for websites with little changing content, such as portfolio websites or corporate websites.

Client-side rendering (CSR)

In this approach, most of the rendering logic is transferred to the client side, i.e., the user's browser. The server provides only the necessary data in the form of minimal HTML code and all logic written in JavaScript, and the entire rendering process takes place on the client side based on the received JavaScript code.

This approach allows for more dynamic user interaction and faster page loading after the first load because most operations and content updates are performed dynamically on the client side. CSR also offers better control over the user interface and allows dynamic content loading. However, the website’s performance depends on the user's device. Moreover, CSR can make it difficult for web crawlers to index your content, negatively impacting SEO.

This solution works great for web applications that require high interactivity and dynamics, such as social media platforms and administration panels.

Server-side rendering (SSR)

Server-side rendering (SSR) is a technique in which website content is rendered on the server side as complete HTML pages before being sent to the client's browser.

SSR combines the advantages of Pre CSR with the interactivity possibilities offered by Client Side Rendering. The process is very similar to Pre CSR – the server processes the request received from the client, generates HTML and sends the finished document to the browser. Thanks to this, the browser receives ready-made page content that can be displayed to the user (which significantly shortens the loading time).

However, by itself, HTML doesn’t allow for dynamic content. The application is loaded but not hydrated ("hydrated" is a developer term that means that the page has been loaded and the JavaScript code responsible for adding dynamic event support has been correctly assigned to it). It means the page is displayed, but no buttons, forms or navigation will work until JavaScript is hydrated. For this reason, JavaScript code is also sent to the browser, which the browser then provides to the framework used, enabling interactivity and personalization of content.

The advantages of this approach include better performance and faster content rendering, especially in the case of complex applications (they can use the server’s full computing power). You can also improve SEO because the website content is available for web crawlers. However, SSR also has disadvantages, such as generating a greater load on the server in the case of large applications and a more complicated implementation than in the case of CSR. Additionally, the waiting time for request execution may also be extended in case of a high server load.

This solution is perfect for websites that require fast loading and good performance, such as online stores and information portals.

Static Site generation (SSG)

Another page rendering technique has emerged in recent years, known as static site generation (SSG). In this method, pages are rendered server-side, similar to SSR, but with the difference that content is generated dynamically based on external data, such as the content of Markdown files or API queries.

This approach achieves a compromise between performance and interactivity, enabling the generation of static pages based on retrieved data that can be quickly delivered to users. To make changes to such a page, e.g., due to the appearance of a new entry, you simply run the application build again and deliver the updated version of the application to the server. The resulting loading speed and ease of content caching – which translates into better performance and SEO – come at the cost of lower interactivity opportunities.

This solution works great for websites that offer rarely changing content, such as blogs or portfolio websites.

Incremental Static Regeneration (ISR)

The latest trend in web page rendering is Incremental Static Regeneration (ISR). It’s an improved SSG technique that combines the features of both SSR and SSG. It allows static pages to be rendered similarly to SSG but uses the SSR approach for pages containing changing data.

Therefore, we actually distinguish two scenarios for rendering pages using ISR:

A given page is cached and can be delivered almost instantly without having to do much work on the server or in the browser
The data on which a given page depends is "out of date," which makes it necessary to render the page again, as is the case with SSR, and provide an updated version to the browser. In this case, the browser must also do some work to enable things like navigation to function properly. Thanks to this, pages can be constantly updated without re-rendering the entire application, which speeds up the page's operation time and provides current information to users

This solution is intended for websites requiring dynamic content but with limited update frequency, such as online stores, blogs, information websites, etc.

Angular SSR implementation

Now that we understand the benefits and drawbacks of each rendering technique, we can move on to how it is done in Angular. As I told you before, since version 16, Angular applications can be extended with SSR logic. It allows us to render pages on the server and includes Prerendering logic (SSG), so we can benefit from implementing both of these approaches. One thing that is currently unavailable is ISR, which, as of today, is only available in the React-based framework called Next.js. Let's move on and explore how Angular SSR approaches implementing all of these features.

Creating an app and adding SSR

First, let's create a new Angular application that will use the capabilities offered by server-side rendering. The version of the Angular framework I will be working with in this tutorial is Angular 17. To create a new application, you only need to run the following command using the selected CLI:

ng new APP_NAME --ssr

Alternatively, if you want to add SSR to an existing Angular application, just use the following command:

ng add @angular/ssr

Regardless of which option you used, your application should now support SSR. So, go to the newly created folder and open the application using the selected IDE (in my case, it will be VSCode). When you now look at the structure of your project, you will see three interesting files that you don’t have in the case of a regular CSR-based project:

server.ts
main.server.ts
app.config.server.ts

Let's look at the first one. It’s the code responsible for creating the Node.js Express server. This is a fairly basic server setup, but what should catch your attention is the code below:

server.get('*', (req, res, next) => {
    const { protocol, originalUrl, baseUrl, headers } = req;

    commonEngine
      .render({
        bootstrap,
        documentFilePath: indexHtml,
        url: `${protocol}://${headers.host}${originalUrl}`,
        publicPath: browserDistFolder,
        providers: [{ provide: APP_BASE_HREF, useValue: baseUrl }],
      })
      .then((html) => res.send(html))
      .catch((err) => next(err));
  });

The above function will always be executed (due to the *) when a GET request is triggered by the client. As a result, this means that regardless of what path you go to in your application, the above logic will be performed before this transition is made. Also, pay attention to one of the arguments provided to the render method, namely bootstrap (the individual arguments are described in detail in the documentation). When you look for where this variable comes from, you will notice that it’s imported from the second file mentioned at the beginning:

import bootstrap from './src/main.server';

When you look at the contents of this file, you will notice that it’s an extremely similar application bootstrap, as is the case in the main file of every Angular-based application, main.js. Note that they use exactly the same function to run the bootstrapApplication app. The only major difference between these two files is where the application's config is downloaded from. Details:

main.server.ts:

import { bootstrapApplication } from '@angular/platform-browser';
import { AppComponent } from './app/app.component';
import { config } from './app/app.config.server';

const bootstrap = () => bootstrapApplication(AppComponent, config);

export default bootstrap;

main.ts:

import { bootstrapApplication } from '@angular/platform-browser';
import { appConfig } from './app/app.config';
import { AppComponent } from './app/app.component';

bootstrapApplication(AppComponent, appConfig)

  .catch((err) => console.error(err));

As you may have already guessed, this means that the application is first rendered by the server and only then on the browser side. However, before we get to what exactly this translates into, let's look at the last file mentioned above, i.e. app.config.server.ts:

import { mergeApplicationConfig, ApplicationConfig } from '@angular/core';
import { provideServerRendering } from '@angular/platform-server';
import { appConfig } from './app.config';

const serverConfig: ApplicationConfig = {
  providers: [
    provideServerRendering()
  ]
}; 

export const config = mergeApplicationConfig(appConfig, serverConfig);

Here, you can also see an interesting relationship: the Angular application's configuration is merged with the server's configuration. As a result, if you make changes to your application's configuration, these changes will be reflected in the server configuration.

import { ApplicationConfig } from '@angular/core';
import { provideRouter } from '@angular/router';

import { routes } from './app.routes';
import { provideClientHydration } from '@angular/platform-browser';

export const appConfig: ApplicationConfig = {
  providers: [provideRouter(routes), provideClientHydration()]};

Now, let's return to the earlier question: why does the server render the application before the client performs this process?

The answer to this question is related to the hydration process, which has already been discussed in the article. In the case of Angular, the markup obtained from building the application by the backend, i.e., on the server side, is transferred along with the necessary data to the client, which then renders the entire application based on it.

Thanks to this, the client doesn’t have to perform this entire process from the beginning but can use the version prepared by the backend. To see that this is actually happening, just run your application and right-click to display the website’s source code. You should see the following view:

As you can see, the code includes an additional parameter of the app-root tag, ng-server-context=’ssr’. In the middle of this tag, there is a markup of your application. This proves that your application was first rendered by the backend, which not only shortens the waiting time for the end-user to receive the page but also provides code that facilitates web crawlers' indexing of pages.

Angular Lifecycle Hooks

To start implementing SSR, you need to define which elements of your application should be executed on the server side and which on the client side. Lifecycle Hooks is a crucial element of Angular, created for this very purpose – it allows you to manage the content rendering process effectively. Let's look at which component lifecycle methods are performed on the side of the server, which are executed by the browser, and the consequences of this.

When each component is rendered, the constructors and some of the lifecycle methods, such as ngOnChanges, ngOnInit, ngDoCheck, etc., will be executed both on the server side and in the browser. However, the rest of the event handlers, which are not directly related to rendering, will be executed only on the browser side. To illustrate this process, let's modify the app.component.ts file as follows:

import { AfterViewInit, Component, OnInit } from '@angular/core';
import { RouterOutlet } from '@angular/router';


@Component({
  selector: 'app-root',
  standalone: true,
  imports: [RouterOutlet],
  template: `<button (click)="decrement()">-</button>
    <span style="margin: 0 1rem">{{ counterValue }}</span>
    <button (click)="increment()">+</button>`,
})
export class AppComponent implements OnInit, AfterViewInit {
  counterValue = 0;
  ngOnInit(): void {
    console.log('ngOnInit: Hello from the browser and the server!');
  }
  ngAfterViewInit() {
    console.log('ngAfterViewInit: Hello from the browser and the server!');
  }
  constructor() {
    console.log('constructor: Hello from the browser and the server!');
  }
  decrement() {
    console.log('decrement: Hello from the browser!');
    this.counterValue--;
  }
  increment() {
    console.log('increment: Hello from the browser!');
    this.counterValue++;
  }
}

The result of this code is a simple application that allows you to display a counter whose value can be increased and decreased by pressing the appropriate buttons. However, what should interest you most is the result of the ngOnInit and ngAfterViewInit hooks. Start the application in the chosen CLI using the following command:

ng serve

The following information should appear in the console:

Additionally, when you look at your browser's console, you will also see the same entries:

This proves that the app managed to perform operations both on the server side, and the browser side. However, you must be aware of certain limitations of this approach. Browser-specific elements such as global objects: window, document, navigator, location or localStorage are not available outside of the browser. Let's try to modify the constructor code by adding one of these objects to it, for example:

constructor() {
  console.log('Hello from the constructor!');
  console.log('This is current href in the browser: ' + window.location.href);
}

As a result of this action, the server will return an error about the lack of window definition, as shown below:

The same situation occurs when you try to use this code in any lifecycle hook which executes on the side of the server. Now you're probably wondering how to get around this problem. After all, in many cases, it’s necessary to, for example, read the value contained in localStorage when initializing the component. Angular provides two solutions to this problem.

Use of the isPlatformBrowser, isPlatformServer functions and the PLATFORM_ID constant value

The first approach is to use a function that returns information about the type of platform on which the application code is executed. This approach is nothing new, but it works great in this case. So, add the appropriate code to your application and check its operation.

import { isPlatformBrowser, isPlatformServer } from '@angular/common';  
import {
  ...,
  inject
} from '@angular/core';


...


platformId = inject(PLATFORM_ID);
ngOnInit(): void {
  if (isPlatformBrowser(this.platformId)) {
    console.log('Hello from the ngOnInit in the browser');
    console.log(
      'This is current href in the browser: ',
      window.location.href
    );
  }
  if (isPlatformServer(this.platformId)) {
    console.log('Hello from the ngOnInit on the server');
  }
}

The above code should trigger a different console entry when ngOnInit is executed, depending on the platform on which it was executed. To check the correct operation of this mechanism, just look at these consoles:

Server:

Browser:

The code correctly printed the appropriate information, indicating where it was executed. Additionally, you can see that with this approach it’s possible to access browser-specific global objects, as seen in the screenshot from the browser console.

Using lifecycle hooks afterRender and afterNextRender

The second approach is to use the new hooks introduced in Angular 17. Let's discuss their purpose and how they work and then try to achieve a similar effect as in the previous point.

afterNextRender – This hook is called once after the first change detection cycle, which is launched by Angular. It’s an ideal place for initialization code that needs to be executed after the first render of the component but before any further updates. It can be compared to the OnInit hook, but with the difference that afterNextRender is called after the first change detection cycle is completed only in the browser. This is especially useful when initializing external libraries or browser-only APIs that require the DOM to already be fully rendered
afterRender – This hook is also called only in the browser, every time Angular performs a change detection cycle. This is the perfect place for code that needs to be executed every time Angular detects a change and updates the DOM. It can be used to perform DOM updates based on changes made to the application. For example, if your application makes dynamic changes to the DOM that are not directly controlled by Angular, you can use afterRender to synchronize these changes with Angular

That’s the theory. Let's move on to implementing the required logic within your application.

import {
  ...,
  afterNextRender
} from '@angular/core';

 constructor() {
    afterNextRender(
      () => {
        console.log('Hello from the afterNextRender!');
        console.log(
          'This is current href in the browser: ',
          window.location.href
        );
      },
      { phase: AfterRenderPhase.Write } // Optionally you can choose a phase
                                           when your code should be executed 
    );
  }

Server:

Browser:

You achieved the expected effect and executed your code only on the browser side. Additionally, the new hook allows you to choose in which rendering phase the code should be executed, allowing for greater transparency and readability of the code and easier optimization of its operation (check out the documentation for more info).

Optimizing performance with HTTP data caching

Another useful option Angular SSR offers is the ability to cache responses received from queries. This means that the server will query the data that your application requires and then pass this data to the front-end along with the rendered application. You can easily see how it works by introducing a few modifications to your application.

First, you’ll need to make some small changes to the configuration of your app.config.server.ts file. To configure the HttpClient service used for this purpose, you must provide the provideHttpClient function. It’s recommended, but not necessary, to provide the withFetch() function to achieve better performance (if this option is missing, Angular will notify you about it by displaying a “warning” message in the console).

import { provideHttpClient, withFetch } from '@angular/common/http';


const serverConfig: ApplicationConfig = {
  providers: [provideServerRendering(), provideHttpClient(withFetch())]
};

After adding the ability to query the server, you can now modify the application code so that it performs a GET query. So, let's start by creating a website that will perform this query. You can use the command for this:

npx ng g s SERVICE_NAME

Then go to the newly generated file and modify it as follows:

import { HttpClient } from '@angular/common/http';
import { Injectable, inject } from '@angular/core';


export class AppService {
  http = inject(HttpClient);


  simpleGetRequest() {
    return this.http.get('https://jsonplaceholder.typicode.com/todos/1');
  }
}

As you can see, this website allows you to perform a simple GET query using the popular JsonPlaceholder API, which allows you to download test dummy data easily. This should be enough to demonstrate how GET query caching works in Angular SSR. Of course, nothing stops you from using the data provided by your own server if you have one. Now, return to your application and modify app.component.ts to trigger your query.

import { RouterOutlet } from '@angular/router';
import { tap } from 'rxjs';
import { AppService } from './app.service';
...


@Component({
  imports: [RouterOutlet, HttpClientModule],
  providers: [AppService],
  ...
})
...


appService = inject(AppService);
  ngOnInit(): void {
    this.appService
      .simpleGetRequest()
      .pipe(
        tap((resp) => {
          console.log(resp);
        })
      )
      .subscribe();
  }

As a result of adding the above changes, both in the console of your server and in the browser, you should see the following information.

Server:

Browser:

But that's not all. The above information proves that in both cases, you successfully completed the query on both the server and browser sides. However, how to check whether the received data is actually cached and transferred from the server? Well, nothing could be simpler – all you need to do is examine the source code of your website. This time, you should see the following view:

You can also see here that the server has transferred the information received as a result of the query to the client. This clearly proves that your GET query has been correctly cached. However, it is possible to cache not only GET but also POST queries, which may prove useful when using, for example, GraphQL. To add this option, go to the app.config.ts file and modify the provideClientHydration settings as shown below:

export const appConfig: ApplicationConfig = {
  providers: [
    ...,
    provideClientHydration(
      withHttpTransferCacheOptions({
        includePostRequests: true,
      })
    ),
  ],
};

Angular SSR – Summary

Server-side rendering is a classic technique for creating web applications, and from the very beginning, it has been the default way of presenting content to users. However, over time, it became less popular due to its limitations. Fortunately, thanks to the evolution of technology and changes in the approach to page rendering, SSR is back in a completely new form. With the new capabilities and advanced tools offered by today's front-end technologies, applications using SSR run even faster, are better optimized in terms of performance and SEO, and provide much better user experiences by reducing page loading time (among other things).

The introduction of Server-Side Rendering (SSR) by the Angular team is a milestone in the development of this technology. It opens up new opportunities to create even better applications, taking advantage of everything mentioned above. Even though Angular started officially supporting this technology relatively recently, it’s constantly developing its support and adding new functionalities to provide developers with the widest possible set of tools and possibilities. Thanks to this, Angular fits into the latest trends in creating mobile applications and is becoming an increasingly attractive choice for projects requiring SSR.

Also, if you’re interested in content related to front-end development and frameworks, check out some of the other articles on the Pretius blog:

Angular vs React: In-depth comparison of the most popular front-end technologies

Paweł Żurawski — Mon, 17 Jun 2024 07:51:36 +0000

For about a decade, we have been experiencing an ongoing conflict between Frontend Developers who favor either Angular or React. Many arguments for and against these technologies have been presented, yet both still hold a strong position in the market. So, which one should you choose? I’ll try to give you an answer in this article – based on my professional experience in using both

The state of JS 2022 survey shows that, while over the last few years, many new frameworks have emerged, React and Angular still reign supreme.

The former’s position seems quite clear – while React’s usage ratio has been steadily climbing, its competitors are rising and falling. Even Angular, React’s “archnemesis”, which has been developed for almost 3 years longer, is falling out of fashion (and quite fast, to be honest – it lost 5% of its usage ratio in 2022).

Yet, despite all this, there are still developers who say Angular is almost always better for front-end web application development. Let’s look deeper into this and learn where this opinion comes from, why it might actually be true, and why React probably won’t oust Angular completely any time soon.

A deeper look into the history of frontend

To better understand the differences between these technologies and the advantages and disadvantages of their use, we need a deeper understanding of their concepts. Although both React and Angular were essentially designed to solve the same problem – creating the best possible frontend for web applications in the shortest possible time and at the lowest possible cost – there are significant differences between them. Let’s start by looking at the history and motivation behind the creation of each of these technologies.

Angular

Angular was the first of the two to appear on the market, and it quickly revolutionized the approach to creating front-end web applications. When the Google team first introduced AngularJS to the market in October 2010, it quickly achieved the status of the most popular among the JavaScript frameworks. The functionalities it offered, such as two-way data binding, dependency injection, routing packages and many others, made Frontend Developers quickly fall in love with it. These features helped solve numerous problems programmers faced when creating new dynamic web apps.

As this technology was developed, its level of complexity gradually increased, which caused growing dissatisfaction among the community. This ultimately led to the decision to redesign the entire framework. This way, the so-called “Angular 2” was born. It introduced numerous improvements, such as:

Support for mobile app development – several features and optimizations specifically tailored for building mobile apps. This included enhancements to performance, responsiveness, and user experience on mobile devices.
Improved change detection mechanism – complete revamp of change detection mechanism to be more efficient and performant. This optimization reduced the overhead of detecting and propagating changes throughout the application, leading to better overall performance, especially in large and complex applications.
Support for TypeScript – Angular embraced TypeScript as its primary language for application development. TypeScript offers static typing, enhanced tooling, and better code organization than plain JavaScript. This integration provided developers with a more robust and scalable development experience.
Improved compilation system – introduction of a new compiler called Angular Compiler (ngc). This compiler transformed Angular templates into more efficient JavaScript code, resulting in faster rendering and improved runtime performance of Angular applications.
Clear structuring of application development – addition of a stronger emphasis on clear and consistent patterns for structuring application code. This included guidelines for organizing components, services, modules, and other building blocks of Angular applications. This clear structure made it easier for developers to understand, maintain, and scale their applications over time.
Modularity – implementation of improved support for modularity through features like NgModule, which allowed developers to organize their applications into cohesive, reusable modules. This modular approach simplified application development and encouraged code reuse.
Enhanced Routing – complete revamp of its routing system to provide better support for single-page applications (SPAs) and complex routing scenarios. The introduction of the Angular Router made it easier to define and manage application routes, including lazy loading and route guards, for improved security.
Internationalization (i18n) and Localization (l10n) – Angular introduced built-in support for internationalization and localization, making creating applications that support multiple languages and regions easier. This included features like pipes for formatting dates, numbers, and currency and tools for extracting and managing translation files.

These are just a few of the most obvious improvements, but there are many more. The result is a technology that allows you to create new applications, but also significantly simplifies the management of existing ones, especially in the case of large projects.

Unfortunately, due to the abovementioned changes, the new Angular was completely incompatible with the old AngularJS. Moreover, the development team didn’t provide an easy path to migrate an AngularJS application to Angular 2, which caused significant dissatisfaction among the community. Because of this, many Frontend Developers decided to abandon this JavaScript framework and look for alternative solutions.

Angular never regained its former position, although the team behind it never made the same mistake again. In subsequent versions, the developers always ensured backward compatibility. Additionally, in 2016, the framework version number in the name was abandoned to avoid potential confusion for developers. Now, it’s just called “Angular,” whereas the old framework is known as “AngularJS.”

⏩ Want to know more about the differences between old and new Angular? Read our article on upgrading AngularJS to Angular

React

During the JavaScript conference in the USA in May 2013, a completely new – and potentially game-changing – library entered the scene. React was created by Jordan Walke, a software engineer working for Facebook. It caused a deep stir among the conference’s participants.

The possibilities offered by this framework, such as Virtual DOM, one-way data binding and Flux architecture, seemed to revolutionize the front-end technology scene. Moreover, one of the largest companies in the world – Facebook – recommended this solution and talked about how its introduction helped solve the biggest problems they encountered, further strengthening the message and emphasizing the innovativeness of this solution. React’s popularity quickly began to grow.

The number of libraries extending React’s functionalities also grew along with its popularity. Today, it’s hard NOT to find a library that meets even the most unique requirements. Even the creators of other highly popular solutions, such as Bootstrap, have created versions of their third-party libraries tailored specifically for React. One of the key and most famous libraries is Redux, created in 2015 by Dan Abramov and Andrew Clarke (inspired by the Flux architecture promoted by Facebook). Unlike Flux, the new architecture offered by Redux used only one store, which greatly simplified application state management. This approach was quickly recognized as a revolution in data-flow architecture and helped React attract even more developers.

Currently, React is still the undisputed king among front-end technologies. It’s not only the most frequently used and most popular library but also the best received by the community. This is evidenced by numerous pieces of information, one of which is the chart presented below, which illustrates the interest in learning and using various front-end frameworks.

Image source: State of JS 2022

As you can see, most React voters already know this technology and are willing to use it again. This is the opposite situation to the second best-received framework – Svelte – which a high number of people are interested in using, but much fewer have actually worked with. Angular is also an interesting case – just like in React’s example, the positive reviews mainly come from the people who already know this technology. However, it garners the least interest from potentially interested users, and many of them seem to dislike it after previous experience. As a result, Angular and Ember are the only frameworks with more negative than positive opinions among developers who know these technologies.

Angular vs React: Key differences

Image source: Pexels

To understand the reason behind the division described above, we need to know the key differences between these solutions.

Before frameworks like Angular gained popularity, web development required tedious handling of interactive events, application state management, or integration with the server using pure JavaScript (so-called “VanillaJS”). Moreover, the standardization of good practices and code reusability was very low, which resulted in additional work for the development team. The frameworks I discuss in this article helped standardize these processes and provided ready-made solutions to these problems, but they did so using different approaches.

Angular key features

Angular is often called the “comprehensive and opinionated framework”. But what does this actually mean? Let’s dissect this technology’s main characteristics.

Comprehensive – Angular offers a comprehensive set of tools and features for building advanced web applications, such as application state management, routing, form validation, event handling, unit testing and much more. Angular developers can use one tool to perform many tasks, significantly accelerating application development and simplifying the management of existing apps. This is not only due to the easy availability of the apps but also – and perhaps even especially – because those responsible for the architecture of Angular-based solutions don’t have to tailor them to each individual project. Angular provides all the necessary tools and solutions, significantly simplifying the process of working with the application’s architecture. Angular’s application development method has been proven and improved over many years and is enriched by the experience of a large and active community. This means that most of the problems we may encounter have already been solved by someone, or a solution will appear in subsequent versions.
Opinionated – In fact, Angular imposes certain guidelines and standards on creating applications. Unlike other frameworks, such as React or Vue.js, which are more flexible and allow more freedom in making architectural decisions, Angular has a clearly defined structure and a set of best practices that developers should follow. For example, Angular encourages using the MVC (Model-View-Controller) pattern or its variants, such as the component-based architecture model. The idea behind this approach is to force developers to use a specific, proven application development method. While this approach may seem bad for some, it has many advantages – it helps maintain a consistent structure and ensures greater transparency of the created code. If a developer has participated in at least one Angular project, there is a high chance they will find their way around another similar project.
Shadow DOM – Angular uses the shadow DOM technology to isolate component styles and behaviors. It allows developers to create components with their own DOM (Document Object Model) trees and styles independent of the rest of the application. This helps avoid style conflicts between different components and ensures greater modularity and encapsulation of the code. In practice, it means that the styles defined inside the component don’t affect other application elements but only the component’s / its internal structure. Components separated this way are much easier to manage and reuse within the application.
Dependency Injection (DI) – a fundamental feature that promotes modularity, reusability, and testability within applications. By decoupling components from their dependencies and providing them externally, DI ensures that components remain focused on their specific tasks, making them easier to understand, maintain, and reuse. This modular approach simplifies development and encourages the creation of smaller, composable building blocks that can be assembled into complex applications. DI also enhances testability by facilitating the isolation of components for unit testing, allowing developers to replace real dependencies with mock or stub implementations. Additionally, Angular’s DI system offers flexibility and configurability, enabling developers to customize the behavior of dependency injection to suit their application’s requirements.
Component Lifecycle – a series of methods which encompass events that occur throughout the lifespan of a component, from its creation to its destruction. These events include initialization, content projection, component rendering, and destruction. Understanding the Angular component lifecycle is crucial for developers to manage component behavior effectively. By tapping into lifecycle hooks such as ngOnInit, ngOnChanges, ngOnDestroy, and others, developers can execute custom logic at specific stages of a component’s lifecycle. This allows for tasks such as initializing component data, responding to input changes, and cleaning up resources when a component is destroyed. Utilizing the Angular component lifecycle empowers developers to create more efficient, responsive, and maintainable applications, ensuring proper management of resources and enhancing overall user experience

Unfortunately, the rules imposed by Angular can also be harmful. They require developers to create a lot of the so-called “boilerplate code”, which can result in worse performance, low flexibility, high entry threshold and the need to have advanced knowledge to understand more complicated cases. Despite this, Angular remains popular for many companies and development teams, especially for large and complex projects where code structure, consistency, and readability are key. This solution works particularly well when the company has a high programmer turnover or many teams working on the same project, and requires applications that are scalable, easy to understand, and maintain over a long period of time (like in the banking industry).

React key features

Would it surprise you if I said React wasn’t built for the web? The React package, which you install to start your projects, does not contain web code. So why is it considered a front-end technology and one of the best such solutions on the market? Well, there are some very good reasons.

Virtual DOM implementation – The first thing to understand is that the React library is not responsible for rendering your application. Its task is to generate a virtual DOM shell, define the hierarchy of individual elements, and implement the logic associated with them, e.g., manage their life cycle and the application state (through the so-called “hooks”). For this reason, when someone uses React, they usually use it with a library such as ReactDOM, which provides functions that allow elements in the DOM tree of a website to be modified based on changes made to the VirtualDOM. Thanks to this, instead of rerendering the entire page in the event of a change, it’s possible to modify only the elements that have changed between renders. This means you can update elements in response to data changes, handle user interaction events, and significantly speed up and smooth out the application’s operation.
Minimalistic nature – Unlike Angular, React is a regular JavaScript library, not a full-fledged framework. For this reason, this technology does not impose any solutions and allows React developers greater freedom in making architectural decisions. The React ecosystem includes a wide range of tools and solutions that can be flexibly used in various contexts to increase the productivity, capabilities and efficiency of the React-based application development process.
Lifecycle Hooks – introduced in React 16.8, they revolutionized state management and lifecycle methods in functional components by offering a concise and readable alternative to class components. These functions allow developers to seamlessly integrate state, context, and lifecycle behavior within functional components, promoting code reuse and modularity. By encapsulating logic within custom Hooks, developers can easily share functionality between components, leading to more maintainable codebases. Hooks also simplify complex scenarios such as asynchronous data fetching and event handling, resulting in clearer and more predictable code.

Due to the above, it’s important to remember that React only provides a programming interface for creating and managing the components of user interfaces and responding to changes in the application state. However, this is also why this technology allows for almost unlimited implementation possibilities. There are cases where it was used to create mobile applications (React Native), frame-by-frame animations (Remotion), e-mails (React Email), PDFs (React PDF), CLI applications (Ink), graphics, and even 3D games (React Three Fiber). Thanks to these features React gained enormous popularity in web application development, especially among companies focused on new technologies and startups.

Angular vs React: Detailed comparison

Image source: Pexels

The main difference between Angular and React’s approach should be quite clear now. However, there are many more differences between them. Here’s a quick summary.

Category	Angular	React
Type/Nature	Complete framework	Library
Programming language	TypeScript (JavaScript in the older AngularJS)	JSX (an extension of JavaScript syntax that allows you to use an XML-like syntax). However, it’s also possible to use TSX instead (an extension of the TypeScript syntax), which is more commonly used
Architecture	Opinionated – strongly encourages the use of certain architectural patterns and best practices, particularly the component-based architecture.	Flexible – allows programmers to choose the architecture appropriate to the project’s needs, e.g. Flux or Redux
Rendering	By default, it uses Client-side rendering (CSR), but it also offers mechanisms and tools to implement SSR (Server-Side Rendering) and SSG (Static Site Generation)	By default, it uses Client-side rendering (CSR), but it’s also possible to use libraries that implement other approaches (e.g. SSR, ISR, SSG), such as Next.js
Application state management method	Dependency Injection (DI) tools and services (Angular Services, which can store application state and make it available to other components) are used natively to manage application state. In addition, libraries such as RxJS, and NgRx are also popular	The application state is managed using React Hooks and Context API. However, it’s also possible to use libraries such as Redux to expand the application state management capabilities
Communication with the server	Provides the HttpClient Module natively	No imposed way of querying. You can either use the native JavaScript FetchAPI or use numerous libraries for this purpose. The most popular of them are Axios and React Query
Forms support	Provides Angular Forms Module natively	No default solution. You can use any external library. The most popular ones include Formik and React Hook Form
Testing	By default, Angular provides tools for testing applications, namely the Jasmine framework for creating tests and Karma, which allows for their execution. It’s also possible to use other solutions, such as the popular Jest framework	No native solution. The user can choose any tool to create tests. The popular ones include React Testing Library and Jest
Popular component libraries	Angular Material, PrimeNG, and much more	Material-UI, Ant Design, Bootstrap, and much more
Support	Both frameworks have strong support from the active communities gathered around them and large companies (Google in Angular’s case, Facebook/Meta in React’s case). Moreover, both technologies have very extensive documentation
CSS technology support	In terms of support for standard CSS technologies such as CSS, SCSS, SASS, and LESS, both Angular and React provide similar functionality and flexibility. Both frameworks allow developers to use their preferred styling methods and tools
Ease of code maintenance	The application code is much more transparent and maintainable thanks to the comprehensive set of tools and standards. Moreover, this approach ensures high stability of the created applications	The flexibility and freedom to choose architectural solutions make maintaining the code of React-based applications challenging, especially in the case of frequent developer turnover. It’s the developer’s responsibility to maintain the appropriate application quality. Otherwise, you can encounter problems with SEO, etc.
Application performance	Due to the imposed application development method, apps often have a larger footprint and operate slower. Developers have less flexibility in terms of the solutions used, which may also mean they don’t have as many optimization possibilities	Virtual DOM and the library’s smaller size translate into faster operation. Additionally, the solution’s high flexibility allows developers to optimize application performance more easily. Because of this, React outperforms Angular in many use scenarios
Barrier of entry	To work effectively in the Angular environment, you have to learn its concepts, such as managing modules, services, directives, etc. Additionally, Angular hass a steeper learning curve – it uses many imposed solutions, which may require a bit more time to master. However, this has the significant benefit of not having to think about what is the best way to create a new application – everything is already provided and specified by Angular	No need to learn new application development architectures. If someone knows JavaScript, grasping the JSX concept comes down to understanding that this syntax allows writing HTML-like code directly within JavaScript. Moreover, in React, each element of the application can be treated as a component that contains both the corresponding logic and its presentation
Ease of project management	Managing a project, even a big one, is much simpler. An imposed architecture and the need for strictly defined solutions translate into greater consistency of the code and its structure. Additionally, many potentially problematic issues have a specific native solution, which reduces the time necessary to plan individual stages	React works great for smaller projects with low employee turnover and a high number of complex requirements. Although it’s possible to create larger applications using this technology, since architectural issues are left to the developer, it’s necessary to analyze the subsequent stages carefully and select the appropriate set of tools

Angular vs React: Summary

Image source: Pexels

So, which is better? Well, as you have probably already noticed, the answer isn’t clear and will largely depend on the nature of your business and project.

When to choose React?

React tries to provide developers with the widest possibilities, limited only by their imagination and skills. This translates into a dynamically growing and developing number of libraries expanding its capabilities and attracting more people. It doesn’t impose any solutions on programmers, doesn’t force them to use strictly defined tools, and allows the use of technologies that best fit the project’s requirements and the programming team’s skills.

React is an excellent solution, especially if you have an experienced person in the team who can effectively use its possibilities. It’s worth considering in cases where you need to meet highly non-standard requirements or achieve the highest possible efficiency. React can be a good choice when you aim to keep your project flexible and adaptable to technological changes. It lets you to develop your application without being tightly coupled to specific technologies, allowing you to switch or upgrade technologies as needed without major disruptions to your project. It might allow your software development team to do the project precisely how you (or they) want it which can be a huge advantage.

When to choose Angular?

However, choice isn’t always a good thing. Imagine you have a team of six people, each with a completely different view on solving a given problem. Each of them may prefer other libraries in which they specialize and have no knowledge about the libraries used by the rest. Moreover, it may turn out during the project that their initial decisions led to complications in its later stages.

You won’t face such problems with Angular. It focuses on doing one thing – creating web applications in the best possible way – and reigns supreme in cases where you don’t have a clearly chosen path. It provides all the tools developers need and doesn’t force them to spend time planning what solutions they should use. If your goal is a future-proof, scalable application with code that different developers will easily understand in the future, Angular might be the best choice.

The tools provided by the Angular team are constantly developed and improved to adapt to the requirements of the modern way of creating front-end applications. There’s also a high chance that another team using Angular has already encountered a problem that our team didn’t anticipate and found ways to circumvent or solve (this is also possible in React’s case, but the number of technology combinations makes it less likely). Of course, the price you pay for this is flexibility – you’re bound to lose some when you adopt ready-made solutions and approaches instead of using what seems best in your particular scenario.

Do you need a team skilled in Angular or React?

Pretius has extensive experience in both technologies – we’ve used them successfully in projects for truly big companies. We can help you out! Reach out to us at hello@pretius.com. We’ll get back to you within 48 hours. Initial consultations at Pretius are always free.