
Angular 2 is terrible - Udik
https://meebleforp.com/blog/36/angular-2-is-terrible
======
aendrew
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.

------
alanz1223
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.

~~~
flukus
> if youre planning to build anything serious, you need to edit like 10 files
> just to add a new feature.

So it's enterprise grade?

~~~
NikolaeVarius
Enterprise grade tends to be complicated because they're BIG and has lots of
parts because there are tons of features

With react, have you seen the starter kits? It's like 400mb of dependencies
for a starter project that pretty much displays hello world with a interactive
button

~~~
flukus
> Enterprise grade tends to be complicated because they're BIG.

In practice I find it's just because enterprise software is over architected
and poorly generalized. With react native I couldn't get hello world to work,
maybe I needed to hire a consultant?

------
seanwilson
> 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.

~~~
raquo
The problem is, typescript will still silently infer 'any' type in certain
cases even with all the no-implicit-any compiler flags enabled, and you'll
never know when this happens until you have a bug.

Not to mention that its type system is unsound by design, and not because of
null. Typescript only pretends to be safe, so in practice you end up writing a
lot of type annotations for very dubious gain.

Stricter options like Facebook Flow or Scala.js are way more useful.

~~~
rkwz
> Not to mention that its type system is unsound by design, and not because of
> null. Typescript only pretends to be safe, so in practice you end up writing
> a lot of type annotations for very dubious gain. Stricter options like
> Facebook Flow or Scala.js are way more useful.

Curious, can you explain why Flow is a more "sound" type system than
Typescript?

------
onion2k
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.

~~~
bshimmin
I don't know; is there not some point where we can just declare something to
be terrible?

