Exploring the Hesitation: Why Developers Opt Out of Using Angular

Exploring the Hesitation: Why Developers Opt Out of Using Angular

How the lack of community support and third-party tooling is perceived by developers

Ā·

8 min read

There's a TikTok trend that uses an intro video saying "Say the weird thing. People are desperate for realness".

It kind of feels bad in 2024 to be an Angular developer.

There, I said it.

When exploring web development technologies, the notable scarcity of community support and third-party libraries for Angular stands out, particularly when compared to the vibrant ecosystems supporting React, Next.js, Vue, or even less mainstream solutions like Svelte.

When working with newer, yet established, platforms and libraries, it's not uncommon to see Angular completely left out of the conversation. For example

These are just a few from a very long list. None of these mention Angular directly, including installation instructions or guidance. While this doesn't make these tools entirely inaccessible, it certainly deviates from common practice. Finding code examples and documentation that fit your needs can often feel like you're fighting an uphill battle.

This disconnect can create moments of doubt for those investing their time into Angular, raising questions about whether their efforts are being directed towards the most valuable sought after skills in the tech landscape.

Over 20 years, I've watched languages, frameworks, and design patterns emerge and fade away. I know that trends will come and go, but I can also recognize Angular's declining trend compared to its more widely adopted competitors in the job market. When we talk about innovators, is Angular a leader or a follower in the web development space? Is Angular influencing how the next generation of web applications will be built or does that crown go to another ecosystem?

Where does Angular excel?

Angular's architecture tells us a lot about its intentions and the scenarios where it excels; it's designed for large-scale applications, using features like dependency injection, modules, decorators, and a more complex reactive programming paradigm compared to its counterparts. Its "batteries included" philosophy ensures that large teams have a go-to solution for most web development needs and encourages standardization on a very specific set of core libraries and patterns. Angular, like many other web frameworks, offers its own opinionated approach to solving common development tasks. As part of it's design, staying within the framework is encouraged.

The Trade-offs of it's design

The double edged sword of standardization: Diminished third-party support

Angular is not just a framework; it's a highly opinionated one. Angular's complex architecture and out of the box solution for most web development situations is excellent for standardization and ensuring that all parts of the web application work seamlessly together.

āœ… That's great for big teams working on large applications with complex requirements

However, its strict rules, design, and self-sufficiency can inhibit its use of the wider front-end ecosystem. Additionally, library authors must provide an importable Angular module in their packages. These factors make Angular an excellent choice for large teams handling large applications, where stability, modularity, predictability, and interoperability are essential.

The "batteries included" approach of Angular, combined with the requirement for library authors to adapt their packages for Angular by including additional framework-specific details, makes it harder for Angular to take advantage of third-party libraries compared to React and Vue.

The truth is that there are simply fewer third-party libraries and integrations available relative to alternative front-end solutions. Of course, some great packages exist, such as Angular Material, although to be honest I really don't like my web apps looking like a Google application šŸ¤·

Many large companies that choose Angular don't mind, and actually prefer, creating their own design systems, component libraries, and depending on code developed internally. There are, of course, exceptions to the rule. In small to medium-sized companies, flexibility and speed to market are often extremely important factors in choosing a tech stack. Angular tends to fall short in these scenarios.

Steeper Learning Curve

Angular demands more time and effort to to master and achieve similar outcomes than other front-end solutions. Some basic things that need to be understood about Angular to be somewhat proficient include

  • Dependency injection and dependency tokens

  • Various decorators such as @ViewChild, @ContentChild, @HostListener, and a handful of others.

  • Angular modules

  • Template and data binding syntax

  • Content projection (transclusion) with templates (TemplateRef) and built-in directive such as ng-content.

  • More effort involved to get Angular's change detection to play nicely with third party libraries

  • Understanding what ngZones are and when you need to create your own

  • A good grasp of RxJS

RxJS Observables

RxJS is a library for reactive programming using observables, providing powerful operators for handling asynchronous data streams and complex event handling in applications.

