Angular 2 is terrible

I spent about a year and a half producing a tonne of Angular 1 stuff, moved away from it for awhile, then decided to deep dive Angular 2 to get back up to speed. I encountered everything the writer of this article did.

While he might not be entirely accurate on every point (His animosity towards RxJS is a bit overdone but somewhat understandable; in my case, writing an observable sequence just to load in a single static JSON file just seemed a bit ridiculous while learning the framework), he's definitely right about the documentation part — it's terrible, even by Angular 1's standard.

Well in that note React sucks too... Yeah I said it. Lots of dependencies, complicated bootstrap process, too many abstract concepts, and if youre using redux which is necessary if youre planning to build anything serious, you need to edit like 10 files just to add a new feature.

> Angular is a not a JavaScript framework, but a TypeScript framework. TypeScript likes to pretend it is safe because it is strongly typed. This is somewhat true, but TypeScript suffers from the exact same problem Java does - it is not null safe. Worse, because TypeScript has no runtime component and emits no warnings for many unsafe casts, the language only offers the illusion of safety. For instance, this is perfectly valid TypeScript code that raises no warnings.

TypeScript has compiler flags to give compiler errors when null errors are possible. You can also turn off the implicit "any" type and use linters to stop explicit use of it.

It's a pretty good compromise given it has to work with what's out there already and it's certainly an order of magnitude safer than plain JavaScript.

It really annoys me when people make a declaration like "X is terrible" when what they actually mean "X isn't a good fit for me." Angular2 has some ... quirks ... that some developers don't like, but to write off the whole thing as terrible because you prefer something else comes across as overly critic.

If you can't see any good in something like Angular2 then it's you who has failed to look hard enough. There's some great stuff in there.

And in Vue. And Ember. And React. Etc.

This part is pretty scary... (sorry for the bad formatting)

... but god forbid you mix up the syntax - the following will simply silently fail with no warnings:

  <template *ngIf="condition">...</template>

The reason is because the you see is a syntactic sugar that essentially wraps the element in a <template>. The problem is when used on <template> tag this gets translated into:*

  <template [ngIf]="condition"><template>...</template></template>

which doesn’t render anything at all.

The author is completely wrong. I think he had misunderstanded the main objective behind using a framework like angular.

Angular is not build for developing a feature for an exisitng webpage. It's developed for building complex and large web applications, in a safe an eficient way.

I'm talking from my experience: We have developed a k3-k6 elearning/game platform in two months. Actually, it has 5 game types, a game creator/editor, user profiles, game boards.. it has around 20 to 30 routes (mostly dinamic) serving stored games and boards. Around 50 to 60 components (with some of them using pixi.js as a canvas render engine)

And despite of the growing feature list, we are still super confortable with the codebase. (We are just on the second iteration, starting the three).. You know something is good, when you are able to throw away parts of it and rewrite them without much drama....

The main application build, when gziped is around 380K ( Think that only firebase + pixi.js are around 150). But also we know that we will be able to split features (modules) for lazy loading them.. (and also our build will be smaller... because soon will be able to treeshake it)

PD: If your main use case is build a slider for a wordpress theme, angular doesn't fit, but instead, if you think on building (a desktop grade) application for the browser, even for the mobile browser you will find angular your best alliated.

A lot of things aren't correct in the article

Rxjs isn't a drop in replacement for promise. Rxjs is about stream, promise is just a way to avoid callback hell. Promise can be replaced by rxjs but not the other way around

You don't break the promise of being cross platform by using local storage if you do it the angular way.

I'm to lazy to keep going ...

I thought the comments aboout Typescript were misguided (not familiar enough with Angular to judge those parts). The whole point of using the any type in Typescript is to dodge the typechecker. By declaring the parameter in the example to be of type any, you are declaring that you want this behavior.

I worked with the author of this post on the said project. I am the guy that wrote most of the angular 2 stuff before the author joined the front-end (from back-end).

