ng build my-angular-library --prod
Building Angular Package
******************************************************************************
It is not recommended to publish Ivy libraries to NPM repositories.
Read more here: https://v9.angular.io/guide/ivy#maintaining-library-compatibility
******************************************************************************

The Angular team is under strain

A steady stream of highly skilled engineers has left the Angular team over the last several years. The list is long, but a few notable names stand out:

  • Matias Niemelä
  • Kara Erickson
  • Rob Wormald
  • Alex Eagle
  • Vikram Subramanian
  • Brad Green
  • Ben Lesh
  • Brandon Roberts
  • Olivier Combe
  • Hans Larsen
  • Jason Aden
  • Mike Brocchi
  • Victor Savkin
  • Jeff Cross
  • Rob Eisenberg

That lineup reads like an all-star roster. Were some of these departures collateral damage from the Ivy initiative, which consumed over half of Angular's existence before reaching a stable release?

Ivy likely contributed to the problem, but the reasons run deeper. People who have left the Angular team have spoken openly about burnout, public criticism, and even anxiety. These outcomes rarely stem solely from ambitious deadlines and expanding scope.

For a firsthand account, see Jeff Cross's letter to the Angular team and community and the surrounding Twitter discussions.

Personal harm on this scale typically points to toxic workplace dynamics — environments where micromanagement, abuse, and harassment go unchecked. Effective leadership empowers a team; it doesn't dismantle it.

Given the relentless turnover and internal friction, the Angular team may never move past the Storming phase in Tuckman's stages of group development. Each wave of departures pushes the group back to Forming, resetting any progress they had made.

On top of that, the remaining team members face the constant challenge of navigating an enormous, deeply intricate codebase.

The Angular ecosystem is in decline

For years, the Angular team poured its energy into the Ivy runtime and compiler — an effort aimed at winning the endless rivalry over framework size and speed.

A substantial portion of that energy also went into Bazel, an open-source adaptation of Google's internal build tooling. After years of trying to turn it into a general-purpose toolchain that worked both inside and outside Google, Angular eventually cut ties with Bazel.

Meanwhile, many other parts of this supposedly batteries included framework were neglected.

TSLint takes its final breaths

The Angular CLI ships with a standard set of tools, including TSLint. Given that TSLint is now deprecated, one would expect a tool ecosystem as mature as Angular's to have moved on. That hasn't happened — the Angular CLI lint builder and Codelyzer rules still depend on it.

ESLint support was originally slated for Angular version 10. Now the question is whether Angular will deliver before December 1st, 2020, when TSLint will stop accepting even security and TypeScript compatibility PRs. Anders Hejlsberg, the creator of TypeScript, has said ESLint is faster than TSLint and is what they use for TypeScript itself. The Angular team, however, still cites concerns about memory usage and performance.

For Angular, the TSLint doomsday clock is still running.

Angular Material undergoes a rewrite

Angular Material is transitioning to wrappers around Material Design Components for the Web, a framework-agnostic Google library. From an outsider's perspective, this is a tremendous amount of work with little visible payoff.

For many components, the Angular team will have less say over the DOM structure and CSS classes. To compensate, they introduced component test harnesses. If your tests depend on Angular Material's DOM internals, you'll need to rewrite them to use these harnesses — otherwise they'll break once the component internals are swapped out.

Harnesses require supporting environments. While TestbedHarnessEnvironment works for unit tests across most test frameworks, Angular only provides a ProtractorHarnessEnvironment for end-to-end testing, and it's not even fully implemented. If you use a different e2e framework, you'll have to build your own harness environment, which is no small feat.

Library authors left guessing

I once tried to lay out a clear plan for migrating libraries from View Engine to Ivy, but I gave up. Even in Angular version 10, the Angular CLI and its documentation still advise library authors not to compile using the Ivy Instruction Set. That's likely because the instruction set isn't considered stable or finalized. The original roadmap called for the Ivy Instruction Set to be finalized by Angular version 10.

When I asked someone on the Angular team about the plan, they didn't have an answer. It's possible that Google itself is still working through migrating its own 2,600-plus internal applications to Ivy.

