I'm kind of amazed Angular is still around. I hadn't heard of it for what feels like years at this point & assumed it was already in the graveyard. My company tried using it back in 2017ish but it was a pain for us at the time.
Other than Google's own services, does anyone have any examples or experiences using Angular nowadays?
You might be thinking of AngularJS 1.x, the older framework whose API looks pretty archaic nowadays.
It was succeeded by Angular (versions 2 and up), which is very popular for large complex apps at large companies. I think React, in the form of Next and other frameworks built around React, have finally caught up with the reason that made it so: more stuff "in the box", with decisions already made and already working.
If you have 200 Angular projects, there's a good chance developers can move between them without much difficulty. If you have 200 React projects, they might have 15 different combinations of selections for various accompanying libraries. This makes moving developers around harder (matters a lot in large organizations).
For example, nearly every Angular project uses Angular's CSS isolation mechanism plus Sass for complexities on other axes. Whereas there are various popular CSS solutions that divvy the React user community among them.
There are trade-offs, of course; Angular has so much in the box that so far nothing like Next (convention-based routing etc.) has sprung up around it. So I am quite bullish on React and Angular both - there will be lots of large important projects churning along with these in another decade, and beyond.
Also important to remember that these are just the two most popular; there are a couple of hundred other competing SPA frameworks that work very well for their intended use cases.
Wise words, as usual. Angular certainly has a lot of value for larger companies not interested in having big technical stack differences between projects and teams.
You're confusing your own experience for the reality of the market. My last three employers use Angular. My current employer just replaced an AngularJS app with a new Angular 11 app for a Fortune 100 client.
Go to a job listing site and you'll find just as many positions hiring for an Angular dev (often paired with C#/ASP) as you will React.
Big corporations tend to copy what trendy tech companies do, and react dominates that market place. I haven’t look into too much but I’ve yet to see something like a boot camp even teach angular. It’s always react and friends.
I work for a Fortune 500 who has clients who range from Fortune 500 to Fortune 1000, I see TONS of Angular throughout the organization. There's also React, but a lot more Angular being paired with Java. Without data we're all just sharing anecdotes colored by our individual experience.
While that’s fair react still absolutely dominates the FE world, until proven otherwise I have a hard time believing angular is more popular or even close. I’d bet money on it if possible.
Boot camps, job listings, conferences, paid learning materials, etc all favor react in numbers.
Not too surprised - Angular seems more "enterprise-y", and I have a feeling Who's Hiring mostly attracts startups. (well, YC is a VC that primarily does seed funding, after all, so there's not much surprise that it attracts startups and people interested in startups)
I just went to a common job listing site and searched for Angular and in my specific city.
I got 78 result for Angular, 133 for React.
There's a lot more to the job market than just startups, enterprise loves Angular.
I've used it on a lot of client projects, my current one included. Angular's batteries-included approach makes it way faster to spin up a new app for a new project, and avoids the problem of picking the wrong dependency for (state/navigation/styling/etc.) that plagues React projects.
After using Angular for years at large Blue Chip projects I decided to switch over to React projects to see the other side of the isle for the last 4 years.
The atomicity of React makes it applicable in an immense variety of usecases, however this comes at the cost of an ecosystem providing a very fragile dependency graph.
With React you'll almost always have the newest trendy thing available as a tool (and not with Angular)[1]. Which means if someone comes up with a completely new philosophy that might better match your (team's) mental models, chances are it's available for react first.
OTOH this means chances are that the concensus of "how to do things" has changed so much within a short time, that older projects are not only difficult to upgrade, but consist of code that is really, really hard to understand at all.
[1] e.g. there was a time when Google's own Material UI was better implemented for React than for Angular.
But I can't agree more, Angular has for its whole existence of 10+ years always been more consistent. But it's not always about tech - Facebook's Marketing > Google's Marketing ...
Good marketing in this space is also about leading by example and eating your dog food.
Facebook used React internally before releasing it. Every new web front-end at Meta is written in React. They also had a convincing story of how the runtime expands beyond the web (React Native etc.)
With Angular, you’d be hard-pressed to name a Google service built using it. It seems to be a framework created condescendingly for the ordinary others, not the Mountain View geniuses themselves. That’s not great marketing.
The Google Cloud Console is the most notable Google service built with Angular and my experience is that's one of the best advertisements for not using Angular. If even Google engineers theoretically just offices away from the Angular team can't make a performant Angular app, who can?
The Angular Team act like it's a great feature that they don't give "special" support to in-house dogfooding teams, but that just leaves as much an impression that they'd rather just support everyone equally bad. Sure "no special support" sounds great on paper, but it certainly looks like "no support at all" from where I'm standing.
Some Angular proponents will also make excuses that the Google Cloud Console is an amalgamation of components and pages owned by a variety of different teams, like that's a unique situation to Google that no one else deals with bureaucratic scale like that. I guess they haven't experienced much other enterprise development, because that is very common in my experience. If they aren't building Angular for multi-team enterprise applications, what exactly are they building it for? (They are certainly advertising Angular as great for those, even if they are using it as an excuse for why Angular isn't performing well in Google's own usage of Angular.)
Facebook's site is awful, but performance, and specifically the performance of React on Facebook if I feel like watching profiling reports in Dev Tools, is rarely ever my complaint with Facebook's site. (When I have noticed performance issues with Facebook they were network/backend issues, not front end issues.) Facebook seem to have some pretty aggressive performance goals, meet them more often than not, and React seems to benefit well from that dogfooding (as release notes have sometimes mentioned that performance improvements were driven by Facebook's needs).
Anecdotally, having to profile the performance of apps I've built on Angular and React I'd much rather be profiling a React app than Angular any day of the week. I got so frustrated with Zone.js at one point I wrote an entire "Component Framework" for Angular to avoid Zone.js as much as possible and try to remove Zone.js entirely as a dependency in Angular apps that I need to profile.
I used Angular at my last company. After having used react for many years and then experimenting with svelte, Angular (even the most modern versions) felt like it was always in my way.
Bi-directional data binding and the isolation between style, structure, and logic felt was less productive. Angular has some nice properties, like dependency injection built in, but you can circumvent many of those needs with a functional component tree in react (or limit the surface area across components). The simple fact that you need @Output event emitters to handle callbacks is a good example of how bloated it feels.
It may be that I don't know nearly enough about Angular but even after a year of doing my best to learn the idiomatic Angular ways I wasn't impressed.
As someone who is now a couple years into using Angular after a number of years working with Vue (since 1.0) your observations are accurate. It doesn't really get any better as you become more familiar with the framework.
I have found it better practice to generally emit via a service BehaviorSubject that other components subscribe to rather than passing thru outputs and inputs generally speaking.
Angular is very widely used in the enterprise, and I can confidently say that given we make most of our money at Ionic working directly with these enterprise teams. I think Angular has just found where it excels and that tends to be in larger companies.
My last three jobs involved Angular. The second-to-last one was a very heavy application in the US healthcare space. Angular was perfect for that app. In conjunction with Rxjs / ngrx it was extremely powerful. I agree the learning curve was… steep. I don’t regret a minute of it. I moved to another company and I’m doing react now. I was actually hired to support the cash cow written in Angular, but now the company moved focus to full react and we are not hiring Angular devs anymore. React is fun though. I really enjoyed doing a deep dive with Hooks, but I would still work with Rxjs if I could
I've worked at a consulting firm as a dev where we used React for our all of our projects. Given the nature of the industry, we had a fairly high turnover rate with new devs constantly onboarding and older devs moving out. That, coupled with lack of engineering culture, resulted in our project architecture unfolding into what felt like a variety of different brain dumps in a codebase that was difficult to reason with.
It's my opinion that Angular would have safeguarded those projects from a scattered architecture with its opinionated framework, and ultimately resulted in less overhead associated with onboarding new resources and getting them up to speed.
The types of companies you listed aren't necessarily known as being engineering focused, and for a React project to really scale, I think that you need a good engineering culture to make that happen. Choosing Angular alleviates some of that work, and that's exactly what some companies need.
Angular, to me, feels like it was designed by Java developers - classes and bloat* everywhere. Most code, when compared to a React etc. version, just seems like a wall of text on my screen.
But, this might make it more approachable to developers that come from a Java background - I see this at my current employer.
(*) By bloat I mean that I often feel like I should have been able to implement whatever feature I just implemented in half the amount of code.
I've worked at a shop largely split between .Net and Angular, so I can anecdotally confirm this. It makes a lot of sense given the enterprisey background.
The company I work on has a couple of projects built with Angular, however we are shifting to use React.
The reason being: no one around the company likes maintaining those projects because they hate the framework and we haven't been able to hire people willing to learn/work with Angular.
I love the framework as it has almost everything you need out of the box. At the beginning I hated it but as any tool/language once you get the architecture, patterns and ways to build stuff you feel it's a great tool.
Even if they stereotypes aren’t true. They are still extremely damaging to the future of Angular. I also feel the same when the entire history of me hearing angular is of converting old angular 1 code to react.
After having worked on an Angular project for a little over a year I'm at the point where I'm very unlikely to accept another job where they use Angular. It's so frustrating to work with, and every week I find another corner in the framework that, in my opinion, is very poorly designed and/or implemented.
The team I'm in uses Angular and used Angular.js before. The reasons are mostly historical, due to key developer's background. We never had any trouble finding people willing to work with it or who had prior experience. I have a hard time remembering a single instance of when the framework choice was a source of any issue, we'd be just as fine with Vue or React. Sure, Angular has a fair share of annoyances (who doesn't?), but these do get addressed, which is why the v14 feels like a step in the right direction - typed forms, less boilerplate, preliminary work for faster builds. In addition to these, my only gripes are with the router (ui-router was the best), not as big of a community compared to other frameworks and outdated testing tools that come out of the box. For SPAs, it does the job just fine.
Yeah, a bunch of companies use it. It is still the 2nd most popular frontend framework.
Off hand I know it's used heavily at: Google (duh), Microsoft, VMWare, Capitol One and Fidelity.
I used it at Microsoft though there is also a ton of React there. I worked on PowerBI which is/was entirely Angular. The rest I just know from going to NgConf and seeing those other companies recruiting there.
I believe the AWS console uses, or used?, angular, as one can see the ng-* attributes on their elements but I wasn't able to readily find a specific file to confirm or deny that's still the case
Angular is very structurally regimented that makes it great for large complex applications used by large corporations, both for parallel work and maintenance.
I work on a team that maintains a customer-facing web application that is built on Angular. It's been in production for the past six years.
I think Angular not quite in "the graveyeard", but probably only because a lot of large organizations outside of Google have large code bases that are built on it. (Having said that, I forget who they are — VMWare and CapitalOne and such, maybe?)
Still, it is definitely not a hot technology any more (if it ever was... I think the botched "upgrade" from the old "AngularJS" to the (completely different, almost a repudiation of a lot of the core ideas of the original) "Angular" framework shed a lot of users, so maybe Angular was never actually "hot" to begin with).
I definitely wouldn't start any new project using Angular, except in one specific circumstance: you have a large (relative to the size of your development team) body of existing software that uses Angular.
Then, you might want to share components and libraries across apps, and also leverage the skills of your existing Angular-using team.
I do find it somewhat harder to hire for roles specific to Angular development (I think because not many people want to learn it), and I also note that deep Angular knowledge isn't likely to be that helpful when looking for a new job, either. It counts for something, sure, but experience with React is far more sought after, and even Vue or Svelte is likely to be a little more useful.
Angular isn't horribly less capable than those frameworks — it does a lot for you, makes things like accessibility easy^W possible, is TypeScript-based which is overall a big win IMO — but there is, and has been, just too much fuckery around the edges.
I don't think Angular is really keeping up; I'd say it has been slowly falling even further behind the general state of the art.
The rollout of Ivy (its new, more performant rendering engine) was a multi-year boondoggle. It was late, it was painful to migrate to, third-party libraries still haven't really migrated so you still have problems/annoyances using those, and it sucked all their resources away from other important aspects like the Angular Language Service — so we didn't have good completion and linting in editors like VS Code, for quite a long time.
There was also nobody left to fix the testing story. They finally killed off Protractor, their bespoke E2E test monstrosity, after years of letting it languish, but the testing situation with Angular is still really mediocre and sub-par. Modern E2E frameworks like Playwright or Cypress support "component testing" (test components without rendering your whole app) for React and other frameworks out of the box, but not Angular.
AFAICT that is because Angular has this weird "NgModule" system where you construct these Angular-specific module things, and then they can import other Angular-specific module things... so rendering a component is not at all simple. The Angular team seems to be trying to make this optional, and Angular co-founder Igor Minar tweeted some "NgModule becoming optional soon, I think!" kind of teaser... before he left the Angular team and Google. That was several months ago at least; I also think he was the last founder to leave, so there are none left if I am not mistaken.
The i18n story recently finally upgraded to 'meh', after several years of being 'ugh'.
The DX is objectively bad — builds are very slow. There was some talk of taking the type checking out of band, so that it would still happen, but not block the edit-and-re-render iteration loop — but that hasn't happened. So in a non-trivial project that loop (which is typically the main loop) is slow.
Angular does do a lot for you, but in order to do so it monkey-patches DOM to hell and back — every async operation is monkey-patched so that it can do automagic change detection. That works great except when it doesn't work or when it makes things super slow, and it also makes debugging kind of nightmarish IMO — you end up in this 100s-of-frames-deep call stacks going through the zone.js async operation interception library. They are trying to make zone.js optional, too — or maybe it's technically optional now, but not really as a matter of practice.
TL;DR — Angular works okay, but after working with it in production for the last several years, I'd say is pretty mediocre; C- would not use again
It's good to see even experimental support for lessening the reliance on NgModules (which get in the way of appropriate tree-shaking), but I wish it weren't by doubling down on Angular's usage of non-standard Decorators. Requiring an experimental build flag in Typescript to even use Angular at all still feels like a red flag if not just outright poor taste in the framework architecture.
Yeah, that has always weirded me out, too, but I have assumed that because Angular is one of TypeScript's largest and most significant customers, that the flag is highly unlikely to actually be removed.
My understanding is that Babel already removed support for similar decorators to the ones Angular uses because that first attempt at TC39 decorators proposal was entirely revised and replaced with a very different decorators proposal. The "Decorators 2: Electric Boogaloo" proposal has actually made it to Stage 3 in TC39's proposal process this time which means that Typescript is going to be under pressure to add "real" decorators and remove the "fake" decorators that Angular currently relies on. I don't know how hard it would be for Typescript to support both medium/long-term but the transpilation backends for the two proposals are rather different to my understanding. (The new proposal is simpler, at least.)
Angular can certainly migrate to "real" decorators any day now, but my criticism stands that they could have already switched to the desugared form of the new proposal already (which resembles the desugared form of Python annotations) and have been better prepared for a migration. I've got a feeling part of the reason they haven't prepared for such a migration already is that maybe the DI is using too much Typescript-specific support in the "fake" decorators that maybe isn't likely to get carried forward into the "real" decorators.
I do think TypeScript's goal to be faithful to / eventually consistent with upstream ECMAScript would outweigh maintaining the current decorators for Angular.
So perhaps the most likely outcome is that TypeScript will at some point announce the deprecation of the current decorators, and this will cause Angular to have to migrate as you suggest.
So, the most important thing is that they renamed the master branch. Along with the racist slogans “Black lives matter”, those things made me vow that I will never use Angular in anything I can decide on. This madness is going too far and it will bring upon us real fascists.
Angular comes with the advantage of you can learn “the angular way” and it will always be applicable. With React every time you pick up a new project you don’t know what you’re going to get.
I also have some serious doubts about the long term viability of React for what it’s worth. They made some choices early on in the project about how they decided to integrate with the wider web platform that made a lot of sense at the time but are now big liabilities that they can’t get rid of.
Like I wouldn’t consider starting a new project with React in 2022 if I wanted it to still be around for more than 5 years.
My opinion is that Angular is the worst of all the current frontend stacks. It's acceptably bad to a lot of people because "no one ever went wrong using something from Google", but it's just bad, especially for something associated with Google. It's "a horse designed by a committee of people with huge egos" that doesn't do anything it sets out to do well and has a ton of "best practices" and "defaults" that lead directly to "pits of failure" rather than anything resembling success. I've blogged more detailed technical analysis about that if you are interested.
React tries not to be awful and generally seems to have a good idea of the direction it is going. It's not perfect, no tech stack is ever perfect, but as an "expert" at this point on both stacks, I'd wholeheartedly recommend React over Angular.
I have worked with both professionally in team environments.
I have got into technical discussions to back up my anecdotes. As I've mentioned I've blogged them before. I've even at this point built open source libraries to work around Angular technical flaws.
The biggest flaw that I think most other flaws derive from is making the huge dependency on RxJS, but then not trusting it and building in escape hatches that end up making "Angular Best Practices" wind up becoming "RxJS Worst Practices" and performance suffers accordingly. I noticed that even the Roadmap now mentions that they are finally re-evaluating the play between RxJS, Angular Change Detection and Zone.js. RxJS is "push" oriented so why do you need two complex "pull" oriented systems around it?
(In my opinion: Zone.js and Angular Change Detection are these extremely baroque, over-complicated systems that aren't necessary at all if Angular actually trusted RxJS to "push" changes. Or they could skip the huge RxJS dependency and go all in on "pull" like Vue/Svelte. What they have today is a worst of all worlds compromise that benefits no one.)
Or you can read it on my actual blog site but it scrolls horizontally when the browser is wider than tall and that got a lot of hate the last time my blog was on HN that distracted from the contents: http://blog.worldmaker.net/2021/06/26/angular/
While we are at it, here's the Component Framework I built out of what felt like necessity to try to make following RxJS best practices easier in building Angular Components (and make it easier to switch components to ChangeDetectionStrategy.OnPush and apps towards being able to set Zone.js to "noop"), which I built out of some struggles doing performance optimization work in Angular and some patterns I was already following in Component building:
Because of the whole "master" meaning a slave owner thing that the progressive left seems to think it means and it apparently hurt enough feelings to make it a movement (default main branch on Github repos is now also "main" because of this), and then you have companies that desperately try to be hip and cool, and they do this to get social clout. The whole thing is pretty sad if you ask me, but what do I know.
I'm on board for removing 'master-slave' terminology from peripherals and replication terminology. I'm on board for removing blacklist/whitelist. But "master" has other meanings besides subjugation. In particular, proficiency or perfection. It was always my sense that git master branch was meant in the same sense as 'gold master' in recording and duplication, or 'master piece' in art and skilled labor.
That said, branches come from trunks, not master or main, and it always felt like a bit of fuckery that git changed the subversion terminology that most of the eventual target audience was already familiar with. Changing to "main" is just confidently incorrect grandstanding. If you're gonna 'fix it' then bloody well fix it.
Git got "master" from closed source SCM Bitkeeper (the Linux kernel team never used Subversion) which did have a concept of "slave" branches as it used master/slave style replication. It's an unfortunate default closer in originating usage to the peripheral and replication terminology than the "pristine copy" terminology.
Changing to "main" is often as much for not breaking a lot of people's muscle memory of "ma<tab>" in the CLI as any other reason to name the default/main branch that. "default" is a good name, too. If you want to use SVN's "trunk" go for it, that's a good name. At this point most git tools don't care what you call it.
I keep going back and forth about whether I should respond to this, so I just upvoted you instead, but now I'm third-guessing myself.
If that's actually the case about BitKeeper then 1) what the fuck, guys, and 2) I'll be thinking hard before I roll out that little rant again. Standing next to a bad actor, you have to gauge your behavior more carefully, because a reasonable response now has additional connotations. Laughing at a joke changes depending on who is telling the joke, for instance.
The part I still feel fairly confident about though is that it feels like someone needs to tap the brakes. It feels like we're on the brink of going too far with this one. And I don't necessarily mean 'witch hunt' style, although that thought has occurred to me more than once. I mean more like diminishing returns and backlash. Maybe we should be wrapping this up and looking for a new problem to fix? Or at least asking the question. Perfect is the enemy of the good, and we haven't really achieved 'good'.
It wasn't the worst mistake that Bitkeeper made in its history. Bitkeeper is going to be an interesting historical footnote for the mistake of dropping the Linux kernel and subsequently prompting the creation of both Mercurial and git.
> Maybe we should be wrapping this up and looking for a new problem to fix?
I feel that we mostly are. It's barely an aside in these release notes and most of the comments are just people still antagonistic to the change, but at this point all the major git repo hosts have made the change for when you init new repos and even new base installs of git itself when you go to git init either have the new default or prompt you (depending on which distro you install, I believe). Like I said, "main" isn't the "perfect choice" but for most of the git tools builders (the major hosts, and git itself) it's good enough and has wide enough support it's "the winner" and has been for several months now. But the tools themselves are happy to let you still use the old default if you don't feel like migrating or personal choices if you don't like the new default. It's all "good enough", and not trying to be perfect.
Renaming branches is mostly just a folder rename, so what harm does it do to just rename the branches? (If it causes some small feeling of harm reduction/justice for those that do object to the old default name, isn't that reason enough?) I'm going to quietly rename branches when I see fit. I'm also not going to force anyone to rename branches if they don't feel like it. That seems to be where most of the tools have landed, no one's forcing the name change, many are suggesting it, but as an action itself it's barely a footnote in Release Notes.
At this point it seems increasingly silly to relitigate why we should stick with the old default instead of just shrugging and moving on to the new one. I don't think your rant was specifically designed to relitigate that, which is why I replied to yours specifically with added context that I thought you might find useful, but some of the other comments in the thread are more questionably about that. The decision has been made: by major corporations listening to their Diversity and Inclusion boards, by the git mailing list itself and even including the developer that chose "master" in the first place without any malicious intent behind it and in general more because of "momentum" than intent, etc. The remaining, recurring complaints seem more about political parties and "anti-virtue signaling" as much as anything technical. (Those same complaints suggest that renaming branches/folders is just "virtue signaling", so complaining about "virtue" as a goal seems it can only be "anti-virtue", right? Our language has gotten so corrupted by social media.)
It takes a few minutes to switch. Maybe a bit more to rebind all CI scripts etc in a project as large as react. There are some things that I don't fully get (slavery was never big in my country).
It takes a few minutes of effort to not be an asshole (real or perceived), so I just do it rather than thinking to much about whether or not the wider population should be offended or not.
We do not have a monorepo, and you can practically watch the gears turn when we mention any process change that involves changing the CI scripts. And this part may be projection, but I am nearly certain I see people subconsciously avoiding solutions that involve systemic CI changes.
I got tired of making clerical errors or helping others fix theirs and went through and moved a bunch of configuration out of our CI configs into source control. So for my projects making changes is easier, but I still bump into mature projects that still have the old patterns because nobody even wanted to edit the configs one last time.
I fully understand not changing for that reason and don't think anyone would think less of a justifiably difficult situation.
But at the same time, what you described is probably indicative of deeper issues which should be considered technical debt, not because of political correctness but because there may be other inflexibility which inhibit productivity in the future.
Not wanting to be seen as an asshole is how we end up with a never ending stream of bullshit because no one is brave enough to stand up. How much time has been wasted on feel good crap that serves only to give the illusion of caring.
Big tech is happy to rename their git branches while doing nothing about the actual evil they commit.
You seem upset? Github, Bitbucket, Gitlab have all switched to main, together. You know who isn't upset? The git community or the person that introduced the master concept or the people who know you can name your default branch to anything in under 30 seconds.
There is nothing wrong with trying to use more inclusive language regardless of said reasons, and to be honest main is actually a better name anyways.
I'd say it's not even only a racial issue (but predominately was/is in the United States), but a socioeconomic one, with racial correlations.
There are plenty of modern day indentured servitude exploitations afoot: the leaked internal Amazon documents about it being business policy to keep engineering hires for less than two years, while preserving managers who fire them, is an example that springs to mind.
Is it still the case that Amazon gives new hires a hiring bonus that has to be paid back if they don't stay at the company for a set amount of time? If you're also targeting fresh college grads...
That's not exactly indentured servitude but it's too close to the Island of Pleasure (Pinocchio) for my comfort.
Which part of that meandering article should make me "want to guess again"?
Though I like this sentence: "So it’s not so surprising that the masterminds at Sears came up with the master plan: As masters of their craft, they mastered the art of capturing the imagination of the American homebuyer."
When commenting about contentious topics like this, IMO you should try to be as inclusive as possible. Slavery has harmed people of all complexions and it creates unnecessary divisions when you discard the trauma of so many people who have suffered under it.
In technology master was always paired with slave, so yes, the word master in technology does indeed imply the meaning of slave owner.
I do agree that getting that bent out of shape about the semantics of the names of inanimate objects like git branches is a bit weird, but then I am also talking from a position of privilege and have no lived experience of being treated differently because of my ancestry. The way I figure: if some people care that much that it is called “main” and not “master”, and I don’t really care either way, why not let them have that one?
Other than Google's own services, does anyone have any examples or experiences using Angular nowadays?