Why Angular Will not Survive 2024

Angular will surely drift into oblivion before the end of 2024 if all of it isn't already dead. I know some people are going to read the above and be like you don't know what Angular is about. But I'm going to ask you this when was the last time you used Angular for a new project? Except you have sold your soul to Google and decided to stick with Angular then I'm going to say that your answer was "it's been a long time".

The die-hard Angular fans in the room are also going to come back with how Angular is being used across large teams and on some complex applications. But I'm going to tell you that there's nothing that you can do with Angular that you can't achieve with other frameworks with much less effort than in Angular. In today's post, I'm going to go over five solid reasons why I believe Angular will be dead to developers before the end of 2024.

• Typescript Barrier
• Not Beginner friendly
• Bundle Size
• Too much restrictions
• It's just too Overpowered
• Fierce competition

Typescript Barrier

From the moment Angular adopted a Typescript first approach to building UIs it marked the beginning of the end. As good as this decision may seem it comes with some potential drawbacks. Yes, we get the benefit of type checking in our IDE but the fact that you have to learn Typescript first before you can start using Angular introduces a major barrier to entry for some developers.

Most developers would be okay with just learning and using Javascript and trust me telling them that they have to go learn how to use a superset of a language they barely understand will not yield any positive results. Many developers shy away from angular because of Typescript. It's only the experienced 10X developers who see Typescript and Angular as a win-win. How convenient it would be for newbies if you could use Angular with Javascript then maybe Angular would have been adopted much more than it currently is.

Angular is not beginner-friendly

Angular do not like beginners and newbies and it doesn't deal any kindly with them. You see Angular was designed to be used on complex web applications and as such it comes fully fledged with everything you need to build and deploy a modern web app. However, all this is not sold to the developer in a way that is simple to digest, and most of the time you need to make use of the features Angular provides when building an app so this demands that you have a strong command over the framework or else you're not going to have a great experience. Angular needs to give more consideration to making Angular more friendly to beginners and that will go a long way in seeing more adoption.

Bundle Size

Angular has an unholy bundle size. I believe that it was for this reason that devs came up with solutions like Astro. I once built a very simple app with Angular. It had just two pages. One for showing a search bar where users would search for what they want from GitHub then another page for showing search results. When I was done and tried to deploy to Vercel, oh my God it was so unfortunate because I had issues building and deploying the app because of bundle size exceeded the threshold.

This was so frustrating because I spent at least three days doing that. I had to look for all the things that made the bundle size so large. It was so frustrating I had to deploy with Codesandbox instead. My point here is that when you compare the Bundle Size for Angular to the Bundle Size for other frameworks you'll observe that Angular always has the highest. I'm in support of shipping as much Javascript as possible to the user but Angular is high on something because what the hell is 5MB for bundle size??

Too much restrictions

Angular is opinionated about the way your application should be structured and the patterns you can employ when building your UI, with a heavy emphasis on an Object-oriented approach. Hold on a second but what if I just prefer to work with functions? And Angular is like maybe you can try other frameworks, we don't do that here. Enforcing a particular application structure will make things much more organized and standardized but this is only good if you don't have a good understanding of folder structure and popular development patterns.

The more you realize that there are different ways to structure your project you will not find it amazing to be forced into a particular application structure and you will feel like you're taped to a a chair because there are lots of ways you could express yourself but you're just stuck with one even if it's something you don't like or understand. Most developers would rather not deal with this situation at all so they'd be like I'm on to the other guys.

It's just too Overpowered

Something about Angular, it's just too much for most jobs around. Most of the time UIs we build tend to be very simple and straight to the point. Very rarely do you see people building something so overly complex. Angular on the other hand is a robust, fully-fledged, and out-of-the-box solution for building UIs. With a full-blown CLI, Built-In router, out-of-the-box state management solution, and Dependency Injection for your services.

All these are great features that could enable you to build the next big thing in Javascript. But if you just want to build something for your client or customers then 100 percent you'd agree with me your app doesn't need all those features or at least not as complicated as Angular make them. This is what happens when you're overqualified for the Job and nobody wants to hire you because they can't pay you.

Fierce competition

