
Opinionated Comparison of React, Angular2, and Aurelia - stickfigure
https://github.com/stickfigure/blog/wiki/Opinionated-Comparison-of-React%2C-Angular2%2C-and-Aurelia
======
WA
I've spend a lot of time evaluating Angular + Ionic, Vue and React. My goal is
to rewrite my webapp as a SPA with complimentary mobile apps. Maximum code
sharing would be nice. I'd like to add to the discussion what I learned and
also add Vue for comparison.

Vue felt less intimidating at first, whereas React seemed to be overly
complicated. Truth is, both are actually quite similar. The problem is that
every single tutorial out there tells you: "React is only the V in MVC" (and
so is Vue) but then goes ahead and implements all business logic in
Components. I found it incredibly hard to learn about a sane (SPA?) software
architecture. Some people throw in Redux and Vuex, but they actually only
manage the state of the application. This is not where business logic goes.

Note: I haven't found a proper solution yet. Or let's call it this way: People
dump their business logic in components and Redux and that works just fine to
some degree, but they actually treat React more than the V in MVC. Just be
aware.

React isn't that complicated, especially if you start out with functional
stateless components, i. e. Components that only have a render function, props
and no internal state. This helps to think about where state and logic should
go and once you implement your first React components this way, you see that
there's hardly any difference between Vue and React. Vue might let you even
produce code that is more ugly than what you'd have produced with stateless
components in React.

The beauty of React is that it forces you to think in a slightly different
way. Vue seemed more accessible for a spaghetti code writer like I was (am?),
but it wouldn't really challenge me in the same way like React does. Vue made
me understand what _reactive_ is all about, React helped me to think about
_state_ more clearly, especially if you want to slowly transition to
functional programming.

Angular is often seen as a full application framework – and to some degree,
that's true. But I suspect you'd gain a lot if you actually wrote your core
application / business logic as if it wasn't part of Angular to make it more
shareable. For example, if you want to go mobile with Angular, you could use
Ionic, but it's not 100% compatible both ways and you must think of a way to
structure your app so that certain parts (the model) is actually independent
from the framework.

You could treat Angular more as a View-layer thing, which simply attaches a
bunch of observers to your app state, which reduces the need for many APIs
Angular offers and also reduces its complexity.

The OP wrote about dependency injection, which I found odd as a comparison
metric. DI is a design pattern to solve a specific problem and React/Vue
simply don't apply to this design pattern.

The main advantage of React over Vue and Angular is: React Native. Vue doesn't
have anything close to it. Weex might be there one day, but right now, the
docs are very incomplete, half in Chinese and I think it lacks a lot of
components React Native already has. With Angular, the logical framework to
build hybrid apps would be Ionic. Ionic is nice for specific cases: When your
app is read-only!

This isn't about performance (it's solid on newer devices) – it's forms and
input controls. This is where Ionic shows the ugly side of the underlying
Webview: Mobile Safari simply sucks for things beyond a simple input field.
Want to show a picker for the date that only shows 15 minute intervals? Good
luck with that. An input field that allows decimal only? Your best bet is
_type=tel_ and neglect the decimal point separator. Or use the rather un-
performant and ugly DatePicker that comes with Ionic.

But this is a thing where even average users notice a difference to native
input controls. If your app is mostly read-only with nothing more than a
button and a toggle as input controls, by all means, go with Ionic. Have a
form in it? Make a minimal prototype with just this form and see for yourself
how it plays out.

React is _learn once, write everywhere_ , because you can't really share any
component-related code between React and React Native. In React, you use HTML
elements, in React Native, you use native elements.

~~~
indexerror
> The beauty of React is that it forces you to think in a slightly different
> way. Vue seemed more accessible for a spaghetti code writer

This has been my experience too with React and Vuejs. React requires thorough
planning beforehand to write good code. You need to plan the parent-children
structure before you jump in. It's easy to write shitty code in react too if
you jump in headfirst; resulting in the kind of "enterprise boilerplate"
others are talking about in this thread. Personally, I am happy with React at
the moment (and React Fiber let's you return an array of components, so no
more wrapping your components around a span - yay!).

~~~
jhoffner
I haven't tried React but I felt the complete opposite with Vue. I've never
written more beautiful front-end code than what I've done in Vue. Did you use
.vue files? Did you use a proper state tree like Vuex?

