Calling it a train wreck is massive hyperbole. Just because React is so popular on hacker news or in the SF bubble does not mean it is anywhere near a de facto superior choice. Using such hyperbole detracts from the conversation and misleads young developers who may not yet know how to accurately weigh software stack decisions for personal or professional projects.

And this is coming from someone who was really excited for 2.x (and TS for that matter) but has resigned to probably staying with 1.x and es5/6 for the foreseeable future.

Totally my opinion but react is simply the best way to create user interfaces, regardless of language. If someone made react using Python targeting GTK components it would be the best. The one way data flow and flux architecture is superior to other UI frameworks I've used.

I find flux to be a really bad way to organize an application. It removes the good engineering practice of having self-contained components. So if you're writing a tabs widget you can't put all of its code together, you have to maintain a separate "reducer" or whatever for the tab state in a different file usually in a completely different location, and the top level of the application has to know about that reducer.

I think this architecture is an awful way to go, and I have no idea how it has become popular.

1. Tab state is presentation state, so generally belongs in the component rather than in Flux which is generally for business state.

2. If you do have a tabs reducer, it should be considered part of your tabs component. Use a good boilerplate that sets it up that way, like https://github.com/mxstbr/react-boilerplate

All of the components are totally independent. You pass functions as props for events that happen inside of the component, and choose to use whatever storage mechanism you want. Maybe you don't fully understand how react works.

I was talking about flux. You might have recognized it because I used the word "flux" in the first sentence.

> I find flux to be a really bad way to organize an application.

To be fair, Flux != React. Plenty of people do fine with `setState` and passing down props and you can get quite far. Honestly, I am with you that Flux/Redux ecosystem seems quite overengineered not by their "leaders" and creators (who ask people to keep things simple!) but by regular users. A lot of people solving problems they don't have.

I'm using redux with angular2 at work. Flux != React, and angular2 itself (just like React) does not impose any required data flow or other organization even.

I'm not making any value judgment here; I dislike React and it's over-abstraction paradigm. I long for the days when web components will be mature enough that we can leave frameworks behind.

But there's no denying that if you go to a web/js meetup in just about any city in the US 8/10 talks will have something to do with React, and that's the position Angular was in 3 years ago. Doing silly things like maintain 2 frameworks with the same name isn't going to help.

FWIW, I don't think number of talks on meetups is a good measure of long-term success at all.

AngularDart's play is not to be the next React (the same way Go is not trying to be the next PHP). AngularDart users at Google are, to my knowledge, extremely happy with the framework, but their enthusiasm won't necessarily (or even probably) translate to large portions of JS crowd. AngularDart works for a specific set of problems (very large web apps that need to be performant and work well on mobile, built mostly by developers with classic CS background).

I personally think insisting on the one framework (Dart+JS+TS) was the silly thing to do, and I'm glad that's over.

What stops you from migrating to 2.x? I'm geniunly interested. I have a fat app in 1.x myself but for new peojects I would consider Polymer instead of Angular 2.x

Happy to answer that. First off we don't use vanilla angular 1.x, we use meteorJS + Angular-Meteor which means we're locked in to Meteor's build pipeline.

Angular-Meteor supports both 1.x and 2.x, and Meteor's build pipeline has us writing angular code in ES6 that is on the cutting edge of 1.x and looks very similar to 2.x without actually being typescript.

The Meteor and Angular-Meteor teams are both really great, really quick response times to issues and combined have a really great ecosystem that helps bridge the gap between traditional angular libraries and the Angular-Meteor stack.

However 2.x support in Angular Meteor is slightly different then the bleeding edge of 2.x from the Angular teams. Last I checked their are a few shims and it is also incompatible with a lot of third party meteor and angular-meteor libraries. Furthermore switching to 2.x would require a decent amount of refactoring, not necessarily because we'd HAVE to refactor it but because if we did refactor we'd want to take advantage of as much of 2.x as possible which would require rewrites.

Finally I don't really like Typescript. I think its advantages over ES6 are marginal for most small or medium apps. Having to refactor Es6 -> Typescript and 1.x -> 2.x seems like a lot of work to me, especially because 2.x will have the growing pains of being bleeding edge, meaning fewer stack overflow answers and a much smaller ecosystem.

For a new side SPA project where I could write a custom build system via Gulp I would probably write it in 2.x, or maybe try out React. But I still wouldn't use it for a new production app because I see too much added complexity that would diminish the productivity I've already built up in 1.x.

Oh and then the only effect it has on end-users is slightly faster performance. You can argue for weeks over the value of this, but for us it's fairly marginal. Our app doesn't render tons of rows or anything that is slow to begin with, so it would almost have no affect on them whatsoever.

Thanks for the answer! Shortly said I feel the same. Angular 2.x would bring fairly marginal value to an existing project. Considering the amount of refactoring it's not worth it yet.

Since ES6 is valid TypeScript, it seems like you could move to Angular 2 without learning much about TypeScript (beyond how to run the compiler).

Not just hyperbole, as others have suggested, but most of what you're saying is flat false. Google's (and maybe the world's) most profitable app, AdWords, is built on Angular 2 and Dart, as is their entire internal CMS. Inside and outside of Google, Angular 2's adoption numbers are extremely impressive for a beta framework.

Yeah, this is really bizarre. It was confusing enough that Angular 1 and Angular 2 are completely different. Now there are two completely different versions of Angular 2 with potentially different support cycles (and different bugs).

The Javascript wild wild west.

Unfortunately that also means web www