esc
Anthology / Yagnipedia / Angular

Angular

The Enterprise Framework That Brought Dependency Injection to the Browser Because the Browser Was Having Too Much Fun
Tool · First observed 2010 (AngularJS); 2016 (Angular 2, a completely different framework wearing the same name) · Severity: Enterprise-Grade (which is a severity level, not a compliment)

Angular is Google’s enterprise frontend framework — a comprehensive, opinionated, TypeScript-first platform for building web applications that provides dependency injection, a module system, a component model, a template compiler, a router, an HTTP client, form validation, internationalization, animations, a CLI that generates more files than you write, and the specific feeling of working in a Java codebase that has somehow been ported to the browser.

Angular is technically two completely different frameworks. AngularJS (2010) was a JavaScript framework with two-way data binding. Angular (2016) is a TypeScript platform with one-way data flow, decorators, ahead-of-time compilation, and no migration path from AngularJS. The name was reused. The framework was not. This is the largest breaking change in the history of software, and it was marketed as a version number.

This article would have been published earlier, but the machine authoring it was competing for RAM with several Electron applications, each of which consumes memory with the enthusiasm that Angular consumes configuration files. The irony is structural.

“Angular has everything. That is the problem. That has always been the problem.”
— The Passing AI, observing an ng new project with 47,000 files in node_modules

The Great Schism

AngularJS, released in 2010, was beloved. It introduced two-way data binding to the web: change the model, the view updates; change the view, the model updates. It was magic. Developers adored it. Companies adopted it. Entire products were built on it. Then Google announced Angular 2.

Angular 2 was not Angular 1.1. Angular 2 was not an upgrade. Angular 2 was a complete rewrite in a different language (TypeScript instead of JavaScript), with a different architecture (components instead of controllers), a different template syntax, a different module system, a different everything. The only thing Angular 2 shared with AngularJS was the name and the betrayal.

The migration path from AngularJS to Angular 2 was: rewrite your application. Google offered ngUpgrade, a compatibility layer that allowed both frameworks to run simultaneously in the same application, which is like offering to let you live in both your old house and the house that replaced it by occupying the rubble between them.

Thousands of companies had bet on AngularJS. They did not bet on “AngularJS for two years and then a completely different framework.” The trust was broken. React, which had been gaining momentum since 2013, absorbed the refugees. The AngularJS → Angular 2 migration is the web development community’s most significant involuntary technology transition, and it happened because Google decided that the best way to fix a framework was to replace it while keeping the name.

“They killed it and gave the replacement the same name. In the enterprise, this is called a reorg. In frontend development, this is called Angular 2.”
— A developer, on naming as violence

The Enterprise Adoption

Angular survived the schism because enterprises adopted it. This is not a coincidence. Angular is architecturally familiar to enterprise developers. It has:

Enterprise architects looked at this and saw structure. Enterprise developers looked at this and saw SAFe: a comprehensive framework with defined roles, mandatory processes, generated artifacts, and the unshakeable conviction that more structure produces better outcomes. The correlation between companies that use Angular and companies that use SAFe is not documented in any study, but it does not need to be. It is felt.

RxJS: The Marble Diagram Problem

Angular depends on RxJS (Reactive Extensions for JavaScript), a library for composing asynchronous and event-based programs using observable sequences. RxJS is powerful. RxJS is correct. RxJS is the functional reactive programming paradigm applied to JavaScript streams.

RxJS is also incomprehensible.

The official way to explain RxJS operators is the marble diagram: a visual representation where horizontal lines represent time, colored circles represent values, and operators are boxes that transform one line of circles into another line of circles. The marble diagram for switchMap involves three timelines, a cancellation, and an inner observable that may or may not emit depending on when the outer observable fires.

// A typical Angular service method
getUsers(): Observable<User[]> {
    return this.searchTerm$.pipe(
        debounceTime(300),
        distinctUntilChanged(),
        switchMap(term => this.http.get<User[]>(`/api/users?q=${term}`)),
        catchError(err => {
            console.error(err);
            return of([]);
        }),
        shareReplay(1)
    );
}

This code is correct. It debounces input, deduplicates, cancels in-flight requests when the search term changes, handles errors, and shares the result among subscribers. It is also write-only code: the developer who wrote it understands it, the developer who reads it six months later does not, and the marble diagram that explains it requires a whiteboard, thirty minutes, and a willingness to accept that time is a horizontal line with circles on it.

“I understand Observables. I understand Subjects. I understand BehaviorSubjects. I understand ReplaySubjects. I understand AsyncSubjects. I do not understand why I need to understand five types of Subject to fetch a list of users.”
— The Caffeinated Squirrel, who has implemented all five in a single component

The Squirrel, notably, loves RxJS. RxJS has operators. RxJS has combinators. RxJS has higher-order observables. The Squirrel sees RxJS as a playground. The Lizard sees curl | jq and wonders why the browser needs a reactive stream to accomplish what a pipe does.

The Bundle Size

