Angular vs. React: Compilers (2024)

Both Angular and React deliver the UI as JavaScript: The UI that the end users interacts with in the browser is the result of JavaScript code that has created/manipulated the DOM. In both cases the JavaScript code that is executed in the Browser is generated by a compilation step.

This post is part of a series. Check out the other posts in Observations about Angular vs. React.

Compilation in React

In React the application programmer writes JSX as part of a React component:

class App extends Component {
 state = {name: 'World'};
 render() {
return (
 <h1>Hello {this.state.name}!</h1>
 );
 }
}
export default App;

At build time the JSX is compiled into imperative JavaScript code. At runtime this code is loaded into the browser and executed.

Both Babel and TypeScript can compile JSX into JavaScript. Therefore it integrates easily into a modern JavaScript build setup where either Babel or TypeScript are typically used. Since both Babel and TypeScript support JSX since a long time, React does not dictate which version of Babel or TypeScript you must use in your project.

The compile process itself is quite simple and easy to understand. JSX elements are basically compiled to one simple factory function. Once you start reading about the JSX compiler, you will understand it within minutes.
A thing to note here is that the compiled JavaScript runs against the Virtual DOM, which is part of the React runtime which manipulates the real DOM.

In Angular the programmer writes a template which is then linked to a component by a decorator:

@Component({
 selector: 'app-root',
 template: '<h1>Hello {{name}}!</h1>'
})
export class AppComponent {
 name = 'World';
}

Compilation in Angular

Angular compiles the template to JavaScript which is executed in the browser. However this process is a bit more complicated than in React.

First of all there are two ways how Angular can generate JavaScript from the templates:

• In JIT mode (Just-In-Time Compilation) the template is delivered to the browser as plain text. Typically the template is embedded as a string in a JavaScript bundle which is loaded by the browser. The Angular compiler is also loaded by the browser. When the Angular application is loaded in the browser it compiles the template on the fly and executes the generated JavaScript. Each time you (re)load the application the template is compiled again.
• In AOT mode (Ahead-Of-Time Compilation) the template is compiled at build time by running the Angular compiler as part of the build process. The browser then only loads the generated JavaScript for a given component. As a consequence the Angular compiler does not have to be loaded by the browser and the browser does not have to compile the template each time the application is loaded.

With Angular the app developer has to decide if he wants to use JIT or AOT for a given application. So far in Angular 4 it is common practice to use JIT for development but to use AOT for a production build.

It has been announced that AOT should become the default mode in Angular 5.

The Angular compiler is a complex beast. There are numerous talks at conferences that treat the topic of the compiler … real computer-science stuff!

In a typical Angular project there are two compilers involved: The Angular compiler which compiles the templates and the TypeScript compiler which compiles the rest of the code. As I understand it, in AOT mode the Angular compiler compiles the templates into TypeScript code (the .ngfactory.ts files) and then all the TypeScript code is compiled to JavaScript.

As a consequence there is a coupling between the Angular compiler and the TypeScript compiler. As a matter of fact the Angular compiler is a wrapper around the TypeScript compiler. The Angular version dictates the TypeScript version that must be used in the project.

Ideally the complexity of the Angular compilation process (two modi, two compilers) would be abstracted away from the application developer.

Unfortunately this is not the case today. Projects like the Angular CLI or the Angular Seed can hide a lot of the complexity, but many times the complexity is still leaking.
A major pain point for instance is the fact that the Angular compiler in AOT mode does not support some TypeScript constructs. A list can be found in the AOT Sandbox(however it is not updated to the latest version of Angular …).
The number of issues involving .ngfactory.ts files is also indicating that the compilation process in Angular is not completely abstracted. It is also announced that with Angular 5 the .ngfactory.ts files will be eliminated from the compilation process.

Concusion

The compilation process is a major difference between Angular and React.

In React we have a very simple compilation process, that any developer can understand within minutes and which is supported by the two mainstream JavaScript compilers (aka. transpilers). There is no coupling beween the version of React and the version of the transpiler.

In Angular we have a complicated compilation process that involves different modi and two compilers and the compilation process itself is mostly a “magic blackbox”. And there is a coupling between the version of Angular and the version of TypeScript used in a project.

The question I am asking myself is: Do we gain advantages from the complexity of the Angular compilation process?

I think the main difference between Angular and React in this regard is that React compiles to JavaScript code that manipulates the virtual DOM while Angular compiles to JavaScript code that manipulates the DOM directly.

Also Angular has made a lot of progress since its first release regarding the final bundle size of an application, and that is primarily thanks to improvements to the compiler. But how does it compare to React? Are Angular components inherently smaller or better suited for future optimisations than React components?

I don’t know! I would be very interested if somebody with a deeper understanding of the internals of Angular could answer this questions.