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:*
"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.
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.
"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.
not true, while still developing the angularjs 1 app in my company it actually prints either a useful error or a cryptic long stacktraces error.
But basically it still is a awful framework, still working on the replacement.
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.
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.
> 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.
> 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.
You stopped reading after "I used it for two weeks?" Really? How much time do developers need to waste before realizing some software is bad? A month? A quarter? A year or two?
I should be able to look at a library or framework's API examples and say "I don't want to use this," and not have to waste a second more.
You can assess whether a framework is a good fit for your use case in two weeks. You can't assess whether or not the entire framework is good or bad in two weeks.
Exactly. There's a huge difference between saying something is objectively terrible, vs. saying that it's not the right choice for you (or that it's bad based on your subjective preferences).
Are you sure you don't want to say the exact opposite?
Something might look good, simple and logic, but you might discover in the end, after a long time, that it wasn't well fit to your use case.
On the other hand, something can be horrible, inconsistent, poorly documented and extremely hard to master, but might turn out to fit just exactly one specific use case.
In any case, we're talking about web applications. Which would be the use case that angular2 doesn't fit? And which the one it fits? Because I don't remember angular2 being advertised as something that has a very specific use case.
The use case for Angular 2 is super hardcore enterprise. Lots of developers, very large multimillion dollar projects, and safety being a top concern.
Everything must be done in a very standard way, and it assumes you need a bunch of stuff that only a fairly big application will need. Testing is very highly emphasized, with components being forced to be written in a way that is testable.
This guy clearly doesn't know what Angular is doing under the hood, meaning there is a bunch of stuff going on in his app that he doesn't understand, which is causing him lots of bugs and heartache. Many a time developers have built Angular apps without understanding what they are doing and ending up with a flaming pile of garbage that needs to be completely rewritten. However if you know what you are doing or hire someone that knows what they are doing to set up an application for you, I think the framework does have its advantages.
Having said all of this I really disliked my time working in Angular, with things like the terrible docs and lots of hidden esoteric knowledge needed being big flaws that they should address. For my company it made sense though.
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.
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
> 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?
React-redux templates have taken concern sharting, splitting domain concepts across several files named after $framework's concepts, to an extreme. The namespace babysitting is unpleasant, too. What technically justifies this?
The compile process is complicated but more because of ES6/ES7 than React and JSX. Everyone wants to use ES6/ES7 which isn't fully supported yet by all browsers. And yes there are a lot of dependencies for a typical project but again that is not really React's fault. React is a view library so you need a bunch of other crap to make something useful. What you say about Redux is spot on.
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.
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), 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.
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.
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.
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.
This is why I prefer React. I think JSX (HTML in JavaScript) is a much better idea than JS in HTML (Angular). The HTML tags in JSX feels like just some extra syntactic sugar on top of vanilla JavaScript when compared to angular directives(attributes?) which just look plain ugly.
Angular 2 has no reliable delivery mechanism, how would it be at all comparable to TCP/IP over unreliable transports? Also, TCP/IP relies on the machine to execute the TCP implementation without errors, which is analogous to Angular 2 relying on TypeScript and RxJS.
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.
> 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.
typescript is to js as c++ is to c. Not a perfect abstraction and still with some problems, but realistically as good as were going to get any time soon.
It's even implemented the same way, a massive preprocessor built to take away most of the pain from something so ubiquitous that it's unfixable.
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.
> 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?
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.
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.
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.
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.
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).
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..
> 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)
Interesting. I'd like to know, what is the size of your production team? And how experienced are they?
1 full time main developer.. two more working partially (5 hours/week) 45h / weeek
No prior experience with angular2. But we are long experienced front-end devs...
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.
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.
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
76 comments
[ 2.4 ms ] story [ 94.7 ms ] thread... but god forbid you mix up the syntax - the following will simply silently fail with no warnings:
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:* which doesn’t render anything at all.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.
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.
But basically it still is a awful framework, still working on the replacement.
Just let me use JavaScript.
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 ...
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.
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.
I should be able to look at a library or framework's API examples and say "I don't want to use this," and not have to waste a second more.
Something might look good, simple and logic, but you might discover in the end, after a long time, that it wasn't well fit to your use case.
On the other hand, something can be horrible, inconsistent, poorly documented and extremely hard to master, but might turn out to fit just exactly one specific use case.
In any case, we're talking about web applications. Which would be the use case that angular2 doesn't fit? And which the one it fits? Because I don't remember angular2 being advertised as something that has a very specific use case.
Everything must be done in a very standard way, and it assumes you need a bunch of stuff that only a fairly big application will need. Testing is very highly emphasized, with components being forced to be written in a way that is testable.
This guy clearly doesn't know what Angular is doing under the hood, meaning there is a bunch of stuff going on in his app that he doesn't understand, which is causing him lots of bugs and heartache. Many a time developers have built Angular apps without understanding what they are doing and ending up with a flaming pile of garbage that needs to be completely rewritten. However if you know what you are doing or hire someone that knows what they are doing to set up an application for you, I think the framework does have its advantages.
Having said all of this I really disliked my time working in Angular, with things like the terrible docs and lots of hidden esoteric knowledge needed being big flaws that they should address. For my company it made sense though.
So it's enterprise grade?
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
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?
The level of complexity was completely staggering. I was floored.
Like you can pretty much write what you would expect to write as plain HTML and it'll work.
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.
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), 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.
[1] https://en.wikipedia.org/wiki/Vertical_bar#Pipe [2] https://en.wikipedia.org/wiki/Pipeline_(Unix)
No, incomplete documentation, errors in documentation and other issues he mentions are objectibly horrible, not merely "bad for me".
http://www.catonmat.net/blog/frameworks-dont-make-sense/
<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.
Don't tell this guy about TCP/IP. Or quantum mechanics.
Without that connection, quantum mechanics may still exist and say the same, but no one will care anymore.
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.
typescript is to js as c++ is to c. Not a perfect abstraction and still with some problems, but realistically as good as were going to get any time soon.
It's even implemented the same way, a massive preprocessor built to take away most of the pain from something so ubiquitous that it's unfixable.
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?
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.
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.
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.
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.
Interesting. I'd like to know, what is the size of your production team? And how experienced are they?
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.
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...