Why Angular is the best front-end for the enterprise
I have done a lot of writing around front-end technologies in the past; for this particular post, I want to focus on Angular and why it’s the best choice for the enterprise environment. Before we get into that, I think we need to figure out what I mean by enterprise environment. When I think of an enterprise, I think of large teams, lots of contributions, and something akin to a slow-moving ship. In short, it’s a large company with a lot of moving parts and often quite a few different projects. There are many enterprise companies out there, and I know this because I’ve worked for quite a few of them. Having worked for quite a few enterprises, I have noticed that they all have similar software development challenges, specifically, front-end development.
Since enterprises generally tend to have a wide array of products, standardization is generally an issue. They want all their products to be developed similarly, and they want to share common core code or components. I want to mention right away that these are not easy things to do no matter what you use. And these things may not even be possible or be your best option for your use case. These are just trends I’ve noticed over the years. Another trend I’ve noticed over the years is that Angular has become, by in large, the best front-end technology to help companies do these things.
Standardization
Angular in 2021 is opinionated, and it should be. When dealing with enterprise applications, you want a full opinionated framework that guides developers in a direction and keeps them on that path. Otherwise, teams are likely to veer from a single standard path, especially as the application becomes more complex. No matter how small or seemingly simple, all enterprise-level applications will become extremely complex at some point.
Angular helps enterprise teams deal with these challenges and complexity with its built-in standardization mechanisms, namely the Angular CLI. The CLI, or Command Line Interface, creates and scaffolds your application and the building blocks of your applications, like your components. You can spin up a brand new Angular project with a single command and get straight to work from there. With another command, you can create a new module, component, service, etc. Since the Angular CLI handles creating and scaffolding these new parts of your application, it frees you up to focus on building the application rather than trying to hook everything up. The CLI can do what you might otherwise have to take a few minutes to do in a few seconds.
There is another, less obvious benefit of this kind of standardization as well. Angular basically gives you a toolbox full of all the tools you’re going to need to build whatever you want. When you have a standard set of tools like that in every project, you get 2 main benefits:
- Every developer will know the toolset for every project in the enterprise
- You won’t have as many 3rd party dependencies in your project
When every developer on every project uses the same standards and tools, it becomes easy to train across teams. It also becomes easy to move resources around. If you have one project heating up and another cooling down, you can move resources onto the hot project, and they can start to jump in immediately. I’ve often said that if you learn 1 Angular project, you’ve learned all Angular projects. The same cannot be said of other front-end technologies. With React, for example, every project is completely different from the other. Every React project uses different tools and different patterns with little overlap. While this is fine for smaller projects or companies with a single offering, it can be a large burden on an enterprise or other companies with more products. It becomes harder to cross-train developers on these projects and increases the number of tools and patterns each developer has to be familiar with if you need to move them around.
Additionally, when you have fewer dependencies in your project, your final build becomes much smaller and more efficient. What’s even better is that you will seldom have 3rd party dependencies. As a developer, I don’t have to worry about if my dependency is supported or not. I know that all of my dependencies are always going to be supported. When it comes time to upgrade my dependencies, they’ll all get upgraded together, and they’ll remain supported.
Testing
We talked about how Angular will create and scaffold new components into your application, but it goes a step further. It will also auto-generate a starter spec file for testing your new component. It will contain a simple “does render” test, and you can start adding more tests after that. Angular also goes a step further than that by giving you a way to tell exactly how much of your code is covered by your tests. Angular uses Karma to do this, and it tests how many lines of code are covered by your test, how many branches (think if/else statements) are covered by tests, etc. Mind you; this comes right out of the box. You don't have to install any other dependencies. You don’t need anything but your initial auto-generated Angular application, and this all works right away.
Modularity
The way Angular has progressed has caused it to be written in an extremely modular way. For example, think about your application building blocks, the components. Angular is basically broken down into Modules. When you have a new Angular app, you’ll notice an App Module file. This is the main module that everything else will go into. Your components can also have their own Modules. You can think of Modules as the actual blocks that contain the components. When you want a specific component or group of components in a certain part of your application, you import the module. When you follow this pattern, you’ll notice it will become much easier to build an application. It will be much like working with actual building blocks. It’s easier to introduce new modules, take modules away, or swap out modules with each other.
This pattern keeps your application architecture a little more flat. Using this pattern means that you won’t ever have deeply nested components like you would in React. The great benefit of keeping your application architecture flat is that it’s more flexible and easier to change. In many React applications that I have worked on, simple changes can become a real nightmare when you have to follow a tree of deeply nested components and drilled down props.
Upgrades
Updating your dependencies is probably the bane of many front-end developer’s existences. It can be obnoxious and can sometimes fail. However, in the world of Angular, dependency upgrades are easy. Like most things, there is a CLI command for that. The CLI will go through and update your dependencies to the latest version, which is pretty standard. Most times, there aren’t any code changes to go along with that, but sometimes there are. When there are necessary code changes, the CLI will make many of those changes for you. If it runs into a piece it cannot update, it will tell you exactly what file and what line it tried to update, why it couldn’t update it, and the next steps you need to take. Furthermore, it tells you all the files it updated so you can review the updates.
This gives you the ability to safely and easily update your dependencies whenever you want. I want to focus a little more on the safety aspect of this. When dealing with enterprise applications, they’re generally slow-moving and often are behind the times. This gives the enterprise the safety it wants and easily maintains complex applications on the latest framework versions.
Wrapping it Up
I’ve gone over many different aspects of why I think Angular is the best front-end technology for the enterprise. I’ve focused on the aspects of Angular that make it suited well for the enterprise. It’s extremely standardized, the CLI takes away a lot of the boilerplate work you have to do, and the CLI provides a great deal of safety when creating components or upgrading your dependencies. While Angular does provide some safety guards, that does not mean you, as a developer, don’t have to know what you’re doing. You still need to be competent with the technology and understand how the Angular framework works. Having a framework that abstracts a lot of work for you is not an excuse to be lazy about learning how it works. The same can be said of any technology you’re going to implement. If you work at any company that has a lot of different software products consider using Angular to standardize and streamline your front-end development efforts.
If you’ve enjoyed this article I’d love for you to join my mailing list where I send out additional tips & tricks!
If you found this article helpful, interesting, or entertaining buy me a coffee to help me continue to put out content!