Angular heavily leverages reactive programming through RxJS observables as a core concept in it's design. Examples include HTTP requests using the HttpClient module, form controls for handling user input reactively, and route management to observe route changes and manage state transitions efficiently.

Being a solid Angular developer not only comes with the territory of understanding how the Angular framework works, but also understanding how to construct complex observables that react and behave in various ways when events happen. RxJS is so closely integrated with Angular that they are almost synonymous. If you choose to use Angular, you're also choosing to use the RxJS reactive paradigm. Of course, RxJS can be used outside of Angular, but how many developers are actually doing that?

Imagine a scenario where you need to fetch user details, filter those based on a condition, retry the request if it fails, catch any errors gracefully, and then combine this with another observable representing, say, the user's settings, which also undergoes a similar process. This could involve using operators like filter, retry, catchError, combineLatest, and tap for side effects, orchestrating a sophisticated data flow that handles errors, retries, and combines multiple data sources with conditional logic and side effects, all within a reactive framework.

RxJS is immensely powerful, but comes with the tradeoff of complexity. This complexity can take years to properly understand and is a barrier to entry.

Industry Momentum Favors React

In the rapidly evolving landscape of web development, startups stand on the cutting edge, pioneering the adoption of technologies that not only promise efficiency and scalability but also boast of a robust community and future-proof architecture. Among the myriad of choices available today, a discernible shift towards React over Angular has taken place within the innovative startup and SME ecosystem.

React's popularity has resulted in a large pool of developers skilled in its use, making it easier for small to medium-sized companies to hire talented individuals who can quickly contribute. Angular, by contrast, presents a steeper learning curve, which narrows the field of readily available expertise. Combined with the exceptional community support and development agility offered by other front-end solutions, Angular has predominantly positioned itself as the go-to framework for larger enterprises rather than startups. This distinction underscores a fundamental shift in the technological preferences of nimble, growth-focused companies (and individuals) versus those of established, larger organizations seeking comprehensive, enterprise-level toolsets.

Conclusion

Even though other front end solutions have the upper hand in taking advantage of third party libraries and are more embraced by the web development community, I still think that investing time in learning Angular is a smart career choice.

Personally, for side projects I find writing React to be far more enjoyable, but consider these points when making the decision professionally:

  • Since there are more job opportunities for React than Angular, it means that more developers, both former Angular developers and new ones, will choose to spend their time in the React ecosystem.

  • Because there are more React devs than Angular devs, really good Angular devs will be harder to find than really good React devs.

  • Large enterprise companies have heavily invested in Angular and just like Java and C#, heavy investments tend to stick around.

  • Angular is a solid framework and is great for enterprise.

Choosing to invest in Angular may mean that you're setting yourself up to work in and progress in an enterprise sized company. There's nothing wrong with that if those are your career goals, but understand that change happens very slowly in large companies and misaligning your expectations with what startups are doing and what trends are happening in the JavaScript ecosystem is not reflective of an enterprise environment in most cases.

I'm a big advocate for picking the right tool for the job. For most startups and small to medium-sized enterprises, Angular just doesn't stand out as the best option. Given this situation, the open source community, new platforms, and modern tools naturally lean towards the solution that works best for smaller ventures - or at least, it often appears that way.

Entrepreneurship is challenging enough without adding hurdles with your choice of technology. However, if you and your team know Angular well, are aware of its trade-offs, and still prefer it, that's a solid reason to stick with it. Ultimately, choose what you want to use. Your customers won't mind what technology you use to build it.

What's Next?

I'm curious whether Angular will continue to be the prefered framework for enterprise scale applications in the future or if larger companies will start adopting React due to ease of hiring. Angular will undoubtedly be around for years to come, but I'm interested in seeing how the landscape shapes now that, in recent years, we've seen a larger surge in React adoption than ever before. As an engineer, I absolutely think it's important to divest your time investments and understand both solutions at a reasonably in-depth level to maintain marketability.

Ā