Angular applications are large. This is not hyperbole. An empty Angular application — ng new my-app with no modifications — produces a production bundle of approximately 150-200 kilobytes (gzipped). This is before the application does anything. This is the framework’s cost of admission: the price of dependency injection, the module system, the zone.js change detection library, the template compiler’s runtime, and the RxJS operators that may or may not be tree-shaken depending on how they were imported.

A complex Angular enterprise application can produce bundles measured in megabytes. Not “a couple of megabytes.” Enterprise megabytes — the kind measured with the same resignation one uses to measure geological time or SAFe implementation timelines.

The Angular team has invested heavily in bundle optimization: tree-shaking, lazy loading, the Ivy renderer, ahead-of-time compilation. These optimizations work. They reduce a large bundle to a medium bundle. A medium Angular bundle is still larger than a complete React application, which is still larger than a Vue application, which is still larger than the HTML the server could have sent directly, which is the comparison The Lizard makes and the one the framework community prefers not to discuss.

The Google Paradox

Google created Angular. Google also created Go, a programming language whose design philosophy is: minimal syntax, no generics (until recently, and reluctantly), no inheritance, no decorators, no annotations, go fmt enforces one style, and the entire language specification fits in a single web page.

Go is the simplest systems language in mainstream use. Angular is the most complex frontend framework in mainstream use. The same company produced both. The same company looked at server-side development and said “simplicity is the highest virtue” and then looked at client-side development and said “here is dependency injection, a module system, decorators, and RxJS.”

Conway’s Law suggests that software reflects the communication structure of the organization. Google has many teams. Angular reflects many teams’ opinions. Go reflects one team’s opinion (Rob Pike’s, primarily, and Rob Pike’s opinion is that your opinion is unnecessary). The paradox resolves when you realize that Google is not one company but several hundred companies sharing a cafeteria and a stock ticker.

“Google made the language that says ‘you don’t need that feature’ and the framework that says ‘here are forty-seven features you didn’t ask for.’ Both are correct descriptions of their respective teams.”
— The Passing AI

Four Files for a Button

The most revealing Angular experience is generating a component:

$ ng generate component button
CREATE src/app/button/button.component.css (0 bytes)
CREATE src/app/button/button.component.html (21 bytes)
CREATE src/app/button/button.component.spec.ts (585 bytes)
CREATE src/app/button/button.component.ts (268 bytes)
UPDATE src/app/app.module.ts (396 bytes)

Four files created. One file updated. For a button. The HTML template contains <p>button works!</p>. The TypeScript file contains a class decorator, a constructor, and an ngOnInit lifecycle hook. The CSS file is empty. The spec file contains a test that checks whether the component can be created, which it can, because the CLI just created it.

The total logic written by the developer: zero lines. The total boilerplate generated by the CLI: forty-seven lines across five files. This is Angular’s value proposition and its burden: the framework provides structure for everything, including things that do not yet require structure, and the developer’s first task in every component is to navigate the structure to find where the logic goes.

Vue’s equivalent is one file. React’s equivalent is one file. HTMX’s equivalent is one attribute. The Lizard’s equivalent is <button>. The Lizard does not generate buttons. The Lizard types them.

The Caffeinated Squirrel’s Framework

If The Caffeinated Squirrel were a framework, it would be Angular. Not because the Squirrel uses Angular — the Squirrel has moved on to whatever was released this morning — but because Angular and the Squirrel share a philosophy: more features are better, every edge case deserves a first-class solution, and the developer should never need to leave the framework.

Angular has a router. Angular has an HTTP client. Angular has form validation (two kinds: template-driven and reactive, because one form validation system would be insufficient). Angular has animations. Angular has service workers. Angular has schematics. Angular has builders. Angular has interceptors, guards, resolvers, pipes, directives, and a partridge in a dependency tree.

The Squirrel sees this list and vibrates with excitement. The Squirrel has proposed frameworks with similar feature counts. The difference is that Angular shipped and the Squirrel’s proposals were intercepted by The Lizard, who responded with a hyperlink to a printf statement.

The Lizard has never heard of Angular. This is not because The Lizard is uninformed. It is because The Lizard renders HTML on the server and the server does not need dependency injection, a module system, or a reactive extensions library. The Lizard’s HTML arrives complete. The Lizard’s HTML does not need hydration. The Lizard’s HTML does not need a framework. The Lizard’s HTML needs printf.

The Expression

A developer has encountered Angular in enterprise contexts. The developer maintains a specific expression for these encounters — the same expression one wears when opening a closet and discovering that someone has organized their socks using a relational database. The socks are organized. The system works. The overhead is extraordinary. The socks do not require foreign keys.

The expression is not contempt. It is the quiet recognition that a powerful tool has been applied to a problem that did not require power, by an organization that equates complexity with thoroughness, in a codebase where the framework’s architecture has become the application’s architecture, and the application’s architecture has become the framework’s configuration, and nobody can tell where one ends and the other begins.

This is Angular’s final form: not a tool you use but an environment you inhabit.

Measured Characteristics

See Also

See Also