Angular

Everything included, deliberately

Web development offers two broad approaches, and Angular represents one of them clearly.

The first is assembling. A library handles the interface, and the team chooses separate libraries for routing, forms, data access, state and testing. Each choice is made on its merits and the pieces are integrated.

The second is adopting a framework that supplies all of it.

Angular is the second. Routing, form handling, data access and testing arrangements are part of the framework.

The trade is straightforward. Assembling gives freedom to choose what suits and requires those choices to be made, integrated and maintained. A complete framework removes the choices and requires living with what it provides.

Neither is generally correct. Which suits depends on the size of the application, the number of teams and how much the organisation values consistency over flexibility.

Where a complete framework pays

The argument strengthens with scale, for reasons that are practical rather than technical.

Decisions are not repeated. In an organisation with fifteen applications, an assembling approach means fifteen sets of choices. Some teams pick one routing library, others another. Developers moving between projects learn a different arrangement each time.

Projects look alike. Conventions and generated structure mean an Angular application resembles another. Someone who knows one can find their way around the next.

Upgrades cover the whole thing. When the framework releases a version, the included pieces move together. With assembled libraries, each has its own release schedule and compatibility has to be maintained by the team.

These are organisational benefits more than technical ones, which is why Angular appears most often in larger organisations with several teams.

TypeScript throughout

Applications are written in TypeScript, and the framework's own interfaces are defined in it.

This means type checking applies not only to application code but to how the application uses the framework. Passing the wrong shape to a framework interface is a compile error.

The documentation, examples and tooling all assume TypeScript. It is the intended path rather than an option.

Dependency injection

A component declares what it needs and the framework provides it. The component does not create its own dependencies.

The reason this matters is substitution.

Consider a component that fetches data. If it creates its own data service, testing it means the test makes real network calls, or the component is modified for testing, which means testing something other than what ships.

With injection, the test supplies a stand in. The component is unchanged, because it never created the real service; it only ever received one.

The same mechanism supports substituting implementations in the application itself, for different environments or different configurations.

It is a pattern common in enterprise software generally, and its presence here is part of why Angular fits organisations accustomed to that style.

Forms

Form handling deserves specific mention because it is where a great deal of business application work actually goes.

An application centred on data entry has forms with validation rules, fields that depend on other fields, values that must be checked against a server, and error messages that appear at the right moment.

This is fiddly, repetitive work, and doing it by hand across many forms produces a lot of similar code that is easy to get subtly wrong.

Framework provided form handling addresses it directly, which is a substantial part of the value for the applications Angular is most used for.

Who uses it

Angular is used by web developers building business applications, particularly in larger organisations and in sectors including financial services, insurance, healthcare and government, where applications have many screens, substantial forms and long lifespans.

Points to consider

Angular is open source, developed by Google, and the official documentation is the reference for the framework and its tooling.

There is more to learn than with a smaller library. The framework has its own concepts, and productivity comes after understanding them rather than immediately.

The framework has changed substantially across its history, including a significant break between the original version and what followed. Material's age matters when reading about it.

For small applications it is more than the work requires. The structure that helps a large application is overhead for a few pages, and lighter approaches suit that case better.

Getting started

The official documentation covers the framework, its tooling and each of the included areas. Generating a project with the command line tool and building a small application with routing and a form exercises the parts that distinguish it, which is the fastest way to judge whether the completeness suits the work in hand.