Here are some of the posts about my (not so negative) experience. I hope they provide another perspective on this issue and maybe give some context on why the author felt that way:

From Angular to Angular 2 – (Almost) Everything Changed

https://paradite.com/2016/10/09/from-angular-to-angular-2-al...

Building Angular 2 Drag-And-Drop Grid System

https://paradite.com/2016/10/17/building-angular-2-drag-and-...

Developing A*genda in Angular 2

https://paradite.com/2016/11/20/developing-agenda-in-angular...

> Let me repeat that: the framework claims to be more stable than its dependency and the language it is built on.

Don't tell this guy about TCP/IP. Or quantum mechanics.

Does Angular have any conceptual innovations that React doesn't? I've read deeply into both and it looks like both projects have identical goals, but React has simple and consistent principles while Angular is a mess.

Friends don't let friends use frameworks:

http://www.catonmat.net/blog/frameworks-dont-make-sense/

I worked on a project that used Angular 1.x and I remember thinking then that if this wasn't backed by Google, no one would use it. It was horrible with its magic directives and MVC on the client side. No thanks. I dumped it for RactiveJS which was waaaaay easier to get started and always had an answer when I needed something more complicated. Simplicity and good design in an API is waaaay under valued.

Well as someone who has been paid a lot of money to build Angular 1 stuff - Angular 1 is terrible too. This is just continuing in a grand tradition.

It's far worse than this article points out. Far, far worse.

Just made a basic master-detail form example (the heroes example) in angularJS 2. The directory size that it serves from : 346 megabyte. Now that is not actually sent to the browser. In "production" mode, 28kb is sent to the browser, for a total . After everything is sent, nothing's on screen (single page web app and all that). According to my browser, it takes 3.5 seconds from first request to everything done, 0.5 seconds until "DOMContentLoaded", at which point nothing's on screen. Seconds, not hundreds of a second. I am convinced I can make PHP without AJAX perform better than this. 116 different network requests, 4 at a time.

For true "oh my fucking god what the hell" effect, see the list of necessary files here : http://plnkr.co/edit/?p=preview (link is the official demo taken from angular.io). This is everything you need to write to get 2 forms and a frontpage working, not a single compiled or temp file.

Again: This is 2 forms, one of which is master-detail.

I repeat : this is the code for 2 forms. One of which has 2 edit boxes, the other has (what is effectively) a listbox. And there's a title page.

I still don't believe it, so I'm just going to repeat it again: this is the code for 2 forms. Nothing more. Nothing the least bit complicated.

Yes my graph editor component in Delphi and all of the app code around it was less code (granted, just barely). That had dozens of forms. Load/save, binary encoding for the file, ... and even code to synchronize with another instance of the app using command pattern (sort of like google docs, except 5 years before google docs).

