Angular 17 Sucks
An objective analysis of Angular 17 and why developing with it sucks.
- Angular 17 Sucks
Defining a Good Web Development Toolset
Web development has to be one of the most quickly evolving disciplines in programming.
project "obsolete" before they even finish it. Therefore, it is very important to be objective when
choosing a toolset to work with rather than just following the development "fashion industry".
Below I have laid out an analysis that will show you that Angular 17 Sucks and why you should look elsewhere for you latest web development project. Should you choose WebRocketX or Vue.js for you next project instead? That depends on the nature of your project so you decide, but for now we will focus on how Angular 17 holds up to suck analysis.
First of all. Let's talk about a good toolset. A good client side web development toolset should have the following characteristics
Angular 17 Sucks For Developers As The Following Analysis Shows
So, let's see how Angular 17 holds up against these criteria. Angular's performance on each criteria is given a 1 to 10 rating. 10 being the best.
For some reason, Angular has to create a completely new ecosystem, complete with Angular specific nomenclature, abstraction, object hierarchy, and even pulls in Typescript. Yes, you can probably take some classes, do some tutorials, copy and paste some examples, and start to put together a web application but when your code doesn't work will you really have any idea why. What is the angular lifecycle exactly? When are your constructors called? How are you objects scoped? How do they really interact? What events are registered on DOM objects and how are they triggered. You will spend a lot of time learning that or just do trial and error until your code eventually works. When you get pretty good at it you will feel like a really intelligent person and maybe even start drinking the Angular cool aid. Nobody likes to admit they learned something overcomplicated and esoteric, so most people will eventually convince themselves that this is something good, but it's not.
Writing a web application involves doing several things. Firstly you want to display an interface in the browser, and secondly you want to render dynamic values into certain parts of that layout. These values typically come from a database. You will need to allow the user to input new information and send it to the server, and have some client side validation of that information. Lastly, you want the user to be able to navigate to different parts of the web application.
So, why are we counting the json layer as extra. It's actually quite simple because the developer has to double render the data. The data is rendered once into json in the service and rendered again into the layout in the template. However, someone could make the argument that services as a whole are worth the extra effort because they are reusable and can be consumed by other applications. Furthermore, a web application using jsp's could also consume a service and therefore make this extra layer a wash. Those would be good points.
However, the real pain point with Angular is its object model. It is truly an extra logical layer in Angular development, and adds a lot of complexity to an application. In Angular 17, data does not flow from the server into text which is rendered into the DOM. Instead it flows into a memory object model which is bound to the DOM with Angular registered events. This extra layer would of course be a horrible idea to maintain by yourself but Angular does this all automagically so the developer doesn't have to do it right? Not quite. Instead a whole bunch of structure and code and bindings all have to be made and variable names have to be matched and everything has be set up just perfectly in order for things to be constantly kept up to date and coordinated. You have to create an object reference for every instance of dynamically displayed information and also for user input elements located in the page.
The Angular object model is where the real pain begins because your pages start to look like objects within objects instead of HTML. So you end up creating an Angular memory object tree that is tightly coupled to your DOM object tree. Imagine this in the physical world. Two dissimilar trees tightly wired together at multiple nodes. It sounds like a tightly bound, brittle, inflexible mess doesn't it? Well, welcome to Angular.
Another abstraction is that all of your template snippets are abstracted because they live with each one of your objects that is bound to them. This can facilitate reusability of this layout but more often it just makes it harder to see the whole web page in one view during development.
If that doesn't suck enough, now put in the other ugly facts.
Angular does provide feedback in the browser script output console (using development tools) when things break. However, it is often far from being precise. Something as simple as leaving out a library import can result in very general errors that tell the developer nothing of the actual issue. The relative crappiness of the Angular debug feedback is something that has to be experienced firsthand to really be appreciated. Using an IDE that supports Angular and Typescript does help but it still does not compare to a good java IDE which will guarantee you do not make errors.
The Angular Object model, aka component, that has to ride along with the layout adds a layer of complexity that simple didn't exist in web applications before. Sewing this object model together with the DOM object (template) and then sewing this model together with service objects that are sewn together with json objects, forces the developer to write a lot of code. The developer will also need to work their way through this relationship chain anytime a new data element is added the page as well.
Another source of unnecessary keyboard work is the fact that imports have to be referenced at the top of the file with an import statement and then referenced again. Typing the same thing multiple times is so much fun. Here is an example and the following link. Angular is full of this kind of repetition.
Someone developing the Angular framework realized at some point that Angular forced user's to create a lot of files and lot of code. This is why Angular gives the user CLI commands to create files for new objects such as components and services. Isn't supplying the developer with code generation tools a big red flag that you are making the developer do a lot of tedious boiler plating that could simply be avoided by designing the framework better?
I think a rating of 3 is actually being kind to Angular for this criteria. The only reason it's a 3 instead of 2 is because the framework is generally flexible enough to allow for customization.
The Angular compilation engine must be written in a very rudimentary style because every object has to reference every object explicitly, plus you have to provide the compiler with full lists of your files. Nothing seems to be done by convention. Imagine programming a java application and having to maintain another file listing all of your class files and their paths just so the compiler can find them. Java doesn't work like that. The java compiler finds your files because they are in your project.
Half of the errors I make in Angular are just assuming the compiler knows classes by name. Not the case, adding any component to Angular requires putting it in lots of places. The CLI to create a component even adds a reference to the main module for you just in case you would forget. The idea of adding a package and then getting all the objects in it does not seem to be supported either. Nope, you will have to list them all out in the import statement and in the ngModule decoration. Have fun. Here is where all the fun begins.
An Angular generated DOM is not harder to "Selenium" test than a DOM rendered any other way. Angular supports putting fixed IDs on tags and fields which is really the most critical thing that any integration testing test suite needs.
Angular does not support any kind of drag and drop development interface. Furthermore, it's libraries like Angular Materials do not make for easy "lego" type page layout because every downloadable component requires matching Typescript classes to be manually coded to be wired to it. Angular's complicated design alone also lends itself to slow development for all but the most experienced developer.
Angular appears to perform well on all major browsers.
Angular applications by design download and cache all of a web applications pages immediately after download. Therefore, very large web applications with 100s of pages will perform very poorly when a user logs into Angular. In fact the browser can hang an unacceptable amount of time after login. The newer generation of Angular deals better with this situation than Angular JS did but its solution called "Lazy Loading" requires a significant amount of configuration to maintain. As can be seen by looking through their documentation, it's not pretty.
Once an Angular app is downloaded on a browser its ability to scale by load is only limited to the ability of the services it calls to scale.
Angular by design downloads and caches all of the pages that a user could possibly need. This means that these pages are downloaded regardless of the user's authorization level. Therefore administrator type pages and the attack surface for them are theoretically present when a user with less authorization logs in. To avoid this security risk, developers would have to make available different versions of the application for different types of users. Since many of the pages would be shared this will make for a maintenance mess.
Theoretically Angular users could be hitting against multiple service endpoints. However, forcing the user to login every time they hit an endpoint is unacceptable as is storing their credentials on the browser. Therefore, architectures that allows a login token to be downloaded to the browser and then used for the remainder of the user's session have been developed and these architectures are generally complicated because this token has to be recognized by all endpoints. Typically companies skirt this issue by serving the Angular static content from the same server that will also serve as a proxy for the services. This way the user only has to authenticate once and will also meet single origin browser security policies when calling the services.
Angular supplies no mechanism for server side errors, a developer will need to come up with this on their own. The solution will need to inspect every incoming json response for server side errors and have a universal handler for them.
Angular forms template and reactive forms both supply a mechanism for client side single field validation. Implementing combination multi field validation can be done but is more tricky.
The internationalization of labels on a web pages traditionally was done using a resource bundle on the web server. Since the resource bundle was stored in RAM even very large key value pairs with phrases registered in the 1000's would perform well when rendering different localities. Internationalizing with Angular would require treating labels as another type of json loaded data. Downloading a json resource bundle for a large application will require pull down 1000s of phrases. Both the download and the binding of the bundle to the labels will perform poorly with large data sets.
Angular results in the user's experience being intuitive with the exception of the behavior of the back button. Angular treats the routing to any URL as a forward motion into that URL even if the user used the back button. Therefore, by default, nothing the user typed into the previous page will be there for them. The developer can make the data stay by mapping the form fields to a service that persists longer than the page, but other DOM manipulation will be lost unless specifically coded to regenerate from a service variable. The back button is a major challenge for the web developer and is important to the user and Angular does little to solve this problem.