Note from the editor:
If you are a regular reader of my blog you know my heart belongs to ReactJS, it’s what I choose for my projects and is the framework of choice at the company I work for. However, there are reasons to choose other frameworks, and I wanted to hear from them and share that with all of you, so I invited Armen to tell us about his experience with Angular, why he likes it so much and why it’s the preferred choice at VOLO, the company he works for. Enough from me, let’s jump to his article.
In 2021, years of improvements in the frontend department of the web have resulted in a gargantuan amount of different frameworks, and a vastly interconnected net of dependencies. For companies, it means choosing a framework in particular, and a tech stack in general has become an increasingly challenging endeavor. Let’s discover together why Angular is a great choice for your next project and how it stands out from the “competition”.
As we already established, there are many options when coming down to web frameworks, but if you plan to develop large enterprise apps, the choices become somewhat limited: smaller tools like Svelte or Recks are great and devoid of some problems that their more advanced counterparts have when you think about them, but lack large community supported libraries and tooling. On the other hand, no one is ever doing Vanilla JS for a truly large project; and Ember.js is a bit old now, which leaves us with the three usual suspects: Vue, React and Angular. So let’s discuss them individually.
React is a great library (or framework, some might argue) developed by Facebook, built around the Flux design pattern. React is very simple to learn, someone who knows JS well and has worked with any other framework may start with React almost right away. But simplicity is largely achieved by not having too many features; what React does is only rendering the UI + state management, which is fine, but when it comes to large enterprise projects, all other functionalities that you might need, like form validation, HTTP requests, animations, and so on, are unavailable, and one would need to build their own stack around third-party libraries or their own tools. As the saying goes, you either use a framework, or end up writing one. Of course, the React community is rich with great developers, so all the third party tools are there, but because none of the tools is official, different projects use different tech stacks, sometimes entirely. In a corporate environment focused on outsource, different teams working on different projects use different tools, while all using React, which obstructs the exchange of experience between the teams. In addition, React does not support TypeScript out-of-the-box, and because Volo focuses on using TypeScript heavily, one would have to setup it manually or using unofficial tools like create-react-app. While all of this is true, React community moves towards having a well defined stack of third party tools, and the same create-react-app, while being unofficial, is de-facto considered the used tool for CLI, so it may remain as a future choice for our projects.
Vue has become increasingly popular in recent years, and rightfully so; the framework boasts a large amount of useful features, some of which are not even present in neither Angular nor React. But the main problem Volo teams see with Vue is the lack of the same out-of-the-box tooling that Angular has, and also the fact that TypeScript support is optional.
Angular is not an ideal framework; actually, it has a plethora of problems that many developers are aware of: Version upgrades can be a mess lots of times Community aims at using functional programming, while the team still makes OOP the official go-to paradigm, even after building the entire framework around RxJS (still required to use modules and zone.js based event detection) Libraries have to support ngcc, if we opt to use Ivy Engine (default after v9). Older unsupported libraries won’t compile No official state management solution; NGRX is most popular, but not a part of the Angular ecosystem by default But on the other hand, the framework has a number of advantages for working in enterprise projects, so let us discuss them.
When doing outsourcing for other private entities, we often encounter challenges endemic only to large enterprises: huge interconnected administrative tools, maintained by a large team of diverse developers. This in particular requires specific approaches from the team management: Opinionated and ahead of time design of the application structure, done by architects Careful and strict supervision of all the coding practices Uniform approach to solving similar problems Using built-in tools rather than deciding the tech stack every time So how does Angular help us in doing this?
Angular CLI is a powerful console tool for creating, maintaining and building Angular applications and libraries. It allows us to create new projects, generate components and tools, install libraries, and generate boilerplate code seamlessly. It is developed by the Angular team, so it is an official part of the ecosystem, and is almost universally used by everyone in the Angular community. And because it generates boilerplate code in a strictly predefined matter, it is suited perfectly for guaranteeing the first point of our approaches: opinionated application structure.
Angular apps built with the CLI come with ESLint support out-of-the-box, allowing us to run commands like “ng lint” to verify the adherence of our code to the best practices. It comes with a ready preset of rules, but we can always override or enrich them. On the other hand, the Angular Style Guide, while not being an exhaustive list of practices, provides a good basis for developers to follow and keep the code clean and neatly organized, thus fulfilling the second bullet point in our list.
Angular comes with a load of concepts, which is why some developers find it challenging when compared to React, for instance; but this approach has its own pros. For one, the separation of concerns is very strongly enforced in Angular: business logic belongs in services, data manipulations belong in pipes or Observables, DOM manipulations belong in directives. This strict separation of concern is exactly what we meant in our third bullet point: same approach when solving similar problems, without strange custom solutions.
Angular also comes with several libraries available. Some of them are available straight away (forms, http, aminations), while others can be installed later (internationalization, material), but all of them are official and grow and evolve together with the main framework, and follow the same rules. It makes choosing a tech stack in Angular incredibly simple: just use angular and its libraries. Sometimes one might want to choose another component library (like ng-bootstrap or ng-zorro), but usually just Angular Material is more than enough. This way, we avoid using too many third party solutions and stick to the official codebase, fulfilling the last bullet point.
For almost five years now, VOLO has used Angular in lots of successful projects. Our knowledge continues to evolve in parallel with new features being added to the framework, but as of now, the decision to stick to this particular tool has been very much justified.