The Javascript UI frameworks/library ecosystem is always growing and there's no shortage of options. There are newer frameworks that offer more performance with much less stress and complication. you can now use Typescript on almost all Javascript UI frameworks so that Typescript advantage is no more. Other frameworks are making it easier than ever to build UI and they are growing at a rate that Angular cannot keep up with.

Signals were recently introduced to Angular but this will do little if anything to slow the decline of Angular. React, and Vue all have their implementation of Signals so that is just a ploy to make the framework appealing to existing users.

What's your take on the current state of Angular, do you think that Angular will not survive 2024 or do you think Angular is going to make a big comeback? Do you think that other frameworks out there are better than Angular? Or Angular is the undisputed T-Rex in the room? Let me know your thoughts on all of the above and what you think of the article via the comments section.

If you are looking at learning React then you can check out my YouTube channel where I have a course on React for Javascript developers with over 13 videos on getting started with building UIs with React, and another 7 part series on React Hooks, well what are you waiting for? Check it out.

Comments

[Leo]

Typescript is mandatory regardless of which "framework" you use. Saying typescript is only for 10x developers shows me you still have a lot to learn.

Angular wasn't designed for little CRUD applications. It is an enterprise frontend framework. You complain about bundle size but frontend libraries like React don't include any form, routing, nor API management like Angular does. Bet once you add in all the little libraries together a React build would be about the same. This is why React is a library and Angular is a framework. Angular is relatively complex because it is designed for complex projects.

I've seen far more large scale projects in React be an absolute mess while large scale Angular projects be a breeze to pick up. Angular is highly opinionated for a reason. It's not going anywhere.

[Nathan G Bornstein]

I agree @ljmerza. Especially when it seems like the de facto standard for React is to use create-react-app for a lot of React projects, which is absolutely bloated. Folks have been saying that Redux will be kicking the bucket soon for a long time due to its significant boilerplate, but its use is dependent on a multitude of factors. Just like Angular.

It's fun to write these kind of "scandalous" articles and I have to admit, I enjoy reading them 😅 It's like watching my favorite soap operas for all the drama, haha.

Every library/framework is going to have its benefits and drawbacks. That doesn't mean it will be obsolete any time soon. The popular ones exist for a reason and they have very different use-cases.

[Omar Karim]

Like I said you are uninformed at best spreading misinformation at worst.

[Leo]

So he admits he doesn't even believe his own blog posts and this is simply a troll post for clicks... All respect has been lost.

[Nathan G Bornstein]

@kalashin1 absolutely! That's the beauty of having an opinion on any one technology. Voicing said opinions opens a platform for free and conscientious discussion, much like what is happening here. That's a wonderful thing, even if people choose to disagree.

I think some of the criticisms you've laid out for Angular do have their merits, as they've been echoed by others before. Regardless of others sharing your opinion, you've opened a space for dialogue and I feel like that's the important aspect. And even if some of the points you've listed could be detached from actual practice, getting feedback from others is the best way to learn about stuff like that, imo.

Embrace the hate 😈

[Kinanee Samson]

Thanks man 👍👍

[imaheshnagar]

Worked both react and angular,
I like angular seperation of concern (html css and ts separate)
2 dependency injection
3 simple component life cycle
4 reuse of logic like pipe directive
5 httpclient and observable
6.easy routing
7 reactive form

Love you angular ❤️

[AppDev School]

Perfect!

[Nagarjuna B]

I too don't see any issues with Angular for enterprisy apps, except for - its reliance on zone.js and the default change detection mechanism. Diagnosing some not so straightforward issues, which are tied more with the framework (or how you used it), is a pain, something which shouldn't happen in first place.

In my opinion, you are better off using OnPush and removing zone.js altogether. But there are too many apps out there that are not doing this. Angular 18 makes that possible(or encourages too) now, but its too late.

I have always been skeptical of Google products, it looks like they are just some side projects by their devs, whose sole incentive is to showcase the work or get promoted, rather than delivering a viable product for the users.

I don't agree with the reasons(which are silly, actually) given in this article, but I would bet that Angular will be dead/barely-alive sooner. Some enterprisy apps might still continue using it to avoid migration costs, but any new apps(even if they are enterprisy) will most probably favor other lighter/simpler libs/frameworks.

