The Case for Angular, from a Hater

• John Vandivier

I am an Angular hater, although less and less so each day. This article discusses why someone like me would recommend a commercial application be written in Angular.

1. What Was the Problem?

Why don’t I like Angular? I looked into it when version 2.x first came out and compared it to alternatives. I consider the alternatives to Angular to be React, Vue, and AngularJS / 1.x. I preferred React because:

  1. It was more performant
  2. The view and logical layers were highly decoupled, and Redux is optional
  3. Typing is optional and decoupled, but when Flow is added it actually catches things TypeScript misses

I preferred AngularJS because it was established and ez mode. I preferred Vue because it is an easy transition from AngularJS.

I didn’t like Angular because it required learning TypeScript. Yes, it did. No, you cannot make it through normal app development using ES2015+. The tutorial allows it, but the larger community does not. I didn’t like that Angular requires a full-stack build process with transpilation. I didn’t like the overly verbose and non-intuitive syntax. To be honest, I really didn’t like that Microsoft’s name was within earshot (I had been developing some Visual Basic around that time…yuck…)

2. Why the Change?

First, I haven’t fully changed my mind. I still do not see Angular as better than Vue or React. I see them all as more or less equal. I do think React has an edge in architectural decoupling and performance, and I do think Vue has an advantage in simplicity.

Angular has an edge when you know you are building an application for scale, and you are willing to put up with a heavy, opinionated framework in order to get all the bells and whistles in a standard way.

For commercial applications, though, I am now using Angular. Things have changed in the library itself and in the community. It’s faster at run time, build time, and development time. The community is larger and documentation is better. More integrations and plugins exist.

Another major factor in commercial application: Clients, managers, and other near-IT-but-still-not-technical folks love it. The fact that Angular 5, or for that matter Angular 2, is completely different from AngularJS / 1.x is lost on many of them, but this works to the developer’s advantage.

While clients and PMs are afraid to try the “new and unstable” (so they think) React and Vue, they are happy to trust Angular. They’ve been using it for years! Sure, they used 1.x, but we’re just talking about a new version, right? No big deal.

Here is my specific recommended toolchain, summarized. Specific reasons are after the summarized list.

Summary Toolchain

  1. Angular Universal
  2. Bootstrap
  3. Express
  4. Webpack
  5. TypeORM

Angular Universal

  1.  Is a logical framework. A logical framework is required because the client requirement involves state management.
  2. Is an opinionated single-language framework to address front end and back end concerns. Therefore, it facilitates developer productivity and reduces developer lock-in.
  3. Is maintained by Google and widely used. Therefore, it is relatively future-proof and well documented.
  4. Leverages server-side rendering. Therefore, it is more performant and optimized for search engine (SEO) or other programmatic observation.
  5. Leverages TypeScript. TypeScript is a superset of JavaScript which enables static typing and additional features. These features can drive down the frequency of unexpected errors.

Bootstrap

  1. Is a UX framework. A UX framework is required because the client requirement involves responsive design.
  2. Is the most widely used UX framework. Therefore, it is well maintained and documented. In addition, the UX and development teams have a single point of reference because they are both familiar.

Express

  1. Is a JavaScript server. A JavaScript server is required because the proposed architecture includes a Node-based middleware layer.
  2. Is the most widely use Node server framework. Therefore, it is well maintained and documented.
  3. Exposes an extension system which is widely used. This allows fast developer implementation of many requirements in a standard way.

Webpack

  1. Is a JavaScript bundler and task runner, and it is also considered a build system or build tool. A build system is required to compile TypeScript, apply linters, automate testing, and otherwise ensure high-quality code and facilitate developer productivity.
  2. Is the third most widely used build tool, but the highest rated JavaScript bundler according to Slant. It also has more GitHub stars than Gulp or Grunt
  3. Is recommended for use with Angular Universal by the Angular team. The Angular CLI tool provides a basic application architecture with Webpack implemented.

TypeORM

  1. Is an object-relational mapping (ORM) library written in TypeScript. An ORM exposes a high-level API for database CRUD operations. A TypeScript ORM is required to improve maintainability and facilitate developer productivity.
  2. Is written in TypeScript. This allows easy integration with the Angular Universal build and run time processes.
  3. Allows configuration as code. This facilitates integration, maintainability, and documentation.
  4. Maintainability is improved because changes are simpler to make, written in one language, and configured in one location.
  5. Documentation is improved because documentation, ERDs, and more, can be automatically generated at build time using an integrated system.