Angular vs Vue vs React

Developer Experience AngularJS 2.0 Vue ReactJS
Client-side routing X X
Client-side routing, State-based routing (?) X
Command line interface (CLI) X X
Concurrency (synchronization), immutable data (?) X
Data binding & change detection/tracking, no dirty checks (good), getters/setters (bad) (?) X
Languages, ES6 JavaScript X X
Languages, Typescript (?) X X
Lazy (on-demand) loading of client-side code (?) X
Modularized, route-specific CSS X X
Module marketplace (?) X
No build process is required X
Observables for databinding a.k.a. KVO (?) X
Orders module dependencies (?) X
Preloads client-side data (?) X
Reload app on file changes (?) X X
Single source of truth, central state management (?) X X
Someone is paid to develop and support it (?) X X
Templating, parsable HTML, no imperative code allowed X X
There is a book about it X X
Two-way data binding (?) X
Typed (?) X X
Virtual, shadow DOM (?) X X
You can still use the technology if you sue the vendor (?) X X
User Experience AngularJS 2.0 Vue ReactJS
Derived, computed properties X
Realtime data sync (?) X
Dependencies AngularJS 2.0 Vue ReactJS
Collaboration Platforms Gitter, Stackoverflow, freenode Stackoverflow Stackoverflow
Languages Typescript, JS ES6 (ES2015), JS ES5 Typescript, JS ES6 (ES2015), JS ES5 JS ES6 (ES2015), JS ES5, JSX
Misc RxJS
Routers Angular Component Router

 

If you would like to help improve this report, please complete this form to apply for access to the data

Compare now with multiple-technology inheritance

This latest enhancement adds multiple-technology inheritance. Previously, each technology had a single ‘parent’ field that allowed you to specify another technology from which it inherits benefits. Now there are multiple parent fields. So entire technology stacks can be accurately represented. By combining all the benefits of all a technology’s ancestor and dependency technologies together with its own benefits we arrive at a more accurate total set of benefits you’ll get by using a technology. These complete sets will be used when producing the trade-off reports between pairs of technologies.

The parents are indicated at the top of the spreadsheet just below the summary point totals and look like this:

Screen Shot 2015-09-05 at 20.54.52

 

button (1)

Improved Trade-offs Reporting

I made a few little tweaks to the spreadsheet which really improve the readability of the trade-off reports.

Just open the spreadsheet and go to one of the trade-off worksheets. Select any cell in the row/column of two technologies you want to compare and click the “Zoom in” menu, then “Zoom into cell” menu item.

That will produce a modal that looks something like this:

Screen Shot 2015-08-14 at 15.37.24

 

You can then ⌘A ⌘C it and paste it into a single list in a text file and delete whatever you don’t care about.

Enjoy,
Dan

Updated: Comparison of AngularJS application seeds and generators

I update the data in this every day as I learn new things and watch tutorials, but I made a few significant improvements to the comparison spreadsheet since I started it.  So I sent off an email to all the project leaders describing what I had done.  I thought I’d put a copy of the message here too.  The response has been encouraging but mixed.  Stay tuned as things unravel unfold…

 

Hello AngularJS application best practices establishers and implementers,
It’s been a while since I wrote to you or maybe this is the first time, but I’ve made some enhancements to my case for why all of you should just work together instead of competing, and I wanted to share them with you.
First, I’ve gotten a few more responses to my survey and added a couple questions.  It still says about the same thing – 73% of respondents would prefer there to be just one AngularJS starter, compared to 13% who would like you to keep on competing against each other.  According to this survey, most of the people served by your projects want you to work together…
Survey results

Screen Shot 2014-07-24 at 08.38.37 am


​​​

I answered several common arguments people make in favor of continuing the competition.  If you can find any holes in the logic, I welcome you to add comments where appropriate…
arguments
​​
You may have seen this one before.  It is a pie chart to show how I have divided the importance I personally give to each of the different categories of benefits.  Importance weights are subjective and determine the scores by combining with the objective facts of which starters in fact deliver which benefits.  Each application generator or seed could claim to be the best one only by increasing the importance of its strengths and decreasing the importance of its weaknesses.  More than anything, this graph lays bare the simple fact that trade-offs and importance appraisals are really hard to make and would be entirely unnecessary if there were only one project and everyone worked together on it.
 pie

You may have seen this one before too.  It’s a matrix that displays the weighted trade-offs between pairs of projects.  It expresses the level of difficulty in choosing between alternatives.  For the top ones, I also created separate spreadsheets for the same information that’s a little easier to read.  Just click the button
​ in the lower left corner to easily navigate through them…
 1on1


I added this section to show which starters are strongest (green) and weakest (red) in each category.  This might help make it a little easier to locate errors or omissions in my fact collection if you find your project to be other than the spreadsheet represents it.  I hope that rather than taking this as a guide to the areas in which your project needs to catch up to the others, you see it as a guide to how responsibilities might be assigned once folks decide to work together…
 bests




Finally, I added a new matrix to show the potential value if pairs of projects joined forces and combined their distinct benefits.  These are the potential gains of just two projects working together.  Imagine what could happen if they all did…

 combos

All of this should speak pretty well for itself.  The competition between your projects just doesn’t make any sense to me and comes at a terrible cost of duplicated efforts, wasted learn time, sacrificed functionality and untaken potential strides in progress.  The value of solving this problem by encouraging you talented and benevolent people to talk to each other and come to agreements is worth to me whatever time it takes.
Please let me know if you would be willing to have a serious discussion about this with each other.  And thank you! thank you! thank you! for your generous contributions to open-source software.
Best regards,
Dan