Did the same tutorial, just for kicks, in Delphi 7, completed it in less than a twentieth of the time I'd need to just type all the code that needs typing in javascript, got it right the first time (while I wasn't able to get the javascript right the fourth time when typing it over character-by-character from the tutorial). Total size, including compiled app, 200kb. The app itself (while dependant on Delphi runtime dll), 4 kb. With static linking 116 kb. The angular site takes >800ms to load from localhost, not counting the delay before it starts displaying (it's a single page app, nothing is on the screen when the long list of network requests finally completes). The Delphi app loads in 4ms, and I'm pretty sure the display is updated just a few ms after that. And before you ask, yes, the Delphi app does in fact support client-server.

The feedback cycle in the Delphi app is measured in milliseconds (change code to view effects of running code, or from fixed code to "test has run and confirmed code is indeed fixed"). The turnaround in angularjs 2, and this is considered fast in web land, on my quad xeon, is just over 6s, and increased depressingly fast when adding stuff. Delphi has full 2 way synch (meaning forms are constructed using code, changing the code will change the editable preview, changing the preview will change the code), angularjs doesn't just not have double syncing, it doesn't even have a preview at all, not even read only.

Debugging in Delphi is perfect. Everything about it just works. Inspect data, change it, change the code and resume, ... all of it just works. In angularjs I cannot even see the bloody data at all. You can see the "compiled" javascript version, with mangled data.

The tutorial on how to do this in angularjs is about the size of packt publishing "intro to" book (those thin ones). The tutorial on how to do it in Delphi comfortably fits on one page with a large font, with a nice big box around the one piece of code you need.

It's not even angular, not really. It's the whole web platform that's causing this utter stupidity. But yeah, angular is making it a lot worse. Skip. Do not want. GTFO.

https://en.wikipedia.org/wiki/Worse_is_better

TLDR - I should have just written a blog about it. I use Angular a fair amount. I don't think it's any worse than your other UI application options. It certainly isn't great, but I wouldn't call it terrible.

I've read through a lot of comments here, and I've also spent many an hour struggling to understand why my application isn't working, both in Angular2 and Angular(1)JS. I wrote a reasonably well-received, and now slightly outdated blog on using Angular2 with docker-compose (that's right, I'm all up on the hip tech).

My least favorite part about writing an application in Angular2 is the rate of change in the framework itself. It can call itself stable, but is it really? Hard to say, since it's only been "stable" for a small number of weeks.

As others have touched on, however, this is not a problem peculiar to Angular - it's more a broader javascript phenomenon. Everybody in the JS world is bumping versions like their lives depend on it. And it's not without its benefits either:

At Angular2-RC1 I tried and failed to use the `ngc` tool for production builds with tree-shaking and minification. Suddenly, when I updated to RC-6, that process began to work. How exciting! This turned out to be mostly for nought, because today angular-cli (ng) takes care of most of this for you. The cli itself is still "beta" (some would argue that so is the framework, if not in name), but it can generate much of the necessary typescript boilerplate, and it does passable builds for dev and production with a single command. All this has happened in the span of about 4 months, so the rate of change has in this case brought welcome improvements. Source maps are generated as well, and error messages are helpful for the most part.

I have not used React, so I cannot make that comparison. Angular has many quirks (and problems!), but with angular-cli the learning curve for building and running gets a lot lower. The biggest issue is that the user-base is divided among those who are still using SystemJS, or using Webpack directly (ng uses Webpack under the hood now), and the the rate of change prevents documentation from keeping up. Also, yes it's very slow (angular-cli, not angular itself). It has a million dependencies. But my front-end application is actually organized, and significantly more readable in my opinion than any Angular 1 app ever was.

I can't go back to jQuery for DOM manipulation - 2-way binding is like crack to me. And Observable streams make it even better. As ever, I like it well enough, and everyone else is free to have another opinion.

Comments like "There is only one JVM" leads me to believe that the Java comparison was only pulled in as some type of smear.

I don't know that the author is qualified to say either way after only two weeks of using it; but I agree with many of the conclusions.

I have used Angular 2 in a professional setting for as long as there have been alphas(until recently, when I stopped). I am deeply familiar with its internals and have worked on debugging software for it.

I don't want to sound mean, but I don't think anyone should use Angular 2. I cannot think of a problem which is solved well, let alone the best, by Angular 2. Angular 1.x has some redeeming qualities, especially if you're trying to build out a semi-smart form or CRUD application, but Angular 2 makes these things markedly harder, while introducing massive complexity from build processes to content delivery. There are serious flaws in the template compiler. Despite many months of concerted, professional effort to document the framework, the documentation is still inadequate to explain the exposed behaviour. TypeScript suffers from all of the flaws expressed by the author of this article, if however slightly redeemed by decent autocomplete in VSCode (though I don't benefit, as an Emacs user).

I think it's fair to say that there is no authority to this post; but it is equally fair to say that he is nonetheless right on most counts.

I will avoid all frameworks that do stuff like

<li *ngFor="let item of items; let i = index; trackBy: trackByFn">...</li>

and

<li v-for="(item, index) in items" :key="item.id">...</li>

I'm just not going to write code in those custom attributes.