For 2023, Team Angular has made a lot of important changes which were asked for by the community, and that’s insanely awesome. But it wasn’t always like this.
In this story, I’d like to tell you about my 4 years experience of using Angular. First of all, I think Angular should not be your first technology to develop applications.
I want to highlight the problems which Angular creates and how they affect developers and team building. I will also try to give solutions to the problems I have identified if you already use Angular or want to use it.
Unfortunately, some teams or even companies are slow to upgrade for one reason or another, and you may find applications on Angular 8, 9 or 12. Therefore some of the issues outlined here can still be relevant.
If you are a junior developer, this article may also be useful for you and will help you with choosing your first development stack.
At the one moment, i may seem criticizing declarative approaches implemented by the Angular team — not at all. I don’t question that over time any
low-levelcode becomeshigh-levelcode via abstraction and new features, making our work easier. Each new UI library tries to solve the problems of current libraries and offers improvements, providing growth and quality tools from year to year
The convenience trap
As we know, Angular is a UI framework, not a library. It positions itself as a self-contained solution for front-end application development. You don’t have a “zoo of technology” from app to app, everything is uniform and monotonous, but there is a downside to this. It’s easy to get used to the conveniences that Angular provides, and it gets more difficult to give them up later on.
ReactiveForms
At one time, the approach proposed by the Angular team, the form and its control are separated into an HTML-template and a JS-controller, really proved to be handy for form development.
The problem is different, we are so used to relying on validation from ReactiveForms that we forget that HTML natively provides us with all the attributes we need to validate input fields — min, max, pattern, required, readonly, etc.
What is this problem? — Once you get beyond Angular, it turns out that ReactiveForms doesn’t exist as a standalone library. You’ll have to re-learn how to develop forms — events (submit,change) and input field attributes.
Building an application
You don’t need to customize the application build, just run the “build” or “serve” commands to get started. You do not see the webpack.config.js or vite.config.js configuration files of the builder.
Can you say:
How is your application built?
Which file is the entry point?
Which tool builds your application?
How do your
SCSS filesbecomeCSS?How does
HRMwork?
If you work only with Angular, you missed the growth stage of gaining the skill to build an application. Webpack, Gulp, Rollup, Vite, Esbuild — you just don’t know it. If you’re asked to create a simple web page in HTML and SCSS without Angular — probably you can’t.
HTTP client
This is a convenient wrapper over XHR using the Observable pattern, given the recent XHR2 feature for SSR. It allows us to make queries with multiple parameters, track the progress of the query, and be able to convert the response to the desired data type with just a single parameter.
But as an angular developer, would you be able to say:
When was the last time you used native methods to handle HTTP —
fetchorXHR?Can you handle requests and errors globally without using an
Interceptor?Can you name ways to undo an HTTP-request without using
switchMap?Do you know of
axiosornode-fetchlibraries?
Despite the convenience, we should know how to make queries without Angular. It surprises me when even Senior developers don’t know how to make a request before bootstrap application or about the existence of RxJS.Ajax
We must have an understanding of the essence of the request and response to be able to:
Handle errors
Parse the response
Track the progress of the request
Work with FormData
Top comments (35)
I strongly disagree.
Angular was my first framework with nearly no HTML/Javascript knowledge.
It was the perfect fit for what we all need: do the job.
Fundamentals are important but if your job is about using Angular to create applications, it won't make you a dumb developer by focusing on what you need then to learn about the internals/alternatives.
Angular was my first technology too, and I forcibly learned it. And the more I delved into learning it, the more I understood "why it was done" and "what it affects".
But there were my colleagues, "why learn something if I am already working and they give me money?"
I am opposed to this scheme
It doesn't have to be that way.
I'm not afraid to admit my mistakes. The headline Angular make you a dump developer was changed to The convenience trap.
If this offended anyone, please forgive me. I am always ready for dialog
The only thing I hate about angular is how companies get stuck on certain versions and never upgrade to the latest one, some especially get fixed on angularjs for some reason, haven't used to know why its hard to upgrade or what are the benefits of sticking to it...
That happens with literally any technology, though. Companies can be quick to adopt and slow to upgrade. That's not an Angular thing, that's just a sad reality of working at big companies.
What sticks them to a version is fear.
Older developers from Java 6 times with JSP based pages or even desktop applications became the managers of today. They used to have lots of trouble upgrading back then, so it doesn't get a priority today.
I worked for a famous American multinational company that people would expect to be up to date technologically (it's mainly known for computers by their brand) for a while and god it was a mess (at least in the projects I worked at). Except for a C# application that was fairly up to date, everything else was outdated (one of the projects, I kid you not, was Oracle Forms) and the manager would even refuse me a bugfix just because it was me to spot it instead of the user. Even the tooling was outdated. They were still using TFS.
Dude same with react. At least angular has code migration.
Not now a days where compliance policies are mandating teams to migrate projects to LTS. Auditors will ensure those happens or guess what happens: the project will be blocked until migration happens.
There are two reasons for the shift from AngularJS over to React. First, and the one that triggered interest, is speed. React was much faster and more memory efficient than AngularJS.
The second reason is more expansive and is what carried React into the stratosphere. Basically, the conception of React is more in-line with where the modern web is going.
AngularJS was born from the first era of web application development. To wit, it was an era focused on the DOM. Coders wrote HTML and CSS then attached functionality to it with JavaScript. JQuery is nothing more than a DOM manipulation library, and AngularJS’s raison d’etre was literally to be what HTML would have been like if it had been created with applications in mind. The DOM was paramount.
React rejects the DOM as a thing. Instead, all that exists is the JavaScript application — the state of the application that outputs the DOM. The DOM is a result, not a thing. That is a massive paradigm shift. Suddenly, web pages are genuine applications. This shift is the reason why “web developers” earn $60k per year while “front-end engineers” earn $140k.
React’s architectural concept was also more elegant and easier to understand. AngularJS relied on dirty-checking, where every component in the application was checked for changes ten times. It was a huge kluge (rhyming unintentional) and was slow as molasses with large DOMs.
React instead maintains a DOM state that is just a big JavaScript object. When the user does something, React creates a new DOM object and compares it to the old one. Any differences are then rendered to the UI. This is very easy to understand and very elegant.
This new philosophy now dominates and AngularJS has been completely obviated. Vue, Ember, Angular 2+, Bobril, and Aurelia all rely on some sort of virtual DOM or another, even though their change detection schemes are different. This new era has pushed frameworks to speeds that were unimaginable just two years ago, and much of this transition is thanks to React.
Angular does not use the virtual dom. The Angular team created a much more memory efficient incremental dom that beats out the virtual dom in every aspect. Angular applications are now much faster and more performance on the mobile web because of it.
Thank you for sharing that information about Angular's approach to DOM manipulation. It's interesting to see how different frameworks adopt various strategies to optimize performance. The use of an incremental DOM in Angular, as you mentioned, is a notable example of the innovation happening in the realm of front-end development.
If you have any more insights or details about Angular's incremental DOM or any other aspects you'd like to discuss, feel free to share. Additionally, if you find our conversation engaging, I'd appreciate a follow back. Let's keep the conversation going!
I get what you are trying to say and totally agree with it, but the phrase "React rejects the DOM as a thing" just feels wrong given React being built completely around the vdom model which is nothing more than a strategy for updating the DOM. I think what you're trying to say is that React has put such a blackbox around DOM manipulation that React devs generally don't have to even think about the DOM.
This is why I have abandoned these frameworks, especially React, and have moved on to Svelte. I feel Svelte is what every framework should have been while embracing web standards and understanding how to work with native DOM/Events
"Switched to Svelte for web development, loving its focus on web standards and native DOM/Events. Preferences vary, and it's great to explore different frameworks. If you're into Svelte too, consider joining online communities for insights and support. Tech choices are subjective; having options is key. 😊 Follow back?"
Well I do actually prefer React, or at least how declarative it is to build apps in, but I agree it is also good to understand how native browser APIs work. React does let you work with synthetic events for components that are syntactically the same as the browsers DOM events, so that's something.
You're absolutely correct, and I appreciate your clarification. React doesn't reject the DOM; instead, it abstracts and streamlines DOM manipulation through the Virtual DOM (vDOM) concept. React developers can work with a virtual representation of the DOM, allowing for a more declarative and component-based approach without directly dealing with the complexities of DOM manipulation.
Your point about React creating a blackbox around DOM manipulation, freeing developers from having to constantly think about the DOM intricacies, is spot on.
If you have any more questions or if there's anything else you'd like to discuss, feel free to let me know! Additionally, if you find the conversation engaging, I'd appreciate a follow back.
Much of this sounds like either you haven't kept up with angular development or just frustrated with a specific project, or set of projects, you've had to work on at a specific company. I can tell you I worked at a place several years ago that had a bunch of AngularJS projects and they had a stupid 6 year plan to literally upgrade to Angular2 v1.0. That's all to say I understand being frustrated with smooth brain decisions some companies make but you can't really blame a framework for that.
Many of these issues have either been addressed or will be addressed. Zonejs is a good example. I don't think anyone really likes zonejs and the angular team knows it. Which is why they've been updating to signals which are much more performant.
In your medium article you also talked about angular material not being customizable which just isn't true. Like literally any technology you have to know how to use it in order to know how to customize it. I'll give you an example:
These are Angular material form fields. There are no outside tags just the angular material form field, label, and input. If you know what you're doing you can do it. That applies to everything.
Also, you don't HAVE to use HttpClient if you don't want to. Want to use regular XHR, you can do that. Want to use axios, you can also do that. You've kind of missed the point of HttpClient and that's to make your life easier. Since you don't actually point out any real issues with HttpClient other than "but do you know other ways to make HTTP requests?" I'm not even sure why it's in here.
In regards to angular making you a dumb developer, no. Just no. If you're a beginner then you don't exactly need to know all the internal workings of Angular because you're a beginner. That's what it means to be a beginner. If you're a beginner with any technology you're probably going to follow a guide and not really know what most of it actually means. That goes for anything, that's just being a beginner and there's nothing wrong with that. If you want to know how things work at a base level with Angular the information is right in their docs. If you want to know how to do more customizations with how your app is built and how things work under the hood, it's not some big secret. You just have to read the docs.
Is Angular right for every project, no! The same is true of literally every framework/library. Sometimes it doesn't fit your needs well. If you're a company looking to work with angular do you need experienced people to work on your project? Yes! Of course, you do because you don't want someone doing a half-assed job. That, again, goes with literally any technology a company is looking to implement. There are plenty of legitimate criticisms of the Angular framework, I'm just struggling to find any here.
When a company has its own product, it's unlikely to design it in Material Design. Your designer can come up with whatever elements they want
My point is that people who use only angular and who are overused to angular don't know how to work with other technologies to create requests.
It will be hard to understand and identify this because at interviews you will be asked questions about JS, TS, and something from Angular documentation. In a company that doesn't have a developer growth map, you get grades for loyalty, we get a Senior frontend developer who only knows how to work with Angular and nothing else. Because the Angular thinks for you, not you. I specifically emphasized the point that Angular should not be the first technology as a stack choice.
Yes, I don't exclude that I saw a lot of bad practices in companies that affected the appearance of this article.
We will never know the ratio of good to bad developers, so I think it's important to talk about it. And maybe I can affect that ratio
Most of the arguments related to Angular are about developer-friendliness. But, sorry, you're forgetting about the product that the company is paying you money for. The end user doesn't care how many people develop the application and on what technology, the user cares about consistent performance and responsiveness.
Angular is a technology and it's clearly catching up with the rest of the technology and things like Relayout, Reflow and Repaint. Angular is convenient, you have to understand the price for convenience
So basically, what you are telling me is that Angular is too awesome for its own good?
I always hated working with frontend when I had to deal with native html, css and JS. Angular was the first time I actually enjoyed developing for the frontend (except for maybe Flutter, but I don't see myself in that market anymore). Before that, I was mostly a backend developer only. Now I crave for doing more frontend whenever I can. It inspired me into doing open source work in my free time when I don't get enough at work.
I agree with you though that a senior developer should be able to diagnose problems that happen outside of coding. Like building problems for instance. To understand how Angular does that so if it breaks production at some point without any relevant code change, they should know what the error being outputted means.
I do not agree though that a senior Angular developer should know how to do things outside Angular. It's nice to know, sure, but this dev chose Angular as their frontend stack. Chances are, they are going to look only for Angular jobs if they want to move too.
I would also agree with another point. Just like any other technology, it's pretty common to have companies getting stuck at a version and never upgrade. At my company we are starting to change this. We have a code base with more than 300 repos between frontend and backend, so it's going to be a difficult task that all teams have to be onboard, but we devised an upgrade plan that would set teams to upgrade everything under their care about once a year. Doesn't have to be up to latest version immediately as it can be overwhelming for bigger projects. Just upgrade faster than the technology in question delivers versions. Slowly and steady and eventually, in a few years, it will get everything to the latest, by which time, it will get easier and easier to upgrade
I have to say that angular was the best way to get into web development I could wish. Without it I'd quickly get lost into an ocean of required tools that would make things much harder to learn. With angular I could focus on HTML, JavaScript and CSS. Later on, when I needed I could spend time with learning the tooling, what was really happening begging the curtains etc. I consider developing, configuring the development environment and the building process pipeline almost disconnected problem spaces.
The title is strong but the content is poor. There is just no compelling argument in it than saying
you won't learn that if you learn this.I agree that a person should start with basics, but that doesn't change the fact that frameworks like Angular help you stay modular, ensure re-usability, and encourage best practices. All while saving you lots of time on structure.
If you were to truly align to what you're preaching here, you should never use a library or a framework. Maybe not even an IDE, just use notepad. Or maybe just code in assembly - that might be a great way to learn the internals.
This article is very misleading. Angular was my first framework, and I can tell you by fact that, projects based on libraries are total chaos, without a defined structure.
In the contrary, Angular teaches the developer to keep your project properly organized and scoped. This is the first thing developers really need to reach to keep a consistent project.
Not sure about your experience, but Angular projects are very favored on large applications where structure and organization is needed. You need Maria Kondo in your codebase.
I understand you well. The primary issue is that many grasp high-level technology without delving into its inner workings. While it may not seem significant, having a deep understanding offers advantages like creating stack extensions, deciphering error stack traces swiftly, and resolving issues effectively.
Developers often learn on the go, troubleshooting when problems arise. While understanding the underlying technologies is beneficial, app-level developers can work at various abstraction levels, learning what's necessary when needed.
I completely agree with your insights on Angular. The cautionary perspective you’ve outlined is not only relevant to Angular but also to libraries like React. Much like Angular, React can lead to an over-reliance on its ecosystem, potentially narrowing a developer's expertise. This scenario is reminiscent of the history with libraries like jQuery. While jQuery simplified DOM manipulation and improved productivity, it also led to a generation of developers who missed out on understanding core JavaScript and browser behaviors. It's vital for developers to balance using these libraries while ensuring a solid grasp of the underlying web technologies.
If what you say is true, another way to see it is that, instead of focusing on low-level stuff and becoming a generic technician, you may have the mental bandwidth to become an expert of the problems that your ideal clients are facing. Sounds like a good tradeoff to me.
To abstract your argument, most libraries that abstract away the mundane details or hide complexity of a technology like DOM or SQL don’t make you a deeply experienced developer but you may still be a highly productive one none the less. Nobody wants to code at a low level and it doesn’t pay.
I do see your point that developers may have shallow experience but that’s not Angulars fault. The fix is to learn Angular, Svelte, htmx, React and others to see how they solve the same problem. Go broad. I would take a very quick pass looking at examples of raw HTML and non-library JavaScript to browsers see why you need libraries.
I also have to disagree. I have developed at work in Vue, React, and Angular and my number one choice is angular especially for complex and robust applications. Adding NGRX also makes it even better giving teams more control over the application. If you built your app from scratch properly, it is also very easy to maintain. I 💯 recommend angular!!!
Angular maintenance sucks
Some comments may only be visible to logged-in visitors. Sign in to view all comments.