[Kinanee Samson]

You missed the point of the post. This post was aimed at discussing the cons holding angular back as a framework

[Nagarjuna B]

Nope. Im aware what the post is about. I am just disagreeing with the reasons mentioned in the post and to a certain extent, with Leo's comment too.

[Kinanee Samson]

You don't have to agree with me for it to be valid. You know we all have very different reasons why we all stopped using a tool and in this instance I'm just documenting my experience.

[Kinanee Samson]

We'll see what 2024 has to say about that!

[Leo]

I expected more from someone who apparently had such a strong opinion against Angular.

[Michael Brown]

Typescript is mandatory regardless of which "framework" you

Not true.

You can use React with TypeScript or just plain JavaScript.

[AppDev School]

Thanks for making right information available.

[Gérôme Grignon]

Poor quality content:

• Typescript is over 32 millions downloads per week, versus 2 millions for Angular: Feel free not to like it but I hardly find a pro React project without Typescript around me.
• 5mb bundle size is only made possible due to poor choices (or not understanding lazy loading but quite unrelated to Angular)
• I see so many React devs being unhappy with a different application structure for each project they land on: that's where Angular shines.
• If you are overqualified by knowing a router and how to share a state in an application, that sounds like a great opportunity to find jobs out of your area.

The easier framework to build applications is the one you are comfortable with.

[Alain Boudard]

Ha ha ... je te vois :D
J'avoue que l'article m'a fait marrer, mais quel excellent moyen de ramener des views !

[dev procedure]

TypeScript was FORCED upon developers. Type Errors is nowhere near a big problem as Microsoft and others would have you believe.

2, I do NOT see "real-world" problem being solved by using TypeScript.

All I see are silly examples of a "function that adds or divides 2 numbers' to justify "type checking". e.g., Who writes a function just to do basic math????

Next, developers are testing (aka runtime) their code LINE-BY-LINE anyway, so "compile-time" checking isn't all that beneficial in saving a developer time coding.

In other words, TypeScript adds a layer of complexity that doesn't have that much benefit to JavaScript world.

NEWS FLASH:

1. Most data on the Client Side are STRINGS anyway.
2. NUMBERS and DATES are already validated in the client's browser anyway.
3. And YES, you are passing data for a KNOWN REASON. So you have a pretty good idea what is to be expected. And those to say you don't OR say you haven't worked with a large code base are justifying passing parameters that you have NO CLUE in what you are passing? If so, that is a sneaky form of "job security". LOL.

[Yutamago]

All I see are silly examples of a "function that adds or divides 2 numbers' to justify "type checking"

Examples are held simple for a reason. Try asking directed questions and someone can help you understand better.

developers are testing (aka runtime) their code LINE-BY-LINE anyway

80% of which developers do not even need to do, when they have type-safety.

Most data on the Client Side are STRINGS anyway

How many times did you have to debug code and it turned out it wasn't a string like you expected. :)
Probably a lot, according to your previous statement.
I just analyzed one of our enterprise projects and found 1,964 string properties and 1,561 non-string properties.
So you'd basically flip a coin every time you came across another property. And you couldn't even be sure if it stays a string or if it changes mid-runtime because someone else didn't know your intentions.

And YES, **you **are passing data for a KNOWN REASON

But does your team know your reason?
Does your successor after you quit the company know your reason? #sneakyJobSecurity
And do you still know your reason after the customer requests a change in 2 years?

TS also makes reviewing your code a lot easier, if I can trust that the TS transpiler already checked it. I can now focus on what your code is actually doing and not have to reverse engineer your value types.

[dev procedure]

1,964 string properties and 1,561 non-string properties.

Properties are one thing.
Actual Variables are another.

But does your team know your reason?

They better know as you should have good variable naming to begin with.

Examples are held simple for a reason. Try asking directed questions and someone can help you understand better.

No one is stopping you, or other TypeScript supporters out there from putting out a TYPICAL REAL-WORLD example.

[Yutamago]

you should have good variable naming to begin with

I don't know about you, but I can count people who name their variables well on one hand.

