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".
Top comments (73)
So Angular hasn't been doing well for a while now. Many devs have stepped away from the framework when it moved to 2.x and its not weird to see that happening. But I still think there are enough companies remaining to keep the framework alive. Something needs to happen at google to reorganize and perhaps take a few major steps (like removing some of the toxic but brilliant minds to get a more stable work environment). I don't believe the people that left are really the issue, there's a few guys leading the project that are difficult to handle and its time to get rid of them. Even if they mean a lot to the project.
Next a couple of things about the issues mentioned. Every project has those and its not that uncommon.
Right now I think we should give Google a moment to organize and see where this is going. If by the end of the year its still in terrible shape, people should consider forking the project and take control ourselves (or have some other company run things). I wouldn't be surprised if a company like Microsoft is willing to take over, seeing how much they have been investing in Open Source and TypeScript. Perhaps improving the compatibility and portability of C# to web or something fancy.
These past few years have made it clear that Google doesn't really have a lot of interest in Angular, but their alternatives are also slimming down. Lots of people move to their competitors (React/Vue) and it doesn't look like Polymer is really getting there either (that project is in worse shape imo).
Overall I don't really see a need to start using other products, especially in the app-style projects that Angular is currently being used for. But yeah, the community needs to take a look and wonder if its still in the best hands at Google or that things need to change. You made a nice list on where they could start to focus on, but I think we should give them a bit of time. And instead of turning articles into doomsday negativity, rather give them feedback to build on and work together to get the project back on track.
Microsoft is investing in React and particularly ReactNative recently, with support for Windows et MacOS. Supporting TS does not imply supporting Angular ecosystem, we React devs also like TS.
I don't see how Microsoft is going to take over. They're pushing Blazor.
As long as Blazor requires shipping a several MB client-side runtime or a chatty WebSocket connection, it only makes sense for enterprise. Angular shines in enterprises, so I guess it's a fair comparison.
Several MB that is cached on the browser isn't a big deal for enterprise users. Having a poorly supported framework with infighting between management and developers is.
Be a bit serious. Using formulations like "Many devs have stepped away from the framework when it moved to 2.x and its not weird to see that happening." and pointing on the version 2.x, where everything was created from the ground, doesn't sound me as a serious argument. On the other hand, I understand that there are some people who still like AngularJS.
A few people missing from this are Tobias and Chuck. These two were... irreplaceably smart. Not sure if Rob Eisenberg belongs on this list, too. But... if we're going as far back as Jeff and Victor leaving... it seems like that may be appropriate. Also, I think it is valid to say that we lost Jules. Even though we got her back, she did leave once. I think it is better that she is here. But... she did leave.
I feel that there are more too, though.
Kara is leaving for a well deserved promotion on another team at Google. Brad also left for a great opportunity. When Jules left, it seemed that it was also for a good move. Those are good moves.
Too many of those on your list, though, corroborate the same stories of manipulation, control, and abuse. Once more than one person says something, I tend to start listening. Once it's up to over half a dozen... if you don't listen you're choosing to enable the abuse.
You know I love you Frosty :). But I know from personal conversations with some people you mentioned, their reasons for leaving aren't necessarily as positive as they seem. I don't want to speak on their behalf, so I'll leave it at that.
But your point is valid, some people have left the team because they were just presented with better opportunities, not to escape. I think it's a minority though.
When I left the Angular team, it looked positive because Victor and I were starting a company! It ended up being great, and I talked openly/publicly about all the good reasons to start Nrwl, but I didn't speak publicly for another few years about what really pushed me away from the team. You and I were friends back then (and still are), so you knew exactly what I was going through, but most people only saw the happy story.
So lets make 2 thought experiments:
We continue (the Angular team, and community) down this same path for the foreseeable future. What happens?
We stop and ask for help. Assuming we can get what we want within reason, what should be done, in what order? Whats the "perfect version" of Angular?
Obviously these are thought experiments and I don't think there are any wrong answers to either, I'm just curious as to what sorta options there are.
I would hope Google get's Angular back together. If not it may end-up in the Google graveyard, where Google just uses something else internally. (Like Polymer, which is used on a bunch of user facing apps already) I honestly could see this happening. Probably not fast in any respect, but slowly and painfully.
I'm honestly not sure what the "best" move would be at this point. Obviously better leadership internally seems to be a big factor. This is open source, and a fork (gasp) might happen. Due to the surface area of Angular, this might be an insane
task in itself.
PS comparing Angular's combined issues to React and Vue seems rather unfair in that neither have nearly as much code/surface area as core Angular repos (the three listed and combined)
I would propose two things: First, change the governance model of the Angular project to be more transparent and more open to collaboration with the community, particularly non-Google entities like Nrwl. This could involve transferring ownership of the project from Google to a foundation.
Second, be realistic about engineering capacity vs. ambition and reduce the scope of the framework's core to what can actually be maintained. Move some parts of the framework out of the core into community-managed projects. For example, both reactive forms and the router have seen very little attention from the core team, but as long as they are official parts of the framework, it is very difficult for alternative implementations to gain traction.
My thoughts exactly.
Thank you, those are great suggestions. I don't have an answer, but something needs to change. We need to be discussing issues and alternatives like these in the open.
Move some parts of the framework out of the core into community-managed projects.
Hell no, look where did that get react native
Where?
All news to me, but as I read Jeff's letter to the Angular Team, it described something very familiar to me.
2 Root Causes of a Failed IT Utopia
Bad Management
Self appointed CZARS
There are self appointed CZARS at every corner of the IT workplace. These are the zoomers. Their intelligence is often over the top, but they are anti-social. They are self appointed spies attempting to win at any cost. They sabotage anything that may zoom past them (upward). They keep the lid sealed on entire teams. Sometimes management buys in hook, line and sinker.
Amiable Zoomers are people that are promoted for being nice. They are often not top notch technical folks, but work on anything as directed. They can cause PTSD too because; as managers, they never address anything for fear of offense.
How to Spot Toxicity Early
It all boils down to one easily identifiable trait, Selfishness! We all know what selfishness looks like. We need to assess our environment regularly asking just one question. Do I feel included in this effort?
You should NEVER feel like a foreigner, or a low-life less-than-par person.
Angular will Survive
Comparisons of the past
Today there's new rages brewing like HTML5 Components (which hasn't taken off like it should). Rust is even being adopted by MSFT? IE is now using Chrome Engine?
To the Metal
Should we ditch all of these framework in favor of HTML5 components that are closer to the metal? Yes. But we won't because it's way to convenient to return to our old pal Angular. We know it, it works and we are tired of learning new things every other day.
BTW
The pain Jeff described is a very real thing, the idea that we go to our workplace torture chamber everyday, and staying because we "believe the dream". This Leads to heart-attacks, super-low self esteem, bad eating habits, high blood pressure and treating family members poorly etc.
Jwp
The developer experience of Angular isn't that bad at all. I currently re-learn Angular with v9 and v10 and see a lot of appealing features:
Well, the upgrade from v8 to v9 was not so easy due to Ivy, but I only had to migrate one library of my app to succeed... and I'm a total noob in frontend development. So should I worry about all this stuff, even though I'm quite happy with my Angular based app?
If you're happy, don't worry about it. To be honest, if your app is small to medium size and not very complex it doesn't matter much which framework you choose. People issues (communication, lack of requirements etc) are often way bigger problems than the technology choice.
That said, we started with Angular 2 and are now on version 10. My experiences with it haven't been that good. From build issues to having to write lots of workarounds and custom components because features are broken, half-baked or don't exist. It's quite a big application and a pretty complex one at that. And since the upgrade to Angular 9 the dev server has been incredibly slow.
I see quite a few people mentioning the fact that it's a 'complete' framework as a pro. If it was flexible enough that you could easily switch parts out in case they didn't meet your needs then I'd have no problem with it. The thing is, with Angular you're often stuck doing it 'their' way, otherwise you're out of luck. I like the way how Vue handles this. Vuex/vue-router are maintained by the core team so you know those always integrate well, but if you really want to switch them out you can.
RxJS itself I like. In some cases streams make things a lot easier, but I don't like it when a framework forces me to use them in situations where they aren't adding any extra value. It's also another thing to learn and I find that many developers don't understand them well enough, and do things with them you really shouldn't (subscribe within a subscribe, settings variables outside of the stream, forgetting to unsubscribe when not using the async pipe and so on).
I have to disagree with the good documentation. I find it only covers the basics. Anything beyond that I just google right away because I'm never able to find it in the documentation.
Most upgrades are easy yes. But most of those releases are just minor, not major like the version number would suggest. My main issue with the releases is that I can't even remember the last time there was actually something in there that would make my life easier. I often find that the typescript improvements that come with the upgrades are the ones I'm looking forward to the most, which is sad. Improving bundle sizes and so on is a good thing but it doesn't make the development any easier. I use Vue as well and I feel that team has a much better grasp on what's important to developers. I see quality of life improvements basically every single release.
Typescript is very nice but you can use it with almost any framework these days. It has its own quirks as well though.
What I've never been able to understand is why people say Angular provides more structure. They provide a default folder structure, that's it. The way code is structured is still completely up to the developer. If you don't have developers who really care about code structure/architecture and simple solutions you will inevitably end up with a mess, no matter the framework used. It's a people problem, not a framework issue. I personally find it easier to make a mess in Angular because of all the workarounds needed when the framework forces me into a more complex solution.
I will never choose Angular again if I have a choice. Vue and React can do anything Angular can do, that's not the case the other way around. You just don't have the flexibility in Angular and it especially lacks features when it comes to dynamic components. If I could I wouldn't even use a front-end framework anymore and just use Elixir/Phoenix/LiveView :)
If you enjoy working with Angular and it does everything you want then don't worry about what anyone else says. No matter what you choose there's always a compromise. I've been programming for over 25 years in lots of languages so I've seen my share of code and formed my own opinions. And there's always more to learn. Have fun, learn more about Angular. See what you like/dislike. Do what makes you happy. You'll write your best code when you're enjoying yourself.
Re: Protractor
Protractor has been under the Angular umbrella for a while. Protractor 6 was going to be the big move to the most recent Selenium Webdriver version to nix the Selenium baked in Promise handling and go full into async. With how hard Protractor leaned in to wrapping Selenium, including maintaining their webdriver-manager package for getting the latest browser drivers, I'm not terribly surprised that got shelved.
I've been following that for a year or so so they were trying to move Protractor forward for a while. My understanding of the diff between 5 and 7 is more just bumping dependency versions since all the actual work for the past year+ was in 6. On one hand, I'm glad I don't have to rewrite my tests that are a weird blend of forcing Protractor to work in ES5 if they had bumped versions. On the other hand, though, you're right that they just coughed up a version to look like progress when their 6 release didn't pan out.
Interesting thing about the 6 release was when they did it, it was out for a bit before they pinned the npm package at the latest 5 release, before doing another 5 bug fix release, then doing a 7 release... 6 existed and was out for a few months. The problem was downloading it meant you needed to be on the bleeding edge of everything else in the Google ecosystem. I'm not writing e2e tests for beta Chrome versions and pre-release versions of Selenium... so I kept to 5. Checked back a month later and they removed 6 from the versions list and were on 7 as a marginal bump from 5.
TL;DR: Protractor 6 is like Angular 3 -- it never happened.
Re: the list of names: Aww, Brocchi is one of the best people
Cypress has disrupted all Selenium products. Selinium is in sunset mode.
Eventually. I'm more interested to see how things shake out when it's not the new hotness.
For the sake of a thread about Protractor, though, Angular apps will always benefit from the coupling Protractor has with the Angular hooks. As long as Protractor is around, I wouldn't use Cypress for Angular E2E.
New hotness for Cypress? It won't shake out because it's just easier to write e2e tests than Protractor. But unlike protractor, it's inbound and outbound http interception allows it to be way more than just for e2e tests.
The javascript community and in particular the React people scream the superiority of declarative programming every day. Cypress is the declarative king for test.
Protractor has been disrupted.
It's fine that Cypress is the new king of React testing or whatever.
For Angular, I'd still use Protractor. Because Protractor is specifically made for that framework.
Anyone who was using Protractor for React/Vue/etc was using a hammer as a screwdriver so any screwdriver is going to work a lot better.
Interesting because even though Protractor has been around since before the Angular CLI, the Angular schematics to this day don't use Protractor. Instead they spin up the ridiculous Karma/Jasmine tests for each new component. Using Protractor has always been a choice whereas Karma/Jasmine were defaults.
But Karma/Jasmine solutions are ridiculous in my opinion. The Angular Testing Library is plug replaceable with Karma/Jasmine and a much better product.
Still Cypress reaches deep enough into our applications that it's now my preferred and only "real" test framework, I still use Angular-Testing lib, but don't spend much time on each test.
The end-to-end test suite generated when creating an Angular application project with Angular CLI is using Protractor.
Protractor has the benefit of hooking into NgZone. Cypress sometimes has issues with waiting for an element to appear. You end up having to put random timeouts into your tests to wait for Angular to stabilize. Sometimes it works, but it's a flaky test waiting to fail.
Protractor is able to support legacy browsers like Internet Explorer and Edge Legacy.
Thanks for the reminder Lars, yes Angular sees Protractor as E2E and not unit test.
What do you think the path forward is? I would love for Angular to get back to the days when the community was excited about the next release.
Crap, I don't follow Angular development and did not know about all this shit.
We use it in most of our projects at work and I'm kinda freaked out about this TBH. I'm going to talk to my manager and see if we should take a closer look at the whole situation.
Personally I love angular, it's a shame it has fallen in such a path, shame on you google.
Amen !
Can you link to discussions on Angular Material switching to Material Component styles?
It's mentioned in the Readme. Work is in the @angular/material-experimental package. github.com/angular/components#what...
As someone who just started learning Angular this is sad and concerning. I love angular and everything about it. I don't want to go back to React 😭
React has gotten a lot better. Hooks really saved it, and they came out of beta over a year ago. TypeScript works really well with React now, too, and there's a lot of projects like Navi and TypeStyle that are implemented in TypeScript and have excellent React support. I've also heard good things of React Query (not to be confused with jQuery... I suppose it's been long enough).
Also, look into Redux Toolkit, it's not the same Redux of old. Gone are the case statements for object literals, and immutability is managed, allowing developers to take shortcuts instead of doing immutability gymnastics. Most of the time you won't need Redux now, or if you do, it's only for certain parts of the app, and it's quite clear where the separation of concerns should lie.
There's more exciting stuff we're seeing already implemented, just not yet out of beta, and the transparency of the React community is pretty good. There was a bit of Twitter drama about React a while back, with it being heavy, and some devs having toxic reactions, but Dan does his best to lead the community by example, by his approach. A developer's approach can be even more important than the solution.
Nahh I feel Chandler, working with React in big projects is a complete nightmare, I know Hooks and worked with hooks for a while now and they are just a mess, every single dev I've worked with in React has a different way of implementing hooks, their own 'Custom Handmade Hooks' and for me is an organizational chaos.
AngularJS was a sensation.
ReactJS fucked up AngularJS and was a sensation
Is time to look for a better solution to React, it's almost impossible to see 2 React projects with same structure, is so free that in the same company, if you are moved to another React project, you need to relearn the whole React structure used there to understand and work on it. Angular fixes this, if you don't follow good behaviors in angular, you're doomed.
I agree with you on most points but just as Chandler, I'm running away from React, React devs and React ecosystem.
After using React, Angular and Vue
Vue > Angular > React
In user experience and organization, not even performance and documentation, using React makes me want to quit Web Dev completely
Exactly my reasons. It's the wild west. I feel safe in Angular and when I pull up a repo I have a good idea how it's going to be laid out. I don't think I'd go back to React. Listening to the podcast on the Angular show made me feel better. I think there will be some changes.
I see your point, and I think it has some validity, but in practice, I'd never seen a React project that surprised me by its novelty.
One could argue that the lack of a prescriptive folder structure, standardized routing scheme, and a styles stack everyone uses, has hurt React. I'd actually argue the opposite. The diversity of thought and inclusiveness of ideas based on their merit is better than leaving thousands of pull requests hanging.
I think the diversity of thought and idea inclusiveness has served React well in that, if you're not happy with something, pull something else in. And with basic tooling and testing, such as TypeScript, ESLint, Jest, and Cypress, these refactors tend to go well.
One could also argue, React has taken the Unix philosophy and applied it to the web. Do one thing, and do it well. Sure, it could be said that React didn't do things well in the past, but also, we once wrote websites in jQuery and Backbone, so, tech gets better all the time.
I've refactored projects with hundreds of thousands of lines of React code alone, for Fortune 500 companies, and our tooling improvements alone resulted in a dramatic increase in developer productivity, but that's just been my experience.
But the negative impact so far is non existant. Angular 10 is working much better than all prior releases.
React is simply gaining more popularity every day.
Since writing that there was a Podcast episode on the Angular Show that made me feel better. Besides I continued on my learning journey and I couldn't be more happier.
I feel the same way, Angular appears to have overcome a lot of compiler and web-pack interface issues with Angular 10. I just don't have any of the same issues I had before. I'm pretty sure the real culprit was NPM package system anyway which continues to be a terrible module delivery system.
Many years ago the desktop environment went through a similar module loading issue known as dll hell. But both Java and C# solved that problem each having loaders that supported name spacing. What NPM can't do that is simply dumb. There's something to be said about a closed system framework like .NET or Java, they don't have these huge and very deep hierarchies like the node_modules folder shows us every day. In addition security threats were minimal back in those days.