Echo JS 0.11.0

Man, this article is a *total mess*!

There are many ways to speak bad about Angular, but you're actually missing basically all of them.

> Out went two-way data binding, replaced with one-way data flow, just like React.

Two-way was just considered too computationally heavy, that's it. That's why they introduced one-way data binding back in AngularJS 1.3 (the ">" binding), way before React came out.
In Angular one-way because the standard, and it's a good thing.

> Out went Controllers, replaced by Components, just like React.

Components are in AngularJS too, since v1.5 (and they've been behind the blurred concept of "directive" since the beginning). And they're quite different from React components or components from other vDOM libraries.
They're much more similar to Web Components and, as that, less capable (you can't have abstract components like <Router> or <Query>) but also much closer to the standard, as the Angular Elements project proves.

> There is no upgrade path from AngularJS to Angular

You're actually right on that, but is it really worth mentioning it in 2018? If you have to deal with AngularJS applications, they're probably all bloated with old patterns and bad practices by now, that's not worth it to just upgrade them to Angular: rewrite them from scratch (as you would do with React, anyway, but with a completely different way of thinking) or stick with AngularJS, really.

> it makes it easier for Java Devs to learn JavaScript by giving them things like strong typing, courtesy of TypeScript

Uh, not really. What it makes a difference here is that Java developers are more comfortable using a *framework* like Angular, and not juggle with libraries to cover all the parts of a modern web app.

Experienced that personally when I was a consultant for a project that had to be done by Java developers.

Do you think TypeScript is all about typings?

> I’m not sure why anybody would think this is a good thing.

Because it is?
Look, you can be comfortable writing vanilla JavaScript, as I am - but using TypeScript is undenyably pleasing. It's not a miracle cure, but it actually helps organizing your code, avoiding problems and speeding up development.

> if they want to learn JavaScript, then why can’t they learn it properly?

PSA: TypeScript is a *superset* of JavaScript. Which means, regular JavaScript is valid TypeScript code.
One of the strong points of TypeScript is that you can gradually introduce it in your workflow.

> I go for a Java job.

Jesus, this example is terrible! It's the JavaScript community that's moving towards static typings because they're nice to use; the other way around (getting rid of types because... huh) just doesn't make any sense.

Now, there *are* concepts that are common in JavaScript and awkward in Java. But guess what, Java *is* also evolving. Slowly, but still.

> When templating, the code that you actually have to HTML is some other language that Angular has just invented.

Yes, and as you mentioned, it's the same for any other modern web library. It's something we have to deal with, *including React*. Until Apple's proposal to introduce HTML templates with bindings will be introduced in browsers, and libraries will start using them.

Why, do you think JSX is *not* a templating DSL built on top of a HyperScript-like abstraction?

So this point is completely invalid.

> I’d never actually used the native .map() method before I saw it used in the React docs.

It would be far too easy to mock you about this (.map has been around since 2005, two years before jQuery's "equivalent" came out), but this actually tells something about you as a JavaScript evangelist.

> Angular gives you nothing to handle state management.

Yes, it's actually a fair point here. As a framework, it should do, because it's a concept that became central to develop a modern web application.
But then again, it's the same for React, Vue, mythril or whatever you pick.

> RXJS is based around Observables.

It's more than that: it's the JavaScript version of ReactiveX, which basically created a de facto standard about the concept of Observable.

> ... which are not native to JavaScript and might never be.

Sure. But they *are* on track, on Stage 1 and soon to be on Stage 2.
Compared to Redux or React synthethic events that's a big difference.

I honestly don't see Observables going away and there's quite some favour to standardize them, and they're actually one of the best traits of Angular (acknowledged by most of the community). It's not about Angular, it's about async and functional programming in general.

> You get an Observable, then convert the results to a Promise.

If you want. When using Angular, personally I got used to use Observables right away. The only downside to this is that I can't use await on them.

> This is, a new module with a different syntax to Http. Time to rewrite again.

This is why they're called "breaking changes", my friend. You can deal with them, or not. If not, stick with LTS versions of the library. This is all, and that's not just an Angular thing.
Good thing they've given you plenty of time to make the transition (you could use both of them in Angular 4).

> In React, you’re free to use whichever Ajax tool you like.

See, and *that* could actually be a problem, if you acknowledge there are good points in "having decisions made on your behalf". Libraries get abandoned, deprecated and marked as insecure everyday.
For me, it's hardly a problem, because I'm familiar enough with JavaScript to understand a library and its strong and weak points, maybe even before using it. It's not the same for a diverse team, which cannot spend time and resources to investigate which library is the best.

That's the strength of Angular.

> Stop already!

Yeah, stop writing rants like that: they don't help anyone, really.