------
searchhn
> There are a few more frameworks I would have loved to try, including Polymer
> and Vue.js. There just wasn't enough time to do a deep dive with all of
> them.

I hope he gives Vuejs a try. As a javascript beginner, who tried Angular,
Angular2, A bit of React and VueJS, I just loved the flexibility and approach
of VueJS. I was instantly productive thanks to the amazing documentation and
vue-cli that just worked out of the box setting up my project.

PS: Never really spent much time on React as I tried it after VueJS and did
not feel like proceeding much further with my tests.

~~~
jondubois
I wish the author had tried Polymer because it's the most underrated one. I
just love the way Polymer components declare/consume dependencies (as tags in
the component file) and connect all sub-components in the template markup via
attributes - It makes data binding relationships between components and their
children very clear.

Polymer is basically an inverted version of React (and it achieves a similar
outcome). In React, template markup is nested inside the code. In Polymer,
code is nested inside the template markup.

I really like React but I wouldn't use it for a personal project knowing that
Polymer exists. I hope Polymer will gain more traction because I would love to
be able to use it professionally.

~~~
ergo14
Polymer traction is looking good, over 7k people on slack channel, 750
elements on webcomponents.org. And they got first day on google IO this year,
youtube main site is being rewritten in it, ING, IBM, GE are using it, so it
gets quite a bit of love from enterprise too.

~~~
jondubois
I feel more comfortable using technologies that have had moderate, steady
growth in popularity over many years like Polymer than technologies which
experienced sudden, explosive growth like Angular 1 (we know how that turned
out).

Early explosive growth means that the technology is hype-driven; adopters
haven't given themselves the time to critically and objectively evaluate the
solution - It's not so different from economic bubbles. People get excited and
buy into it without thinking and then at some point in the future when they
realise that it won't live up to their expectations they all start selling at
the same time.

------
stymaar
> And the React ecosystem tends to either lack typings or provide poor/broken
> typings.

