In this article, I’d like to provide some additional thoughts and context for each of the discussion points that just didn’t make the cut for the video.
When comparing it to React - you need to remember that with Angular, you’ll have learned a framework that gives you everything you need to build full-featured frontend applications. Routing, HTTP requests, animation, data accessibility APIs, serverside rendering, translation, forms, and a testing framework, to name a few. With React, you’d have to learn all of these separately.
Online you’ll see this eloquently summed up as “react is a library”, angular is a “framework”.
I’ve seen a lot of discussions online that basically state comparing React and Angular is like comparing apples and oranges… personally, I’m not a fan of that idiom because you can absolutely compare apples and oranges - which might make it even more applicable. Angular and React CAN be compared and are compared so often because they are used exclusively of each other.
I can only imagine that there are a handful of poor, misguided souls who have attempted to use Angular and React together in the same application. When the decision is binary, the comparison is only natural - and fair.
Even if there was a case for Angular being technically superior for enterprise, A quick look at job listings in my area shows that enterprise has clearly had no problem taking up React or Vue for that matter.
I think Angular’s prevalence in the enterprise market stems from just being first. AngularJS was grandfathered in a lot of Angular teams. I do believe we will see a continued shift to React and Vue over time.
Yes, Angular does give you some architectural building blocks, but there is still plenty of room for architectural differences between applications.
I respect that this is a difficult concept to grasp if you work with a small team, on small projects. Just wait until your application hits 10, 15, or 20 engineers. Maintaining good architecture becomes a recurring struggle. I can’t imagine working on that scale without some of the architectural niceties of Angular.
Angular is opinionated in the same way that the instructions for IKEA furniture are opinionated - yes, you’ve gotta do things a specific way - but why would you even want to do it differently?
See point 3. This is a good thing!
Let me put this one to bed this way - If you are having performance issues with any modern frontend framework, the problem isn’t the framework.
At the end of the day, the performance differences between frameworks are negligible.
I think this is lost on a lot of Front-end engineers - at all levels. Performance is the thing I worry about least. I promise you that if you prioritize maintainability and readability over more performant code, you will be a much better engineer. I think the obsession with performance can lead to very detrimental coding habits. With all that said, Angular’s performance is genuinely great and gets better with every version.
Popularity becomes a much more important factor when we’re talking about the job market.
I don’t think you could go wrong with any frontend framework in a market like this, but there’s a case to be made that Angular is as hot as ever in this regard.
Seriously - Angular jobs are paying insanely high, and the talent pool is completely dry. If you can become comfortable with Angular, there are six-figure jobs with your name all over them!
I worry, though, that this will lead to companies thinking that Angular isn’t suited for their applications.
Remember, Angular developers, come in knowing everything they need to work with your app. Yes, they will be harder to find, but once you’ve found them, there won’t be any doubts about if they are familiar with certain parts of your frontend tech stack.
As someone who once felt overwhelmed by the switch to Angular and the need to learn typescript. - I know it is a hurdle, but having once gotten over that hurdle, I believe it’s worth the effort.
Stay tuned to my feed for more content about all things frontend!