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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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
You are hundred percent correct. Besides, react developer who are beginners might not find out about dependency injection, routing, MVC, and other patterns simply because they are starting out with a presentation library. The whole premise is flawed with regards to the dumb developer. It's like programming in notepad instead of using an IDE just for the sake of learning implementation details that add very little business value a... Absolutely crazy
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.
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 behind 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.
Very elegantly expressed!!! Author, let me know how you are doing with register s in assembly when you have a chance. And give me an ETA of when you think you are done with that feature I asked
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.
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.
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.
There is just to much to learn. One must be selective.
The layers of abstraction like jQuery came into play because what was available before then did not cut it. So decide, be effective and efficient and call your self dumb. Or a slow and frustrated genius...
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!!!
I always heard angular was harder to learn than the other libraries out there like Vue and react, that only means using it and learning it will make you a better developer
Angular adds (sometimes unneeded) complexity, but it's also way more stable and testable out of the box then Vue or React, in my opinion. I agree if you don't have Angular 17 or higher, you will miss out on a lot, but for greenfield projects, starting with an Angular 18 scaffold is still a rock-solid choice.
100%
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.
It's like programming in notepad and bypassing the IDE for all the wrong reasons
if u really wanna call urself a developer u should know react and vue as well, combined with a myriad of technologies, until u can build anything and everything
This article doesn’t make any sense and don’t have any facts to back it up. This should be taken down
I agree
Cost of evolution, maybe.
Angular maintenance sucks
This is true to any kind of technology. One might just be a consumer of the framework or one might dive deeper to understand how everything is done
If you spearfish , you know you only go down when it is absolutely necessary to shoot the fish....