No one is stopping you, or other TypeScript supporters out there from putting out a TYPICAL REAL-WORLD example.

Alright, I looked up some bite-sized open source examples, because my company is literally stopping me from putting out company code. :)

Example 1:

function toKebab(str: string): string {
    return str
        .replaceAll(' ', '-')
        .replaceAll(
            /[A-Z]+(?![a-z])|[A-Z]/g,
            ($, ofs) => (ofs ? '-' : '') + $.toLowerCase(),
        );
}

You immediately know that this function CANNOT handle null as a parameter, because it only allows string. Not only that, your IDE will show you an error and highlight the place where you tried to call this function with null. And because the result CANNOT be null, you also get a hint if you're checking it for null.
Source: taiga-family/taiga-ui

Example 2:

import type {Locator} from '@playwright/test';

export async function tuiHideElement(element: Locator): Promise<void> {
    return element.evaluate((el) => {
        el.style.opacity = '0';
    });
}

Writing this function took the author probably just a minute. They might not even have had to open the playwright docs. The IDE already knows which functions are available in element, because it is an object of type Locator.
Imagine playwright updated the Locator model and evaluate was now renamed to modify. Now your code is broken and you don't even know until you run the code.
Source: taiga-family/taiga-ui

[dev procedure]

EXAMPLE 1
function toKebab(str: string): string {

    // BOILER PLATE null and empty string checking
    if (str == "" || str == null || str == undefined) {
       return "ERROR!!!! str is empty string or null, etc";
    }


    return str
        .replaceAll(' ', '-')
        .replaceAll(
            /[A-Z]+(?![a-z])|[A-Z]/g,
            ($, ofs) => (ofs ? '-' : '') + $.toLowerCase(),
        );
}

You immediately know that this function CANNOT handle null as a parameter, because it only allows string.

Why not just add some Boiler plate, IF-THEN null or empty string checking? That's worked just fine long before TypeScript existed. And if I get that ERROR string message, I know exactly what happened and where it happened.

Plus, when I read the JS Boilerplate code, it so much more clear.
The TypeScript has to state "string" TWICE in Example 1 (and look where it uses string twice...somewhat confusing to read.)

[dev procedure]

Imagine playwright updated the Locator model and evaluate was now renamed to modify. Now your code is broken and you don't even know until you run the code.

return element.evaluate((el) => {
        el.style.opacity = '0';
    });

If you are renaming "evaluate" to "modify", why would you NOT run the code to test those changes anyway?

[Abhinay]

Your article accurate for Tic tac toe kind of application.
Angular is for enterprises application and react is nowhere closer to Angular in Code migration, Type safety , scalable project structure and many more

[Kinanee Samson]

You maybe right but doesn't change the fact that React is the most adopted UI framework for a reason.

[Abhinay]

React is library not a framework

[Irwansyah]

Something called framework if it has Hollywood Principle in it and React has it so React is a framework.

[Fyodor]

trust me telling them that they have to go learn how to use a subset of a language they barely understand will not yield any positive results

As well as their job search in this case 😅😉

I know folks that just don’t digest JSX, or fancy new reactivity primitives in Vue 3, or weird templating of Svelte. Angular is absolutely OK for mid-level developers, quite simple to grasp these days. It has well-rounded and SOLID mental model behind the scenes, and it has great ecosystem and community (I really like these people, hardly any framework has such a small amount of fools among proponents). Also it’s mostly used for enterprise development which is HUGE part of the job market. So it’s not going anywhere, as well as… COBOL, for instance.

I prefer other tools personally. But I know that Angular in 2024 is performant, safe, scalable, and approachable choice. And inevitable evil for legacy enterprise code bases.

[Kinanee Samson]

How many Jobs are hiring Angular Developers? Can't remember the last time Angular was a requirement for a Job I've applied for in the past three years. Well it has to be those hardcore Angular fans that don't want to give up t their pride.

Angular will still be performant and it is still going to be used albeit just a little less.

[Austin Akers]

I also think that's very subjective. It depends where you live. In Dallas,TX there are many Angular job postings Ive seen and many enterprises located there use Angular. In Seattle, WA there are a multitude of React jobs here. Look at your local job market and learn what's relevant in your surrounding area.🙂

