As great as Angular 2 seems to be, by breaking compatibility to the point they did, they've essentially created another framework.
For someone looking to upgrade from Angular 1.x, this shifts their thought process from "should I upgrade to Angular 2?" to "which new framework should I upgrade to?".
And for many people, that new framework isn't going to be Angular 2.
The Angular team is currently exploring options to ease the upgrade path - the current plan last I saw is to create an engine that runs angular 2 components in angular 1 and vice versa for seamless interop, so upgrading can be more incremental.
That is an evolving story, which has changed several times before reaching that point.
That said, Angular 2's performance is already looking phenomenal, and assuming some of the stats I have seen out in the wild are to be believed, it can run over 30x as fast as some of the existing frameworks for large datasets, including angular 1. If I had to choose a library to use now, it'd be React, but if I had the opportunity to hold off upgrading, I would absolutely wait for Angular 2.
As someone who loves Angular, searching for information on Angular 1 vs Angular 2 is insanely frustrating. They should have just renamed the damn thing.
There's a very natural upgrade path from Angular 1.x to React: start building new little components in React and patch them into your app in Angular directives.
You can even apply the flux pattern to good effect within the directive while still making use of your existing Angular service infrastructure. Per Evans this would be an Evolving Order over a pair of Bounded Contexts.
Even though the Angular part wasn't very big at the time and the rewrite would not have been too costly, it would not have been wise to move to Angular 2 just to have them pull the same thing again for Angular 3.
Except... have you seen the changes between 1.8 and 1.13? It might as well be a new framework. So far moving from 1.8 to 1.8 on CLI has taken my team 3 months, and we still need to migrate to 1.13 if we are to remain supported. Ember provides an upgrade path, but it is a long, miserable slog.
I'm really sorry it's felt like a slog for your team. We've learned a lot from the transition from 1.x -> 2.0, and definitely didn't get everything right. That said, we think we can refine the 2.x -> 3.0 transition to make it much smoother based on what we've learned.
Given how fast the frontend ecosystem is moving, we've tried to strike the right balance between delivering new features and taking care to ensure that we don't leave the existing ecosystem of apps behind.
I think you'll agree that if we did nothing, our community would slowly die off as people moved to competing libraries and frameworks that made them more productive. So total stability would feel good in the short term, but long term, having to do a wholesale rewrite of your app because the framework stagnated would be much more painful, right? (You can approximate this effect by locking yourself into an older version of Ember, which sucks! People rightfully want the new features.)
The goal of Ember's additive-only strategy is to deprecate features, rather than remove them. This is more work for the maintainers, but we think it's worth it because users can "refactor towards the future" at their own pace, amortized over the year and a half between major releases. Development teams have a natural ebb and flow, and that amortization of deprecations over the year means you can use lulls/downtimes to refactor the deprecations out when it's most convenient to you.
We made a mistake and rushed in a bunch of deprecations in 1.13 because it was our last chance to remove features for the next year or so. In retrospect, we got overzealous, and for that I am sincerely sorry. Users like you rightfully felt overwhelmed, and that is something the entire system is designed to avoid.
If there's a bright side, it's that your app should continue to work as you upgrade, and when you're ready to make the jump, you can upgrade to Ember 1.13 and refactor away all of the deprecations. Once that's done (whenever you decide to do it), you will be able to upgrade to the latest version of Ember 2.x, because Ember's SemVer guarantees means that a deprecation-free 1.13 app is compatible with any 2.x version (2.7, for example).
Sorry again that it's been a slog for you. Once you're through it though, we hope you enjoy all the new features, and we certainly hope the simplifications we've made to the framework over the last year make it easier for new developers to join your team and get productive.
My experience working through ember and ember CLI versions was that it was tedious and time consuming as well. It is not stable software and fixes don't happen or don't happen fast (so many utterances of the word "months" in the ember world).
Lots of marketing though. It's not really backwards compatible, they just like to claim things like that. If you say it doesn't work, well you must be doing it wrong. Very typical of Emberjs.
Pretty much goes with the territory. Javascript is sort of a mess right now. Everyone is figuring out the best way to do things. The exact same thing happened in previous projects of Yehuda's like the Rails merge where 3.0 brought a tremendous amount of pain, but 4.0 significantly less so. Or Bundler, where people cursed it up and down for the first two years, but once it stabilized it was amazing and now everyone just quietly uses it without problems.
I really trust Yehuda and Tom's approach with Ember. Yeah there will be pain and breakage, but that's better than making a long-term commitment to the wrong thing. Over time it will converge (and I think it is already to a significant degree) on the right abstractions and then stability will come, but to do so prematurely leads to an inferior framework. If you need stability in your front-end then Ember (or god help you Angular) is probably not the wisest choice—I would even consider your options of just going server-rendered for current projects to give a bit more time for the ecosystem to mature.
It sounds like the core team is contemplating doing LTS releases, which should ease the fears of anyone who worries they'll be left behind if they can't keep up.
I'm not sure LTS would help us. If 1.8 had been deemed LTS we may have delayed the upgrade work until it was EOL... then what? We'd still be facing months of upgrade work, but on a significantly larger code base.
This is a problem of platform maturity. The Web is moving too quickly for monolithic framework solutions to keep up. ES6, web components, shadow dom etc were not part of the landscape 12 months ago. Ember and Angular are both doing admirable work in all of these spaces, but they're leaving their users in their wake.
I'm just not sure what you are supposed to do if you want to build a multi-year project with modern frameworks in 2015. My current suggestion is that we don't, accepting that the web site is just a skin over your api, that needs to move with the fashion, so expect to replace it every 12 months, minimum... that doesn't go over very well with executives.
The jump to Ember.js 2.0 involves API changes, but I see no reason why the majority of application will not move forward.
Your experience sounds very painful, but many Ember applications, even ones that are over two years old, have already made it onto 2.0. That is not meant to trivialize your pains, but just to challenge the idea that we're leaving people behind.
Ember's 2.0 strategy is specifically designed to ensure as many people get to 2.x as possible. That is our goal. I'm rather proud of the number of mature, long-living codebases build with Ember that continue to progress with us.
> I'm just not sure what you are supposed to do if you want to build a multi-year project with modern frameworks in 2015. My current suggestion is that we don't
That is an option. The web, and single-page applications, offer unique advantages but like any platform also come with limitations. Companies like Yahoo, LinkedIn, Zendesk, Twitch, Bustle, and many others have placed big bets on this architecture though, and use it successfully.
Sure, but does doing it all by yourself really put you that much further ahead? That does not slow the pace of change. You have more granular choices, but you have many many choices you are forced to make. If you trust the people making decisions behind the framework, it still seems like the better choice.
The solution would be to do the incremental updates as they were released. Yeah it's no use to you now after you've fallen behind but it's the easiest way to be able to update your project rather than dropping behind 4-5 versions.
To be fair, Angularjs (since you are obviously talking about it) backpedaled their "second system" a bit(since users complained loudly) and there is now some level of compat between the v1 and v2. But yeah, one shouldn't break apis to a point where each version is a brand new framework.
> To be fair, Angularjs (since you are obviously talking about it) backpedaled their "second system" a bit(since users complained loudly) and there is now some level of compat between the v1 and v2.
Why is that obvious? I can think of several other frameworks that this would apply to. Drupal for instance, Yii is another and there are quite a few more.
The upgrade situation with Drupal is, frankly, a disaster. Every major revision from 6->7->8, breaks literally every module and every third party piece of code. I'm months into migrating our website from 6 to 7 (I'm the only person working on the migration, and my PHP experience is somewhat limited). Many common modules provide no usable upgrade path, even if there is a version for both 6 and 7 (which is often not the case). And, there seems to be no inclination on the part of Drupal core developers to alter this course, or even recognition that it's a horrible user experience.
According to some conversations I've had with folks, Drupal 8 seems to be even worse than Drupal 7, and Drupal 7 is literally the worst upgrade experience I've ever had. Piles of new jargon and new APIs get introduced in every new release, and often replaces or subsumes entire swaths of similar functionality in previous releases (e.g. nodes -> entities), and Drupal was already ridiculously jargon-heavy to the point of documentation making no sense to someone without extensive experience with the specific ways they use terminology, and googling generic terms like "node" and "entity" is a laughably unhelpful process.
I have, at many points in this process, thought: "Fuck everything about this, I'm migrating to WordPress." I probably should have done so the first time I thought that, as it would be done by now. But, every time I made it over another hump in the upgrade, I thought, "Surely that was the worst of it." and kept slogging along. Upgrading WordPress is literally a no-brainer, now...you just get emails every week or two saying, "Your website has been updated to the latest version of WordPress." Sometimes, you click the "upgrade database" button.
Sorry to rant. But, I happen to be working on my Drupal upgrade again today, so I'm grumpy.
The biggest gripe I've had with Drupal was when moving from 6 to 7, they had module writers pledge that their modules would be ready on the release day of 7, which a lot of folks broke the promise or worse, abandoned the project all together without letting anyone know.
So some folks were caught not being able to upgrade due to a crucial module being abandoned at 6.
But, the biggest problem I have is that even when there was a pledge to do so and when they actually eventually produced a D7 module (Drupal 7 is several years old...I spent most of this time waiting for the modules we rely on to become stable on Drupal 7), there wasn't a pledge to provide an upgrade path...so, you've got data in some module in Drupal 6, and no way to get that data into the same module in Drupal 7. Often there are bizarre workarounds, like using the Migrate module, which is designed to handle all sorts of migration tasks and is thus endlessly complex, and requires custom migration code (and comprehension of a huge swath of even more new jargon and convoluted, baroque, APIs).
It begins to remind me of Zope/Plone from many years ago, which had many of the same problems. Lots of jargon, lots of new ideas in each version before the old ideas were stable or fully implemented, painful upgrades, tight coupling of interfaces making changes in one part of the system require changes in every part of the system. A modular system is nearly meaningless, if every module has to be rewritten with every new release.
Because both Ember and Angular are front-end frameworks AND competitors.
The issues with Yii and Drupal are a bit different. Yii is a serverside framework. And Drupal a CMS. I'd say the case with Drupal is way more problematic than Yii's though.
I think the more generalized point that was being made was for any framework, front-end, back-end, middleware, CMS, whatever..
Properly handling deprecations and providing a clear and reasonable migration path for your users will keep them happy and will keep them upgrading instead of either sticking to old versions or jumping ship.
These are not concerns that apply only to front-end frameworks.
I think both meanings are implied and definitely both percieved. The first have "every framework should take note" is more general, and I would mostly agree. The ember team has seemed to manage their project very well. Though I don't like the style of Ember itself, personally. There are often times with projects though where breaking changes are necessary for evolution of the software. I'm not sure if there were any major trade-offs with Ember. That may be because of good planning, but good planning like anything else takes resources, and often that resource is time.
The "that's how you avoid creating another framework and fragmenting community" comment is pretty clearly about the angular mess last year, and rightly so. I have a love-hate relationship with Angular. It's been a complicated journey and at times handled poorly. They seem to be on a better track now.
Regardless, I don't think there was any malintent in nercury's post. They are all good lessons learned.
No, I did not actually had Angular in mind when writing this. We often hear talks how new major version should handle deprecation gracefully. It was more the reaction of actually seeing it happen.
- The switch from symfony 1.4 to Symfony 2.0 requires a complete rewrite. Support for symfony 1.4 stopped fairly quickly; there seemed no understanding that companies wouldn't pay to rewrite their messy-but-working systems onto a 'cleaner' framework.
- MODX Content Management System. There is no upgrade path from 1.X to 2.X. Good luck to you if you've invested years developing your site on 1.X...
Been a while, but from what I remember, upgrading Drupal itself usually worked okay, but you couldn't because most sites relied on 3-4 contributed modules, and it would take another half year-year for them to also upgrade, if ever.
I've had the same experience as you. I've never had a problem upgrading a Drupal site because of the core modules. Everything in the core upgrades fine. It's always a contributed module that breaks stuff.
Unfortunately the aforementioned backpedaling--the new router--only allows Angular 2 components to live side-by-side with Angular 1 components. If you want any Angular 2 features you still have to rewrite that component.
As already mentioned, the upgrade path for large apps is not quite as simple as the line implies.
Ignoring that, this concept of backwards compatibility above all things is so strange to me. How modern browsers work has changed fairly dramatically over the last several years. Not to mention a major, major overhaul of ECMAScript.
And yet, every. single. time. we have something that mentions backwards compatibility being straight-forward, the top comment is always about how re-writing frameworks are bad.
I don't have a problem with the way the Angular team are doing things. Angular 1.x will be supported for a long, long time. And even though this hasn't been announced, I expect the 1.x and 2.0 branch to gradually merge, requiring minor changes to code at each minor version increase.
So effectively, Angular 1.4 -> 2.0 is no different than Ember 1.0 -> 2.0 with the caveat that 2.0 was planned in advance so all of the minor version changes will lead to 2.0, rather than 2.0 being the outcome of minor changes in 1.x.
Yes, super happy the core team keeps as a priority minimizing the pain of tracking new releases while continuing to evolve Ember. Kudos to the core team.
Which is sort of ironic, given that Ember.js was originally called Sproutcore 2.0 [1]...But I digress. Props to Tom, Yehuda, and everyone else. I've been dithering over whether to get up to speed on Ember or React, but I feel like the 'Batteries Included' approach that Ember provides and the very aggressive approach to cruft removal is what's right for me.
To release a 2.0 that basically is a 1.3 without some things is not much of progress. It will be interesting to see if they can complete new planned features without breaking the api when they move through more 2.x releases and later 3.0.
No, actually, there were quite a few new introductions between 1.11 and 1.13 (Glimmer, the new rendering engine; Actions and API changed, ED became 1.0, got more stable), and, as a result, there were numerous deprecations in the 1.13 release. 2.0 removes things that were deprecated in 1.13. Things like views, active model adapter, etc. have been extracted out in an addon.
None of these things broke the API; there was always a sane (although sometimes painful) process to help you through the upgrade. There are other things planned for the next few releases, such as routable components, new component syntax, etc. but the things they will replace (controllers and the old component syntax) will be supported through the 2.0 cycle (at least that's what's said).
Ember's deprecations in 1.13 were a bit of work for me, as a developer, but the new features in the past few months have done a lot of good to the framework and removed a lot of the complexity. I much prefer this way of upgrading, and I really, really appreciate the Ember team for doing it this way.
It's not a marketing release, Ember is simply following semantic versioning. Many of the new features that might've slipped into a 2.0 have made it into the last few 1.x releases, since they could be made backwards-compatible; e.g. Glimmer could've been held back for marketing reasons, but they pushed hard to get it out ASAP in 1.13 in June.
and shrinking :) We have some fun related work planned to continue the shrink.
One thing to note, often we must trade-off bytes for supporting older features. As those go away, we shrink. But moving forward the plan it to have more of a pay-as-you-go model. Utilizing ember-cli to do the r.js optimize esq step, to strip unused portions etc.
Nothing ground breaking, its tried tested and true in many other ecosystems. But when it lands it will provide nice value for our ember apps.
It's big, sure, but that's just another piece of decision making information. If you're building an app that'll be deployed for users in sub-Saharan Africa then it's clearly too much, and you need to revise your technology decisions. On the other hand, if the majority of your users are affluent westerners with broadband connections then it's less than the size of a single, full-screen background image, so arguably it's actually a relatively small download. What is "too much" changes - 120kb library, for some users, isn't too much.
That said though, if your ember.js code blocks rendering, or causes lots of repainting, and you're building a site rather than an app, then I'd question if you're making the right choice.
My Nexus4 has a faster internet connection and more RAM than my parent's laptop, and it's almost a 3 year old phone. Most (75%+) smartphone users in the UK have devices that can easily cope with a 120kb javascript library. Your rule is wrong for western countries.
E.g: is it an internal tool? Is it a landing page? Is it a SPA that has to do a bunch of things before content can get rendered? These considerations have an effect on what is an acceptable webpage weight for most teams.
Traditionally those sites may have also consider
I am sure they will continue to be happier as the byte size shrinks, but in the interim they are able to deliver what appears to be a great user experience, in-light of your concerns.
Ember is fairly all-encompassing. Sure, if you compare it with JQuery, it's big. But if you compare it to the full stack of libraries you need in order to run a reasonable React app, it's not too shabby at all.
It seems comparably pretty terrible to me actually after a bit of checking.
React comes in around 26k, Flux is another 1k or so, and say you throw in underscore that's still something like 30k combined. Add another 5k if you need an es5 shim / sham (say you're supporting earlier IEs). Another 4k for superagent. So it looks like somewhere around 40k minified and gzipped to run a reasonable React app.
The nice thing is that you don't even need jquery once you're in react land, unless there's an addon you absolutely must have and would be a pain to reactify. We haven't had to use jQuery in our last few projects.
That's 3X though and not 8X. 8X sounds like a biased exaggeration. I don't understand why people have to polarize so much over js frameworks...
Now I also think Artsy does a lot more than Bustle, to be fair. However the point is that framework size is only a part of the story. The complexity of your code, how you ship it, and how concisely the framework lets you express a design are all extremely impactful.
Ember gives you a big bang for your buck with that 108K (a minified, gzipped 2.0). In practice not many people find this to be the main performance hurdle in their apps, but regardless we're working toward smaller payloads (something we call "svelte builds") and better initial execution performance (https://github.com/emberjs/ember.js/pull/11576).
Exactly my thoughts. Only one JS framework of that size. You'll probably include a few more JS (analytics and what not)... no wonder my "unlimited but limited" mobile plan is hitting the limit every month.
Artsy.net home page weighs 5.2Mb compressed. Less than 20% of that is JavaScript that is fully cached between page views. Let's suppose average visitor will watch 3 pages on average visit. He'll consume 800Kb of JavaScript and 12Mb of images. Most likely, next visit visitor browser won't download any JS at all. If people are OK browsing so image-rich website on their phones, developers shouldn't bother about 140Kb of Ember.JS if it helps them deliver app faster. JavaScript is less than 10% even for the first time visitor.
I don't know artsy.net, it's probably image heavy.
But an average webpage size of over 1.5MB is not acceptable onmobile, imo: http://www.websiteoptimization.com/speed/tweak/average-web-p...
Also: http://royal.pingdom.com/2011/11/21/web-pages-getting-bloate...
It's far more then it should be. Graphics can be size optimized, SVG or jpg. A JS framework doesn't need to be 100k where most webpages are probably only using a small subset of functionality. And i also don't want to download a gazillion other JS files for web tracking and such things. Ever download on a high latency connection hurts.
Even though you always hear about the mobile web, web devs simply aren't trying hard enough to make the mobile web experience pleasant. They'd rather complain about mobile safari or mobile chrome than actually look at their own product.
(Yes, this is a generalization, but generally, the mobile web sucks.)
Your problem is a mobile network operators' problem primarily and not web/mobile devs'. Don't blame us for making the experience for you or us all prohibitively mediocre when those carriers are to blame for their ridiculous limitations imposed on data consumption and their exorbitant data plans.
That is really the thing, for a line of business application (which is what I write) I can hardly think of anything meaningful I can do in only 14k. If you are writing a marketing page for a random potato distributor I can see it, but even the standard run-of-the-mill home page has 1 meg of images, even more if there is video.
In 1999? Depending on what you're doing, ~100k of scripts is completely acceptable. If you just want some fancy UI interactions on a landing page, it is overkill though.
That's not 100k of scripts here, that's 110k of minified, gzipped javascript before you've started writing your own application, and it doesn't include ember data.
One dependency that has been holding me back is ember list-view https://github.com/emberjs/list-view. List-view does not work with Ember 1.13 and does not work with 2.0 since it does not support the new Glimmer engine. In a post on the ember site http://emberjs.com/blog/2015/06/16/ember-project-at-2-0.html, they said "Starting with Ember 2.0, we will coordinate every release of Ember with releases of the main ecosystem tools maintained by the core team:" and list ember list-view as one of the main ecosystem tools. Without list-view, I can't upgrade my app past 1.12.
I guess the best thing would be for me to quit complaining and just fix list-view, I just haven't had time available. I suppose the same is true for the maintainers. Is it planned for ember list-view to still be treated as part of the main ecosystem and updated to work with 2.0 soon?
I have the same problem. list-view 2.0 exists as a branch on krisseldens github (https://github.com/krisselden/list-view/network) and there have been other people forking from there. The implementation is _much_ simpler now due to glimmer, no more needing to get funky with ember internals. So it's essentially a re-write.
I haven't tried the 2.0 branch myself, but it _should_ be a drop in replacement.
That is good to know. I figured that ember-list view was likely using some private APIs and fiddling with the ember internals. It makes sense that the Glimmer engine would require a large amount rewrite work for list-view.
I just finished getting this working - if you clone that branch there is an example ember-cli app inside tests that has some examples which are great starting points.
Congratulations to the Ember team! It's been a real pleasure upgrading each minor version with minimal headaches. I can't imagine making this process more simple – it's one of the main reasons I use Ember a lot (mature, well thought out moves like this).
I'm amazed with that kind of release. Ember didn't do the same thing like Angular, CakePHP, Python, etc. That ensure that the documentation and all the Stack Overflow questions will stay relevant.
Especially the MVC -> Route-Glue-code-Component model (which I welcome). But yes, looking at the change log, it does feel like a bunch of deprications only.
Ember is an interesting example of when an also-ran doesn't catch up in time. It was better than Angular, but React came along. This seems to be a pattern... something cool happens and then improved versions crop up, but by the time they get traction, the paradigm has shifted.
Ember's new Glimmer engine has the same tech as React does. (and slightly better in some circumstances, but IIRC React will be doing the same soonish.) These frameworks tend to help each other, not hinder.
In theory you could, with components, but what I mean is that Ember's rendering technology now uses a similar but slightly more advanced form of React's.
So I wanted to try it out, being a nodejs newbie I tried:
sudo npm install -g ember-cli
And it gave me:
$ ember -v
version: 1.13.8
Could not find watchman, falling back to NodeWatcher for file system events.
Visit http://www.ember-cli.com/user-guide/#watchman for more info.
node: 0.12.7
npm: 2.13.4
os: linux x64
CLI will be following closely with a relevant release. To ensure trying ember 2.0 is as smooth as possible.
my apologies for any lag between the two project releases.
For those interested (or concerned) the CLI is not coupled to the ember versions, it actually enables interested users to switch between versions. Obviously we believe in more curated experience (hence the in-bound CLI release)
We take advantage of this version switching via https://github.com/kategengler/ember-try which enables ember-addons to automatically test against multiple relevant versions of ember.
> Why didn't all JS Framework creators combine into one team to create only one true JS Framework ?
Because devs will never agree on what should be the only one true JS Framework. Like programmers will never agree on what the one true language should look like. Just take JS itself, some devs think it's the "best language ever", others despise it.
Obviously things like unidirectional data flow is getting traction in every big framework. Yet some people think it's "magics" since the DOM doesn't work that way. Who got it wrong? all these fancy framework creators or people that wrote the DOM ? well the point is both were created for different needs , thus the reason why there will never be one true framework. Because developers have different needs and project requirements.
There was a guy who joined the Knockout or Angular team (I forget which) since they had similar ideas for the future of their frameworks. Not too long later, he left them and restarted his project as their vision began to diverge.
I don't know why anyone would want One True JS framework. Many of them provide different things. Angular has the kitchen-sink approach handling everything from templating, model-binding, routing and ajax requests and on the other end of the spectrum there are small libraries that do one thing well and encourage their users to adopt other libraries to do other stuff. Choice is a good thing.
Probably you mean Rob Eisenberg, creator of Durandal[0] for Knockout.js. He first joined the Angular 2 team as they shared visions and Angular 2 was planned to be migratable from Durandal but after a while he left to create Aurelia[1].
I'm keeping an eye on http://aurelia.io/ - I like the way it's going. There's no doubt Rob Eisenberg is smart; whether they can build a community & get traction around Aurelia remains to be seen.
> There was a guy who joined the Knockout or Angular team (I forget which) since they had similar ideas for the future of their frameworks. Not too long later, he left them and restarted his project as their vision began to diverge.
Developers have an itch to scratch. That itch is that they enjoy making stuff. If that itch isn't getting scratched at their day job, they will come home and develop a framework they will then blog about. Other devs will read about it, and their itch to work on the latest technology isn't getting scratched so they will start to use it. This cycle continues until the internet crumbles under the weight of all this crap.
I think Javascript is the best choice for front-end development (as JS is supported by all browsers natively). It's different with server-side languages.
There will probably be lesser frameworks in the future.
Everyone is converging to components based development and web-components are a standard, so they will be more similar than with the "we do our own idea of MVC" in the past.
The amount of diversity in JavaScript frameworks is NOT good in my opinion (a back end dev who needs to get a bit of front end stuff done every so often).
It's not like you have to use all or any of them. It's more of a problem if you're a front-end dev looking for work and feel obliged to learn whatever is trending at the moment.
Really? You have React, Angular and Ember. Three libraries or frameworks for building web applications. If you aren't building a web application you might not need any of them.
Just use React as the other two are copying/converging toward React.
All the other web app UI frameworks? Noise, they won't amount to much and add very little. The last release worth paying attention to was React 2 years ago. Hardly a breakneck pace.
Angular 1 or Angular 2? What about Backbone? Meteor? There are a LOT more than 3 frameworks. The choice is overwhelming when you are not a specialist in JS and its difficult to know where to begin.
(Though having tested React recently, its the best of the ones I have used).
Every framework should take note: that's how you avoid creating another framework and fragmenting community!
It's is great to see this in action :). Amazing work.