I looked at what he wrote about Angular's 2 templating, and then I looked at
the bits in the documentation about "pipes"
([https://angular.io/docs/ts/latest/guide/pipes.html](https://angular.io/docs/ts/latest/guide/pipes.html)),
and it really does look terrible - confusing terminology (is this really a
pipe in the sense that most people would understand?), confusing syntax (the
colons to separate arguments), and generally impenetrable without a trip to
the documentation.

~~~
onion2k
The pipe operator isn't really an Angular thing. It comes from Unix[1] and it
was first implemented in 1973[2].

[1]
[https://en.wikipedia.org/wiki/Vertical_bar#Pipe](https://en.wikipedia.org/wiki/Vertical_bar#Pipe)
[2]
[https://en.wikipedia.org/wiki/Pipeline_(Unix)](https://en.wikipedia.org/wiki/Pipeline_\(Unix\))

~~~
bshimmin
Yes, of course I know this - I'm sure many people know this. What Angular 2
calls a "pipe", though, doesn't refer really to the piping of the data (though
of course it also uses a vertical bar), but the actual thing that's
receiving/processing the data. Their previous name of "filter" was probably
better, except for use-cases where there was no filtering being done.

------
tsneed290
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._

~~~
coltonv
"Silently fail with no warnings" is like the angular motto... At least in
Angular 1 if something failed usually angular would just show an empty string
on the screen.

Debugging is just a cold dark hell where very very few resources can help you
find what went wrong, you basically just need to litter everything with
console logs (Except the template html syntax, which you can't just write JS
log statements in since... it's not javascript, its it's own language.

I've become much more productive and comfortable in all the JS vdom frameworks
which have no template language, just javascript.

~~~
hinkley
This, I think, is a common problem with library writing in general, and doubly
so for Javascript. Ember tries, but it's still remarkably easy to get a
cryptic error from it.

The ergonomics for using libraries needs to improve a great deal. I have my
fingers crossed that this will be something most people have on their radar
soon, but I'm not holding my breath.

------
jordic
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.

~~~
Udik
I'm not sure how this proves the author wrong though. The fact that Angular2
can actually be useful in a very specific use case doesn't mean it's not
poorly designed, horribly documented, cryptic and inconsistent (just to
summarize briefly what I think the post says).

~~~
jordic
Sorry I will not argue on all of the exposed things by the author.. for
example (decorators) is something that is also used on react libs. The point
to modules is completely wrong.. modules exist to allow lazy bundle (load)
parts of your app. Btw, I suspect the problem is mainly on the user level..
(anyone says that angular is targeted for novice users) at least to start
architect the app..

------
mickael-kerjean
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 ...

~~~
jaimex2
I stopped reading after "I used it for two weeks"

~~~
flukus
Two weeks should be plenty of time to put something through it's paces and do
a thorough evaluation.

~~~
heisenbit
> The home of a peculiarly minded 21! year old web developer

This developer was dropped into a larger project. He caught up with Angular 2
and TypeScript. He wrote an elaborate post. But maybe he had not been exposed
to a larger set of diverse use cases and software patterns in practice yet.

There are some learning hurdles to Angular 2 but imho. they are lower than
what was there with Angular 1. Documentation could be better of course. Moving
from 1 to 2 requires a bit of unlearning, it is essentially a new framework.

~~~
Udik
> There are some learning hurdles to Angular 2 but imho. they are lower than
> what was there with Angular 1

I really don't understand how people can claim this. I got my first basic
application running in angular 1 in about two hours- no, I'm not talking about
a tutorial but a small, real application. All you had to do to start was to
include the minified angular framework in the page and write some plain
javascript _functions_. That's it.

Now, I've been working with angular 2 for the past month or so (on a brand new
application). I still have very little understanding of what the framework
does or how it works. I found it pretty easy to understand the basic concepts
and inner working of angular 1, but I still haven't managed to grasp what
angular 2 actually _does_. Some things seem to work, some others just don't.
The documentation is obscure and lacking. The requests for basic features or
bug fixes have discussion trails that go from many months ago up to yesterday.

I just googled for the first example that comes to my mind- a pretty
fundamental question: what's the execution order of directives in angular 2
and how to influence it? On the first page of results, only the first two are
relevant (thanks Google!). Both are StackOverflow questions, and the answers
are:

>As far as I know the order of execution is undefined. You shouldn't depend on
a specific order.

>> That's just awful..

\----

> I think priority concept is yet not there in Angular2. (If it is already i'm
> not aware of it yet) but One should not depend on a specific order as
> already said.

\----

> Suppose you have _ngIf and_ ngFor directives on one element

>> that's not supported. For more details see _ngIf and_ ngFor on same element
causing error. At least for this case there is no requirement to specify an
execution order.

Thank god. It breaks so it doesn't even need the feature.

------
sixbrx
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.

~~~
FrancoDiaz
Decorators being at Stage-1 seems to be a special case. It's very unlikely
that decorators won't make it into the language.

------
paradite
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...](https://paradite.com/2016/10/09/from-angular-to-
angular-2-almost-everything-changed/)

Building Angular 2 Drag-And-Drop Grid System

[https://paradite.com/2016/10/17/building-angular-2-drag-
and-...](https://paradite.com/2016/10/17/building-angular-2-drag-and-drop-
grid-system/)

Developing A*genda in Angular 2

[https://paradite.com/2016/11/20/developing-agenda-in-
angular...](https://paradite.com/2016/11/20/developing-agenda-in-angular-2/)

------
filoeleven
> 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.

~~~
jbmorgado
Quantum mechanics is a fundamental theory in physics and therefore only depend
on maths. Maths, is by definition, eternally stable.

~~~
candiodari
The connection between reality and quantum mechanics, however, is subject to
unknown unknowns. That connection may not be stable, or might even not exist
in the first place, and rather be the effect of something else.

Without that connection, quantum mechanics may still exist and say the same,
but no one will care anymore.

------
Liron
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.

~~~
schwarrrtz
Well Angular was initially released three years earlier than React was. Also,
React is all about one-way data flows, and Angular is all about two-way
bindings, so that's one noteable difference in goals.

~~~
kitsune_
Angular2 is not about two-way data binding. Angular2 is much more similar to
React in that data flows downwards and events upwards.

~~~
schwarrrtz
Gotcha, thanks for clarifying. I didn't realize they had introduced
significant changes to the conceptual model.

------
pkrumins
Friends don't let friends use frameworks:

[http://www.catonmat.net/blog/frameworks-dont-make-
sense/](http://www.catonmat.net/blog/frameworks-dont-make-sense/)

------
DonnyV
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.

------
bryanrasmussen
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.

------
candiodari
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](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](https://en.wikipedia.org/wiki/Worse_is_better)

~~~
throwayawnotime
Word!

------
trey-jones
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.

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

------
microcolonel
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.

------
FrancoDiaz
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.

~~~
audleman
What do you prefer instead? I feel like I've gotten used to working with this
kind of thing, though some part of me doesn't like it.

~~~
devforey
If you're like me who doesn't like those magic things, I advise you try React
if you haven't tried before.