React integrates really well with flow[1] (which is not surprising because
they're both developed at Facebook) and in my experience flow's typesystem is
more powerful (OCaml inspired) than TypeScript one (C# inspired):

\- non-nullable types by default is a big deal (they added support for non-
nullable types in TypeScript 2, but enabling it with `--strictNullChecks` is a
breaking change, so I don't think many users have done the switch).

\- the type checker is sometimes not strict enough to be sound [2].

[1] : [https://flowtype.org](https://flowtype.org)

[2] : [http://djcordhose.github.io/flow-vs-
typescript/2016_hhjs.htm...](http://djcordhose.github.io/flow-vs-
typescript/2016_hhjs.html#/21)

~~~
voidr
> React integrates really well with flow[1] (which is not surprising because
> they're both developed at Facebook)

It can integrate just as well with TypeScript.

> flow's typesystem is more powerful (OCaml inspired)

It lacks access control for class properties/methods, I wouldn't call that
powerful.
[https://flow.org/en/docs/types/classes/](https://flow.org/en/docs/types/classes/)

~~~
stymaar
> It lacks access control for class properties/methods, I wouldn't call that
> powerful.

You mean `private` and such ? Well JavaScript don't support taht either yet,
and flow is a type-system for JavaScript, it's not a new language on its own.

About the «powerful» word: Flow has had an algebraic data type (ADT) from the
beginning, the kind of type system you'd find in functional programming
languages, whereas TypeScript has and Object-Oriented type-system (à la Java
or C#). ADT are usually considered «more powerful» since it offers more ways
to write logical invariants in your code. The recent versions of TypeScript
tries to retro-fit some features of ADTs into it, like non-nullable types or
sum types, but it's a bit hacky IHMO[1].

[1]: [https://www.typescriptlang.org/docs/handbook/advanced-
types....](https://www.typescriptlang.org/docs/handbook/advanced-
types.html#discriminated-unions)

~~~
addicted
Typescript has had Discriminated Unions as long as I can remember (pre 1.0).
Why do you think they've been hacked in?

------
daliwali
The ending is what makes this article:

>Overall, I'm not 100% sure I made the right choice, but I only have to live
with it for two years.

People are great at short term thinking, and tend to be terrible at long term
thinking. Just some anecdata: I had a look at some source code for a 10+ year
old web app before JS libraries were popular. I could understand perfectly how
a click on a link resulted in a URL hash change and how the hash change
resulted in updates on the page. Nowadays it would be written off as coding
your own framework since web developers can't be trusted to code without a
framework anymore. But it worked with the least amount of indirection possible
and it was simple to understand 10 years later. Web apps today just get
rewritten every two years.

~~~
tannhaeuser
Don't worry, the simpleness and adequateness of plain old JavaScript (+ maybe
jquery) and basic web techniques is re-discovered like every 5 years. Right
now, we're at the height of the React hype cycle which just means we're
approaching its imminent downfall due to generational forces (though I still
do like some aspects of React specifically).

Sorry to sound defaitist, but like you say, the goal of React (and AngularJS,
vue, ...) is to simplify web frontend development and improve maintainability.
But these cost benefits are offset by their (absurd, IMHO, for most use cases)
upfront complexity and thus can't possibly be attained within two years. Also,
the desire to work in an agile fashion where everybody should be able to do
everything (back- and front-end work) works against expert/thermonuclear
front-end development tools.

~~~
YCode
A critical point about these types of frameworks it that their benefits wont
necessarily outweigh the complexity they bring to every project, and
specifically they are likely to be needlessly complex in smaller projects.

In larger or long-term projects though the ability to use formal conventions
to break down an app into components that have solid documentation already
written on how to do this or that in a way that will scale and extend is quite
valuable.

Additionally being able to reach out to a large community of developers who
use similar conventions and plugins is quite valuable for troubleshooting
those 10%/90% problems or finding a drag-n-drop solution that's compatible
with your stack.

------
anjc
It just shows how fast the web moves (or how old I am) that someone can write
"Then the Web happened...pages were giant jumbled messes of template and
jQuery."

There were plenty of new paradigms and new headaches before the JQuery era!

~~~
stickfigure
OP here. My first draft of the intro was a long-winded history that went all
the way back to Win16 thunking. It was too long and detracted from the point
of the article, so I cut it down.

~~~
acemarke
I'd actually like to see that history as another post, then :) Last fall I did
a presentation called "The (R)Evolution of Web Dev", which covered a brief
history of web dev technologies and gave an overview of modern web dev tech
and trends: [http://blog.isquaredsoftware.com/2016/10/presentation-
modern...](http://blog.isquaredsoftware.com/2016/10/presentation-modern-web-
dev-overview/) . I also ran across a couple similar presentations recently:
[http://www.bcssouthwest.org.uk/presentations/MikeEvans2016.p...](http://www.bcssouthwest.org.uk/presentations/MikeEvans2016.pdf)
and [https://hackernoon.com/modern-web-development-
bf0b2ef0e22e](https://hackernoon.com/modern-web-development-bf0b2ef0e22e) .

Anyway, excellent post. I'm actually a Redux maintainer, and spend a lot of
time answering questions about use of React and Redux. I'd be happy to chat
with you sometime about any React+Redux-related topics or questions you might
have. I'm @acemarke on Twitter, and also in the Reactiflux chat channels at
[https://www.reactiflux.com](https://www.reactiflux.com) .

------
SebastianM
> Angular's routing seems to involve "one big routing config".

That's wrong. You can split the routing configuration just like in react-
router or Aurelia. It also supports lazy loading of child routes and
components. So you don't have one giant application to serve at bootup time.
It is also documented really well:
[https://angular.io/docs/ts/latest/guide/ngmodule.html#!#lazy...](https://angular.io/docs/ts/latest/guide/ngmodule.html#!#lazy-
load)

~~~
sjclemmy
I was re-structuring the routing in an Angular 2 app yesterday and I came to
the same conclusion as the author. I think the documentation in the routing
section doesn't go into enough detail about how to configure the modules for
the desired encapsulation. The documentation you've posted is what is required
- but it's in module not routing. It's hard to find.

~~~
robwormald
Angular core team here, we're restructuring some of our docs at the moment and
this is super useful feedback. Thanks!

------
Raphmedia
I really like Aurelia so far. It offers me a lot of tools as a developer to
develop projects my own way.

It feels like working with raw ES6 with a small but powerful library on top.
Anyone good Javascript developer can pick it up in a matter of a few hours
which makes onboarding very easy.

It is still young and small when comparing it to its big brothers but you
should try it anyway. It's really a joy to work with.

I keep reading about how there is no community but that isn't true at all. The
Gitter chat is very active and you can get an answer there in a matter of
minutes.

\----

My answer to the article's conclusion:

"My team is small and doesn't have a professional web designer; I need other
people's components."

\- In my experience using other people's components is often the weakness in
big projects. You end up spending more time customizing them to your need than
it would have taken building them yourself using the project's specification.
That being said, yes, you do need either a full-stack or a front-end dev. for
that.

"I also hit too many stumbling blocks building out my spike, requiring hours
of painful research."

\- The building system is very simple and looks like the ones I do myself but
bigger. You can choose between Webpack and JSPM. You can even use their very
simple CLI if you are not used to front-end build systems.

"I never did succeed at getting a dialog to open, show a progress bar, and
close programmatically."

\- ... Really? That's the basic tutorial on their website. Was an attempt even
tried?

~~~
stickfigure
_That 's the basic tutorial on their website._

No it isn't. The basic tutorial raises a dialog with a close button that the
user clicks.

Try raising the dialog, advancing a progress bar, and closing the dialog - all
without user interaction. Eg, you're showing progress for an activity that
should block out all interaction. It just doesn't work.

~~~
Raphmedia
The search grid that I have built using Aurelia does that.

It's been a while so I don't have the exact code in my head. I simply modified
the progress bar of the tutorial so that I can pass a parameters that make it
so nothing can be clicked if it is set to "true" and also binds the "disabled"
parameter of the buttons in the dialog.

I don't want to be "that guy" but how is any of this hard? Everything is open
source, you can modify everything to your requirements and build the parts
that don't exist.

------
vazhifarer
This kind of comparison is meaningless. Compare React to Veu.js, as these are
both view renderers, not full MV* frameworks. And compare Angular2 to Ember
(with Fastboot), both of which are opinionated MV* frameworks. Not sure why
this is on the front page

~~~
awjr
I found it interesting and he specifically pulled in react-router to get the
balance needed for the comparison to be valid.

~~~
SebastianM
When your application is just some views plus some routing - then that would
be a fair comparison. But in most real world situations (SPA) it's much more:
Form validation, Data Fetching, Unit Testing, Component styling, Translations,
Modularization, ...

~~~
pluma
Obviously therefore nobody writes real world SPAs with React.

/s

------
sjclemmy
This article is spot on. I've been building Angular 2 and React (Native) apps
over the last 3 months and I have broadly similar conclusions. Once React
clicked, it really is very easy to reason about.

With regard to the DI problem, I created a combination of static classes for
things like the User object and function collections with observables for app
state. I didn't use Redux. You can get similar behaviour with Observable
zip/scan/reduce and it's much more lightweight.

------
platz
> Save the global components off as global variables and just use them ...
> When my ActivityIndicator component mounts, it saves itself off to a global.
> Any code can import busy and run busy.start() and busy.stop().

What is the story that FP folks need to tell here, so that people don't do
things like this?

~~~
richthegeek
Nothing. We know it's messy, but React doesn't really provide a better way of
doing this.

Context is barely mentioned in the docs, "not recommended" by the devs. Redux
is incredibly verbose and overcomplicated. Passing "global" things down in
props is just madness (if everything needs it).

Personally I use context, or a singleton (which is just a hidden global
really). It's naughty, but usually required for one or two things per
application.

FP folks aren't sages hiding in caves who we all wait to come down from the
mountains once a year with their crusty wisdom...

~~~
ctvo
Passing data via props has never been a problem for me. It's explicit, the
chain of dependencies explicit, the data flows in one direction, and
components can still be dumb while letting us push the glue layer all the way
to the top.

No one has ever approached that code and been confused or had issues tracking
down bugs in my experience.

I agree it's ugly. I've found it triggers the same sense in a lot of
developers that make them over-abstract code to achieve DRY at the expense of
simplicity (this is just an observation, I don't have an opinion on if it's
good or bad!).

------
cjCamel
Aurelia is componentised, so you can use React as the view engine which (in
theory) would give you the benefits of React alongside decent routing and DI
(which can also be swapped out).

One other thing that Aurelia is good about is not requiring a lot of DSL. The
maintainers aren't interested in developer lock in or mindshare like Facebook
and Google, so the code you write is more portable than with React or Angular
- it's a shame the author didn't make more of this.

Additionally the maintainers provide guarantees that they won't pull the
projects, which Facebook and Google do not.

That said, it's hard to argue that the ecosystem around React+Redux and
Angular makes it very hard for the smaller players to get a look in for all
sorts of reasons.

------
SebastianM
Comparing plain React with Angular and Aurelia is completely useless. You
cannot write a big serious application with Form Validation, Data Fetching,
Testing, etc, just with React itself. A fair comparison would be to write a
whole "real world" project and then see what parts you have to use and learn
to be able to write a full React application.

~~~
pluma
Author didn't compare "plain React". Author compared React with React Router
(and possibly Redux/whatever for state).

Did you only read the part about the documentation?

~~~
cmdkeen
I doubt the author was using Redux if he was praising React and Typescript...

~~~
joshuacc
Why? I've used Redux and TypeScript together before. They make a really nice
combination.

------
porker
I'm working on my first Angular2 app (inside Ionic 2) and have not been overly
impressed. Most (all) of these will be first-project-pain but I'll list them
anyway:

* The massive coupling in app.module.ts and app.component.ts

* Coming as a backend dev, the coupling of services to the view layer

* Terminology of service/provider, and the general standard of documentation (3rd parties are far better than the official docs)

* Having a definite 'Angular way' of doing things, but not documenting it explicitly

And new to a modern JS project:

* Observables need a mindshift,and I'm still adjusting * Keeping clean separation between layers. Subscribing to events to update viewmodel attributes helps, but I feel I'm lacking separation and over-coupling

Of the example code samples I've adapted, I've found the Aurelia community to
be consistently high quality and well thought through, which can't be said for
Angular.

~~~
ssijak
"* Having a definite 'Angular way' of doing things, but not documenting it
explicitly"

Here you go [https://angular.io/docs/ts/latest/guide/style-
guide.html](https://angular.io/docs/ts/latest/guide/style-guide.html)

------
ferto
I know yet another Framework but a lot of your issues I think are solved with
Vuejs as they provide a quite mature and well documented component library
which is using Streams (under the hood) and their single-file approach solves
a lot of issues ([https://vuejs.org/v2/guide/single-file-
components.html](https://vuejs.org/v2/guide/single-file-components.html)).

additionally, they provide their own router, redux implementation which are
all working very well with the components.

I think Vuejs has some great approaches which makes it easy especially for
people who want to use new frontend stuff but not with the complexity and
technical depth Angular2, React and others introduce.

------
cmdkeen
/me Quietly goes back to using Knockout and Typescript to happily pootle along
building apps without worrying about routing, SPAs and other added complexity.

Simplicity brings its own rewards.

~~~
lpa22
In my experience, this initial added complexity and learning curve results in
significantly higher productivity once a comfortable knowledge level is
obtained. I can't imagine going back to Knockout and I truly believe I can
develop 2x with React and it's ecosystem.

------
knowThySelfx
Been using Vuejs for a couple of months now. Just love it's simplicity and
flexibility. Tried Angular 2 earlier. It was ok. But they've lost it with
their new release cycle. I guess people will hesitate to use it.

Needed a routing solution where we had to load list-> multiple
details(multiple tabs from a list of items; loaded using ajax/websockets) not
single detail view. Not sure either Angular or Vue's router could do it. So we
ended up implementing a custom one.

~~~
robwormald
FWIW, Angular's release cycle is roughly based on the same cadence as React :)

~~~
knowThySelfx
:) Wasn't aware of that. Haven't tried React. Maybe because I am a bit
impatient.

------
fraserharris
My key to success with react-router was to use context and redux to get props
to the routed components. Sub-components from there can accept props directly.
After a while it feels natural - any necessary information is stored in the
store.

~~~
BigJono
This is an anti-pattern unless you actually have shared state between pages.
Otherwise it's functionally no different to just having local state on each
page and all you have is lots of unnecessary boilerplate.

This is way more common than I realised before I started working in teams.
Each page does it's own API calls to the server (either directly, or more
commonly through some sort of horrible misuse of redux-thunk), stores the data
in it's own little section of the redux store, and then receives the exact
same data back as props :/

~~~
fraserharris
In general, you only need react-router if you have multiple pages with some
kind of shared state (ie: a dashboard).

I do know exactly what you are talking about. We do have some single pages
that implement the boiler plate just so that they are consistent with the
others.

------
Matthias247
Regarding the Angular DI part: You don't need "provides" anymore on each
component, afaik it's even deprecated. You just need to define it once on the
module that defines the DI providers. And in the module of the component
import that module. But your findings may already have been from some time ago
where things were different in Angular land. That's for me the saddest story
of Angular 2: Between alpha, beta, RC and final release dozens of things
changed, which required me to constantly change my app. Now that it's stable
I'm quite sophisticated with it.

~~~
SebastianM
> afaik it's even deprecated.

No, it's not. You use providers on a component when you want to have a new
instance of that Service when a new Component instance of that type gets
created. So you have complete control over the DI. More details here:
[https://angular.io/docs/ts/latest/guide/dependency-
injection...](https://angular.io/docs/ts/latest/guide/dependency-
injection.html#!#injector-config)

------
pluma
I swear "React is just a library, not a framework" is the new "JavaScript is
just a scripting language, not a programming language". The comments in this
thread are a great example of this.

~~~
gbog
Well for me React being just a library is the very reason to use it.
Frameworks are constraining, you code "inside" them and can't get out.
Libraries are giving more freedom, you code "along" them. For example, I was
really hating react-router and wrote my own, with proper state and url
injection, in one or two sessions. I guess it would have been much harder if I
was "inside" a framework.

------
makkesk8
I like the conclusion and it's a fair comparison. I, however, can't stand
react with reasons I don't want to get into.

But I would kill to see a middle ground between react and angular.

------
Kiro
I would love to hear how people solve the snackbar problem in React. I don't
even see how you would solve it with redux since that's just the state.

~~~
Sacho
The snackbar problem is actually what redux is built to solve. You would
"provide the toast()" function by having components dispatch a "toast" action.
From there, your reducer would modify the snackbar state accordingly, e.g. by
implementing a stack of toasts, and you would have a single global component
render that state into popups.

~~~
acemarke
Yeah. There's a dozen existing "notifications with Redux" libs already:
[https://github.com/markerikson/redux-ecosystem-
links/blob/ma...](https://github.com/markerikson/redux-ecosystem-
links/blob/master/widgets.md#notifications) .

Behavior-wise, it basically just amounts to a pair of SHOW and CLOSE actions,
possibly with the reducer tracking an array of open notification entries, and
a component that maps over the array and shows an actual notification entry. I
glanced at the ones in my list, saw the similarities, and just wrote my own.

------
mi100hael
_> React-router has gone through a lot of version churn. I used the (at the
time) still-in-beta v4 router. This is good because it's clearly a better
solution than prior versions. It's bad because all the tutorials and most of
the online documentation refer to the old versions. Also there were no typings
for v4 (since fixed)._

And to think people complain about GTK changing too frequently...

------
atemerev
React is, of course, a work of a genius. But may I suggest another option in
the same spirit, which is Riot.js? It is more elegant, compact and better
syntactically polished, while retaining React's convenience and performance.

(I had approached React right when the infamous Babel5->Babel6 transition
happened, and was seriously burned by it.)

~~~
JepZ
I am using riot.js too and am pretty happy so far. Actually, I never tried
react, but as riot is smaller, I like the tag syntax much better and I do not
feel like I miss anything, I do not know why I should try it (anybody here
prefers react over riot? why?).

Before riot, I tried Backbone, Ember and Angular. While Backbone did a fine
job it didn't help to structure the app and everything had to be done
manually.

Ember was too opinionated for me. Yes, they have some nice concepts and bring
a lot of functionality right out of the box, but when you still have problems
doing basic stuff after the third project, you know it's time to move on. The
only thing I sometimes miss is ember-data.

Angular looked better to me, but they lost me with the Angular2 migration. I
hate it when libs break backward-compatibility and in my eyes, there were
enough good alternatives so that I did not have to risk facing the same story
again with some future angular version.

The beauty in riot.js is that you can easily build small html components and
stack them together afterward and reuse them later. It really feels like a lib
which you can plug into something else. So I am able to develop an app using
riot.js with framework7 and formatjs at the moment.

------
boriscy
Nice comparison, please try Vuejs I have used angular 1 and react with redux
in the past and Vue for me is so elegant and simple (it's also really fast),
it has the component system of React and the template style of angular and you
can create single file components .vue files that encapsulate html, js and
css.

------
k__
I always hear Angular 2 ppl talk about how awesome it is, because of
TypeScript and RxJS, as if they're the main good things about it.

If you really like these two things, try CycleJS. It's basically "Angular 2
the good parts"

~~~
milesrout
Personally I don't see any appeal in either Typescript or RxJS.

------
all_the_things
"Some of us dynamically generate this for various reasons. You can just copy
the important script tags into your html but it still seems weird and
invasive."

You can use the ng eject command to add the webpack configuration to your
project root and it'll add and print a set of npm commands too.

------
EisenbergEffect
I'm the project lead for Aurelia, so I'd like to take a minute to address a
few of the points from the linked post. Jeff makes some valid points, for
sure. However, there is also some inaccurate information and a healthy dose of
subjectivity.

* Documentation - This one tends to be highly subjective. One's happiness with documentation is often highly dependent on learning style and what you are trying to do "in the moment". Jeff describes it as a "mixed bag". However, we've had plenty of people praise Aurelia's docs as amazing or even make statements such as "this is the way all documentation should be." Do we have room for improvement? Absolutely. In fact, we're working on a completely new documentation site right now. * TypeScript Support - We have a huge community of TypeScript developers who are quite happy with our support for the language. We provide d.ts files for everything. We also have a number of our libraries that are now completely written in TypeScript. This includes our new Webpack tooling, our Validation library, our UX Component library and more. We've actually worked directly with the TypeScript team to provide scenarios for them, which resulted in new features for TypeScript and submissions to ECMA for future versions of JavaScript. * Build System - Aurelia supports multiple options, including RequireJS, SystemJS, Dojo and Webpack. We have a very diversified community. Our CLI is designed for beginners who either are completely new to SPA frameworks or don't know how to use tools like Webpack. It's designed to get them up and running quickly and easily. It has been exteremely successful in that area and we've received a ton of praise for it. If you are a Webpack developer, I would expect you to use a Webpack setup instead though. We have a Skeleton for Webpack that's based on Webpack 1.x. However, we've got a completely new set of Webpack 2.x tooling. There have been blog posts about it, there's documentation, dedicated plugins, etc. It sounds like Jeff missed this somehow. Lots of people are using it though and loving it. We're doing some work now to broaden the availability of our new Webpack setup, so hopefully future devs won't have the same discovery problem that Jeff did. * Dependency Injection - This one is is pretty accurate. Our DI is extremely powerful and extensible, but we try to stay out of your way as much as possible. You can even use DI without decorators at all, in a pure ES2015 fashion, if you like. * Component Encapsulation - Here Jeff doesn't talk about the component model at all really. He's fixated on whether or not you can put a component in one file, something that tends to be a subjective requirement. That would be fine but he missed the point that you can include your JS and HTML in the same file with Aurelia as well, by using our @inlineView decorator. We've supported this for two years, but maybe we need to talk about it more. That said, we generally don't recommend this as the default practice, because we hold the opinion that it's better for developer/designer collaboration, parallel work, and sometimes even source control, if you put these things in seperate files. If you want to do it, you can though. The Aurelia strategy is to have a lite set of opinions but to always enable developers, which is why we support both paths. One other quick point here: Jeff calls out our component naming as "magic". However, our documentation very clearly points out that, if you don't provide an explicit component name, the convention is to use the export name. This is a fundamental convention in Aurelia that is well-documented. * Routing and Fetching - Here Jeff has a couple of questions about getting access to parameters in sub components and altering the way that routes generate titles. Those are all possible and would have been a good opportunity for Jeff to engage with our very helpful community. Jeff makes one cricirtism that is very valid though. Our documentation on routing is lacking in some big areas. I don't think there's any doubt about that. It's something we're working to remedy. Perhaps this is the central reason why he thinks Aurelia's docs are a "mixed bag"? * Ecosystem - This point really frustrated me. Our community is not tiny. There are tens of thousands of companies using Aurelia all over the world. There are tons of very large, well-known brands using Aurelia. Unfortunately, we can't share these names all the time. Please understand that Google and Facebook have considerable influence over other companies that we do not have. For example, if company X uses Angular or React, they want Google/Facebook to publish that information because the Google/Facebook brand is likely bigger than theirs and they want to ride on the coat tails of the larger, more influencial company. In our case, Aurelia as a project, is almost always smaller than the dozens of Fortunate 500 companies that are using it. So, they don't have any motiviation to share that information. Because the bureaucratic legal and marketing hoops are so numerous, we end up not being able to share many things publicly. * Ecosystem Part 2 - We have tons of 3rd party modules for Aurelia. Jeff states that there are no third-party component libraries for Aurelia. That's not correct. We've had public announcements about Telerik and Syncfusion component libraries. There's also a Materialize component library and at least one very large community-based component library in addition to the collection of individual components that people have built. Aurelia itself has an official component library. It's early, for that library, true. One thing I take away from this is that we need to focus on and "highlight" even more in our official docs and site these 3rd party components, because maybe people just don't know that they exist.

Now, we realize that Aurelia is far from perfect and that we always have
plenty of work to do and things to improve on. I and my team of about 30
engineers have poured countless hours, worth millions of engineering dollars
into Aurelia. We don't have the brand power of Google or Facebook. Who does?
So, if you write this type of comparison post, please be careful to validate
the information and maybe even reach out to the project contributors for
feedback. Posts like this can cast all our work in an overly-negative light,
particularly for those who haven't encountered Aurelia before and don't know
better. We're all working for the same thing here and want to help each other
and our businesses succeed. I always take feedback like this to heart and I
and my team will continue to work hard to make Aurelia better every day. We
invite everyone to join our community and contribute together to making
Aurelia the best platform for modern web apps.

~~~
weagle08
Thank you for Aurelia btw... I've used both Angular 2 and Aurelia
professionally now and Aurelia is hands down a better framework and it's ease
of use makes up for lack of documentation (which has improved a lot over the
past few months and SO answers are usually answered pretty quickly). I've not
used React and would like to stay away from it since I find the JSX file to be
a horrid mixing of concerns.

------
krystiangw
Here is interesting comparison of frontend frameworks popularity in job
offers:

[https://jobsquery.it/stats/frontend-
frameworks/group](https://jobsquery.it/stats/frontend-frameworks/group)

------
jug
Urrgh, please stop using "opinionated" as a trendy, positive web development
word. It's not even always certain that it is.

------
ericfr11
first time I hear about Aurelia. I found Angular2 easier to start with, as I
did not have to make decisions about what to use for router, DI, storage. With
React (and React Native), there are many blanks to be filled, and hard to make
a decision: Redux or Mobx?, which router?, who owns the style...

------
edem
What about Polymer? It would be also interesting to see it compared to Angular
and React.

------
andrew_wc_brown
Mithril, Mithril, Mithril

------
stanislavb
And we can compare them on LibHunt by CodeQuality, Popularity & Dev Activity

React VS Angular [https://js.libhunt.com/project/react/vs/angular-
js](https://js.libhunt.com/project/react/vs/angular-js)

React VS Aurelia
[https://js.libhunt.com/project/react/vs/aurelia](https://js.libhunt.com/project/react/vs/aurelia)

Angular VS Aurelia [https://js.libhunt.com/project/angular-
js/vs/aurelia](https://js.libhunt.com/project/angular-js/vs/aurelia)

BONUS Vue.js VS React
[https://js.libhunt.com/project/vue/vs/react](https://js.libhunt.com/project/vue/vs/react)

It seems that Aurelia beats them all by Code Quality...

~~~
acemarke
Rather depends on how they're measuring "code quality". A very brief search
didn't turn up any specific description of their metric.

If it's simply, say, "number of issues", or even something like "average age
of open issues", then an actively used lib like Angular or React is likely to
have "less quality" simply because more people have been using it and filing
issues over time.

~~~
tribby
lumnify describes the criteria[1] but is incredibly vague about it.
unless/until they give detailed reports on each project explaining how they
arrived at their conclusions I think it's fair to treat these grades as pulled
out of thin air. and even then it would be of very little/probably still no
value. every project is different and you need to evaluate your tooling based
on the situation.

1\. [https://lumnify.com/grades/](https://lumnify.com/grades/)

~~~
stanislavb
They are not pulled out of thin air. You should contact them, and they will
come with an answer. The algorithms have been tuned based on feedback from a
number of Start Ups in Sydney.

~~~
tribby
they can open-source their methods/algorithms for public review if they want
anyone to take their scores seriously.

