Cover photo by Pixabay on Pexels.
The views expressed in this opinion piece are entirely my own. They do not represent any organization.
You're going down a dark, murky, slippery road and you've lost your way. What do you do? Keep moving while acting like everything is alright? Or stop and ask for help?
The whole Angular community and especially what's left of the Angular team is going down that road in 2020. It looks like it's not all rainbows and unicorns down there. I think we should stop and regroup. It's time to stop pretending that everything is fine. It's not.
The Angular team is hurting
What seems like an unlimited pool of talented people have parted ways with the Angular team for the past few years. Too many to be named, but here's a few of them:
- 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's a dream team right there. Are some of them collateral damage of the Ivy project that dragged along for more than half of Angular's lifetime before the first stable version was released?
While Ivy probably is part of the problem, we have seen people leave the Angular team speaking about burnout, ridicule, and even anxiety. This doesn't come from scope creep combined with overly optimistic deadlines alone.
Refer to Jeff Cross' personal accounts in "Jeff's Letter to the Angular Team and Community" and recent Twitter discussions about this [1][2] for context.
Serious personal injuries like these come from the worst team cultures in companies that enable individuals to micromanage, abuse and harass their peers. Leadership is about enabling your team, not disabling them.
With the constant high churn and conflicts on the Angular team, it seems that they might never get past the Storming stage of Tuckman's stages of group development. Every time a big part of the team is replaced, the team is reset to the Forming stage.
On top of that, the Angular team as a whole is constantly struggling to get to know the huge and highly complex codebase they own.
The Angular ecosystem is falling apart
For years, the Angular team's efforts were focused on working on the Ivy runtime and compiler in a misguided attempt to keep up in the never-ending "my framework is faster/smaller than your framework" prestige war.
In the same period, a lot of effort went into using and supporting Bazel--an open source version of a toolchain made specifically for Google. In the end, Angular ended up parting ways with Bazel after years of failed attempts to make it work as a generalized toolchain usable both outside and inside at Google.
Meanwhile, many other parts of this batteries included application framework were left to rot.
TSLint takes its last breath
Angular CLI comes with a preset of tools. One of them is TSLint. With TSLint now deprecated, we wouldn't expect an ecosystem with such a rich set of tools to still use it. Unfortunately, that's still the case for the Angular CLI lint builder and Codelyzer lint rules.
Originally, ESLint support was planned for Angular version 10. Now we're left to wonder whether Angular will make it before December 1st 2020 when TSLint stops accepting even security/TypeScript compatibility PRs. According to the creator of TypeScript, Anders Hejlsberg, ESLint is faster than TSLint and they use it for TypeScript itself. The Angular team is still worried about memory consumption and speed.
The TSLint doomsday clock is still ticking for Angular.
Angular Material is rewritten
Angular Material is switching to implementations wrapping Material Design Components for the Web, a framework-agnostic Google library. This is a lot of work for no observable difference, seen from an outside perspective.
For many components, the Angular team will have less influence on the DOM structure and CSS classes. To mitigate this, they came up with component test harnessses. If you have tests that rely on the DOM structure of Angular Material, you have to rewrite all your tests to use the library's component harnesses or your tests will break when the internals of Angular Material are replaced.
Component harnesses have to be supported by so-called harness environments. While the TestbedHarnessEnvironment will work for unit tests with most test frameworks, Angular only ships with a ProtractorHarnessEnvironment for end-to-end tests and even that one is still a partial implementation. If you use other test end-to-end test frameworks than Protractor, you will have to implement your own harness environment which is easier said than done.
Library authors are left to wonder
I have tried to outline the View Engine-to-Ivy transition plan for Angular libraries, but I've given up. Even in Angular version 10, the Angular CLI and documentation recommends that library authors do not compile to the Ivy Instruction Set. Probably because the Ivy Instruction Set is not stable and finalized yet. The original plan was to have the Ivy Instruction Set finalized in Angular version 10.
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
******************************************************************************
I asked someone from the Angular team, but they didn't know the plan. It could be because Google themselves are still struggling to migrate their +2,600 applications to Ivy.
Protractor coughs up a new version
Apparently, the Angular team now owns Protractor. Protractor was barely touched in 2019 despite a growing number of issues (about 200 open issues from 2019 alone) and breaking changes in the Selenium WebDriver APIs it wraps.
The Angular team managed to release Protractor version 7 and bundle it with Angular version 10. It seems that this version still supports the deprecated synchronous Selenium WebDriver API for interacting with browsers. There's still work to do.
Angular Elements are still unusable for many use cases
Angular Elements was introduced years ago. Angular still doesn't support a way to output an Angular custom element in a single bundle or an easy way to share common bundles between multiple Angular custom elements. Additionally, even Ivy's compiled output is still too big out-of-the-box to make Angular custom elements usable in environments where bundle size is a concern. On top of that, building a library with the Ivy Instruction Set is still not recommended as mentioned in a previous section.
The Zone.js doomsday clock
Zone.js can monkeypatch global APIs, but it can't intercept syntax like async-await. Angular's NgZone and the default change detection strategy relies heavily on Zone.js to intercept all tasks that could potentially change the state of an Angular application.
This prevents us from outputting ES2018 bundles as this would keep the native async-await statements in our bundles. Native async-await statements aren't intercepted by the NgZone which leaves Angular applications out-of-sync with the DOM.
This fact has been know for years, but has until very recently been ignored by the Angular team. When I say the Angular team, I actually mean the Angular team's management or whomever are the actual decision makers driving the direction of the Angular framework.
Abandoned packages
While many of Angular's subpackages and related tools have been kept up-to-date and received features in the past few years, some have been fully abandoned or received very little care and attention in recent years:
- Angular Benchpress
- Angular Flex Layout
- Angular app shell
- Angular Mobile
- Angular Preboot
- Angular PWA
- Angular Universal Socket Engine
- Angular Universal ASP.NET Core Engine
- Angular web worker platform
- JasmineWD
- Protractor accessibility plugin
- Protractor console plugin
- Protractor cookbook
- Protractor timeline plugin
High number of unresolved issue and pull requests
The number of open issues and unresolved pull requests across Angular's main GitHub repositories have reached alarming levels as seen in Figure 1.
Figure 1. Open issues across the angular/angular, angular/angular-cli, and angular/components repositories over time.
The Angular team and the Angular Collaborators went through a focused effort to bring it down as seen in June and July 2020, but this has to be a consistent effort to get the number down to a reasonable level.
Towards the end of July 2020, the number of open issues across the angular/angular, angular/angular-cli, and angular/components GitHub repositories are close to 5,000. To put things in perspective, this is more than double the number of open issues in React, Svelte, and Vue's repositories combined.
The number of unresolved pull requests are about 1,000. That's 65% more than the number of unresolved pull requests in React, Svelte, and Vue's repositories combined.
On top of that, many issues are locked for further discussion by the Angular team's GitHub lockbot after the issue has been closed and not commented on for a month, regardless of whether the issue creator is satisfied by the outcome or still looking for feedback from the Angular team.
No public roadmap
The elusive promise of Ivy has failed to impress. Ivy is an enabler to what exactly? The past 3 years, the core framework has barely changed.
Highly demanded feature requests are still either rejected as non-framework concerns, they have no response or they are not laid out in a roadmap.
Here are a few examples:
- Strongly typed reactive forms
- Observable lifecycle moments
- Observable input properties
- Zoneless applications
- Zoneless Angular Elements
- Dynamic rendering without
ComponentFactoryResolver - Optional Angular modules--besides public APIs, we're still missing NgModule-free options for:
- Routed components
- Injector management
- Support for tree-shakable providers
- Style compilation and encapsulation
- Local component scope for declarable dependencies
- Compilation schemas
- Content projection
- Bootstrapping components with all necessary dependencies for running and application
- Runtime language switching
- Dynamic loading of translation texts
- Dynamic component rendering with data binding
When asked about a roadmap, the Angular team answers that it's being worked out and to watch their blog for updates.
We're still waiting…
As briefly mentioned, these examples of technical issues are symptoms of much bigger and more important problems. Read more about this in "No, I don't want to become an Angular GDE".
Latest comments (73)
Angular is DEAD
Agree, this article clearly defined the issue in Angular that I've been thinking about during the last years. Angular is dying
Will Flutter face the same treatment? I put myself into this situation and start avoiding google technology stack.
I hate JS framework but simple 90s pure JS won't cut the deal for today's enterprise (brainwash up to some extent) . So I decided to invest in GWT and later on Angular. While I was doing angular I kept an open mind and looked at Flutter extensively in free time.
After learning about this I am worried that investing in google technology stack is an utter waste of time. Google can stop Fuchsia OS development (experiment) anytime without any explanation. As we know they're planning to use flutter to develop apps on Fuchsia. Golang is awesome as well but not spending too much energy on google stack to be safe. Now people will say choose technology stack based on requirement but sometime you choose what you love and enjoy doing it.
Developers need to abandon Angular and switch over to Aurelia. It's a batteries-included framework that has a non-toxic community and a great open-minded core team that value all community contributions.
Rob proved he is unreliable.
Switching to this is a career killer.
It is a bit of a mystery to me that the team management does not take any public position, fully aware of what is otherwise widely discussed, so they must be aware that this is a significant issue. As I have said elsewhere, it is now in the position of "about us without us", and this is not a situation for anyone to be satisfied within the long run.
I decided to give up on Angular, a bloated over-engineered and complex to learn mess! I cut my teeth with Angular and made a lot of money consulting as a Angular dev. I drank the kool-aid and use to champion it. Now I know better, I would never recommend using Angular for enterprise dev, too much time wasted fixing breaking changes. The larger the project the more painful and wasteful these upgrade cycles are, there is angular, rxjs, ngrx and yes crappy angular material with its own set of bugs that never get fixed or accessibility issues that have gone unfixed.
With Angular the developer is forced to (keep) re-learning the eco-system over and over as none of this over-engineer complexity was designed with the developer in mind.
I switched over to Vue.js, it is smaller, a lot faster with rendering, forget the Ivy hype! Plus Vue.js is really well designed and doesn't get in the way like angular does. Easy to learn and to remember skills learned, the routing and global store (vuex) is a joy to use! Gone are the boilerplate coding in Angular + batteries! With Vue.js 3.0 out, switching away from Angular has never been a saner choice!
I ditched Angular since 2015, right when they throws version 2+ at alpha.
I'm moving to Svelte
Between AngularJS, Vue and React, my best experience was with VueJS.
I never moved to Angular it was too much of a shock for me, what if I had many large scale projects already on AngularJS... it would be painful.
And the whole concept of Angular feels like a monolith, like Dojo toolkit and Sencha ExtJS, hard to turn around when things change (e.g. mobile screen size introduced).
Vue 3 with Vite3/Snowpack, ES Modules etc. is a game changer. I mix it with HTML Custom Elements, and use Javascript native APIs to reduce exposure to technical debt and breaking changes in dependencies.
Even VueJS ecosystem is not immune to changes... the Vee-validate is one such example, major version change requires rewrite of the validation code... imagine if just one application has 20 forms and each form has 20 fields... One would be better off working with native HTML5 Validation.
All those supporting UI frameworks like Bootstrap, Ant Design, Material UI, etc... for vue/react/angular/etc were designed as monoliths...
Moving to HTML Custom Elements (aka Web Components) should help make your UI less susceptible to underlying vue/react/angular/etc framework changes...
At the end of the day I do not want to revisit and rewrite what I have written.
The only big advantage I know of having to keep rewriting and updating is that this will help keep one employed perpetually...
Yes but compare the job postings and vue comes in last.
This certainly depends on the region of the world you're looking for jobs in.
How is any of this surprising?
All frameworks and libraries got their ups and downs. The fact that you do not work with a particular framework does not make it ill for others. I don't believe in such post which can easily ruin the interest in aspiring developers. Your MVP award needs to be question!!
I use Angular every day. I contribute code, reviews and docs, speak about it, blog about it, podcast about it, use it at work for many teams.
Choosing Angular 5 years ago was easily the worst mistake I've made as a developer.
It's not like framework choice is written in the stone. In the end if you are good developer you can switch to any of them.
it takes time
Didn't follow Angular or work with it (apart from a "Hello World") after version 1, but with the arrival of React it seems Angular was doomed (and it's probably even being surpassed by Vue in terms of market share).
Reading this article, with the team falling apart and becoming toxic, it's even more doomed than I thought it was.
Frameworks and communities this big don't easily die completely, but they will need some sort of brilliant plan to revive it, or it will wither on the vine. Go down the Web Components path? Go down the Svelte path with a compiler?