[Kinanee Samson]

Exactly over here Angular is rarely used. Even when I worked for a firm that used Angular, the CTO kept encouraging us to switch most of the User Interface for their products from Angular to React.

[akili]

I have only used Angular in the companies I've worked for for the past 5 years. I think if people could make scalable applications in react correctly there wouldn't be a need to hire people to fix other people's work.

[Maximilian Lenhardt]

Since all JavaScript Code is valid Typescript Code, there is literally no mandatory overhead with regards to Typescript. I honestly believe Angular will always have a place, especially because of the complicated stuff it can do, such as DI. If you end up building a complex app with another framework, the stuff gets either as complex or is not as good as angular is out of the box. I admit, the learning curve is steep, but it is so much more rewarding.

To be honest, I feel like javascript developers tend to go down the easiest way opposed to other areas of development. Topics like DI are not that hard to grasp in general and are very commonplace in the software world (Spring in java for example).
And as always, you don't have to learn it all at once. That's the good thing about opionated frameworks, they take over a lot of mental load.
And they help you onboard developers which have experience in the area much faster opposed to say React, where every project has its own custom structure.

[Kinanee Samson]

Nice take man, what a strong comeback by Angular.

[MP]

I like your enthusiasm, but the energy is misguided. (Unless the goal is just to get a controversial piece trending for clicks and ad revenue, then I'm sure my comment will play into that.)

I'll address as much as I can, but it's easy to see that most of your complaints are clearly of wrong fit - You don't take a semi truck to go grocery shopping and complain about gas mileage and parking space when a hatchback is clearly the correct choice.

Something about Angular, it's just too much for most jobs around. Most of the time UIs we build tend to be very simple and straight to the point.

You're right, with the sample set of "all web jobs", Angular is surely too much. Angular is a robust, feature-rich, highly-opinionated application framework for building powerful, scalable applications. I think this is an important distinction to be made; Angular isn't for UIs, (which I take to mean light, interactive web content.) If you're looking for "very simple and straight to the point", Angular is not a fit for your project... that doesn't mean it's dying in 2024.

There are newer frameworks that offer more performance with much less stress and complication. ... Other frameworks are making it easier than ever to build UI and they are growing at a rate that Angular cannot keep up with.

1. Newer doesn't always mean better; oftentimes it can be seen the opposite.
2. Even if that were the case, angular gets major releases twice a year that supply thoroughly tested new features, improvements, and optimizations.
3. Ease is subjective - Angular isn't for one-day websites, it's for lasting, growing applications.
4. Angular only competes with with Vue and React in blog articles. It doesn't have to 'keep up' with anything except the expectations and needs of architects and developers needing a robust, scalable application platform.

when you compare the Bundle Size for Angular to the Bundle Size for other frameworks you'll observe that Angular always has the highest

Strong assertion of fact that I'm sure you have sources for...
Once again a question of fit - build an identically-featured, medium size application in all three and I'd bet the compiled size difference is negligible. (Not a factual assertion but a well-educated opinion.)

Angular do not like beginners and newbies and it doesn't deal any kindly with them. ... However, all this is not sold to the developer in a way that is simple to digest,...

You seem to want all of these free and open-source frameworks and libraries to "sell" you, and I'm not sure why. Do your own research and find the best fit for your need. Angular isn't a quick afternoon read, and that's entirely acceptable for the developers that it's made to help.

This is what happens when you're overqualified for the Job and nobody wants to hire you because they can't pay you.

I love when I become overqualified, because then I find a new job and continue advancing my skills and income further! I have recruiters constantly trying to poach me for higher salaries than I make now. Funny enough, besides extensive development experience, Angular is their #1 quoted reason they call me. Angular is fully qualified for its job - which isn't in the one-day-website world.

You see Angular was designed to be used on complex web applications and as such it comes fully fledged with everything you need to build and deploy a modern web app.

This is the best line in your piece... it's is exactly the point. Angular answers its need quite well. If Angular isn't for your need, that's okay.

[Mark Litchfield]

Excellently written and considered response. I'm thinking the author is poking the bear to drive views to his "I'll teach you how to make websites" YouTube channel that certainly isn't cluttered with the same short-sighted and poorly informed opinions. /s

[Marco]

Calling type safety as an "overhead" reveals the intention of that artcicle: none.

[Kinanee Samson]

Because it really is. If you're not experienced enough to use Typescript then what use is it adding Typescript? It just adds another layer of unnecessary complexity.

[Marco]

This is not an argument. When you can't programm type safty and don't understand the underlying concepts and advantages you are not a programmer. Instead you are a script kiddy. Type safty is a widely used concept to catch errors before you ship software while you're developing. Thats not overhead, thats mandatory.

Thats my cup of tea to this topic.

Your post is just polemic to gain some social range nothing else. In other terms:
Type safty will save your ass when you don't understand your problems with your code.

[Kinanee Samson]

You are making the assumptions that all beginners should know Typescript immediately after they learn Javascript and I'm telling that it rarely happens that way.

I had to learn Typescript specifically because of Angular! And that was because I had the time to do so! But I started using React/Vue without worrying about Typescript and I only added Typescript to React when I was already familiar with Vanilla React and added Typescript when I understood the benefits and importance of Type safety and how Typescript works.

[Marco]

That may be but your article doesn't properly reflect that. But even in that case, I would recommend/encourage every new js programmer to learn typescript and the attached concepts.

IMHO using vanilla js is a red flag when it comes to serious programming.

Your article would be correct when you would say something like this:
"If you don't (want to) understand typescript just put your hands off from angular"

[chris-richter]

If someone isn't experienced enough to work with typescript, they're probably not qualified for the task.

What you're describing is someone who only does inline styles because they think css is too confusing. This year isn't that year.

[Marco]

That year won’t be even in the next 5 years

[G1itcher]

Typescript at this point is mandatory learning for all front end web developers. Types make enterprise JavaScript development tolerable.

There are complicated aspects of Typescript (generics) that can be hard to grasp, but the majority of Typescript value is easy to access and use.

This reads like classic developer "I don't want to learn this so I'm going to try and justify that with specious reasoning". That isn't an insult to you; it's something all developers are guilty of at some point. I've done it, the best developers I've met have done it, and you're doing it now. That's fine, but the only way past it, especially if it's a very popular library that you will undoubtedly have to use in your career, is to sit down, learn it, and use it. Maybe without Angular.

More often than not you will understand why a library is so popular.

[Lợi Trần]

Angular can be a great choice for projects that are expected to scale up. Its opinionated structure and built-in features like dependency injection, comprehensive documentation, and strong architecture can help maintain a scalable and maintainable codebase as your project grows. However, ensure your team has the expertise to leverage Angular's capabilities effectively for scalability.

I believe that tailoring your content directly to your course can attract more people to watch your videos and potentially generate income from it. However, this approach seems unethical in my opinion.

[Kinanee Samson]

The goal here is not to get people to watch my content but to share my opinions and thoughts with you guys.

From what I've seen Angular seems to have some strong hearted developers behind it.

[Volodymyr Yepishev]

Angular on the other hand is a robust, fully-fledged, and out-of-the-box solution for building UIs. With a full-blown CLI, Built-In router, out-of-the-box state management solution, and Dependency Injection for your services.

And how many other frameworks offer that much out of the box?
There's also an automatic upgrade tool :)

[Johannes Phetoane]

When I first started in the field of software development, I started learning Angular. As someone without a coding background, the initial challenge was tough, but it was a enjoyable moment for me. Along the way, I took a pause to explore React, and upon careful consideration, I chose to delve into React because I easily and quickly grasped its fundamentals. Fast forward 11 months, and I've been working with React.

I am gearing up for a new project in the coming year, and this time, I'll be working with Angular, the latest version. I am hopeful that this time my experience will be different from my initial encounter with it, and I am eager to see how my skills have evolved. While I acknowledge that it may not be as beginner-friendly as React, I am ready for the challenge. I agree, Angular is not begginner friendly especially for someone with no coding background

[Kinanee Samson]

You will come back to React.

[Rense Bakker]

You're going to hate it xD