Protractor releases a new version

It appears that the Angular team has taken ownership of Protractor. The tool saw almost no activity in 2019, despite roughly 200 open issues from that year alone and breaking changes in the Selenium WebDriver APIs it relies on.

The team did manage to ship Protractor version 7 and bundle it with Angular version 10. That release still supports the deprecated synchronous Selenium WebDriver API for browser interactions. There's more work ahead.

Angular Elements remain impractical for many scenarios

Angular Elements was introduced years ago, yet Angular still lacks a way to produce a single-bundle custom element or a straightforward method for sharing common bundles across multiple custom elements. Even Ivy's output remains too large out of the box for environments where bundle size matters. And as noted earlier, building a library with the Ivy Instruction Set is still not recommended.

The Zone.js doomsday clock

Zone.js can monkeypatch global APIs, but it cannot intercept syntax like native async-await. Angular's NgZone and the default change detection strategy depend heavily on Zone.js to catch every task that might alter application state.

That dependency blocks us from producing ES2018 bundles, since they would keep native async-await statements intact. Those statements bypass NgZone, leaving Angular applications out of sync with the DOM.

This issue has been known for years but was, until very recently, ignored by the Angular team. By "the Angular team," I mean the management — or whoever is really steering the direction of the framework.

Neglected packages

Despite the fact that many of Angular's companion libraries and utilities have seen steady improvements and new functionality in recent years, a notable subset has either been entirely dropped or received almost no maintenance activity over the same period:

The accumulated volume of open issues and pending pull requests on Angular's primary GitHub repositories has grown to concerning levels, as illustrated in Figure 1.

Open issues on Angular's GitHub repositories over time.

Figure 1. Open issues across the angular/angular, angular/angular-cli, and angular/components repositories over time.

The core Angular team and the Angular Collaborators have made a deliberate push to reduce these numbers, which is visible in the data from June and July 2020. However, this kind of reduction can only be sustained if it becomes an ongoing priority; otherwise the backlog will creep back up.

By late July 2020, the combined count of open issues in the angular/angular, angular/angular-cli, and angular/components repositories was approaching 5,000. To contextualize that figure, it exceeds the combined total of open issues in React, Svelte, and Vue's repositories by more than a factor of two.

Pending pull requests number around 1,000 — that is 65% higher than the combined count of unresolved pull requests across React, Svelte, and Vue.

Adding to the frustration, the Angular team's automated lockbot frequently locks issues once they are closed and have seen no comments for 30 days. This stops further discussion regardless of whether the issue reporter got the resolution they were hoping for or is still waiting on additional input from the team.

The much-anticipated arrival of Ivy has not delivered the dramatic impact many expected. The question remains: what does Ivy actually unlock? Over the last three years, the core framework's public surface has stayed remarkably static.

Highly requested capabilities are repeatedly dismissed as not core framework topics, receive no feedback at all, or are never addressed in any formal plan. The list below highlights a few such cases:

  • Typed reactive forms with strong guarantees
  • Lifecycle hooks exposed as observables
  • Input properties as observable streams
  • Applications that can run without zone.js
  • Angular Elements that function without zone.js
  • Dynamic component rendering that bypasses ComponentFactoryResolver
  • NgModule-free application structures — and beyond the public API surface, the following still need module-less alternatives:
    • Routing that works with standalone components
    • Injector setup that does not depend on modules
    • Tree-shakable providers that work in a module-free context
    • Style scoping and encapsulation without modules
    • Component-level scoping for declarable dependencies
    • Compilation schemas without modules
    • Content projection in a module-free setup
    • Application bootstrap that supplies all required dependencies for a standalone component
  • Switching the language of an app at runtime
  • Loading translation files dynamically
  • Rendering components with live data binding at runtime

Whenever inquiries are made about a public roadmap, the standard response from the Angular team is that one is in development and to keep an eye on the Angular blog.

And so we continue to wait…

As indicated earlier, these technical pain points are just surface indicators of far deeper and more significant systemic issues. For a fuller discussion, see "No, I don't want to become an Angular GDE".