
Why we moved from Angular 2 to Vue.js and why we didn’t choose React - chillax
https://medium.com/reverdev/why-we-moved-from-angular-2-to-vue-js-and-why-we-didnt-choose-react-ef807d9f4163
======
erokar
> With Typescript things that were really easy to do on Javascript like
> defining a simple object were more complicated to do on Typescript.

TypeScript in no way prohibits you from defining a plain old untyped object.
Just don't assign a type to it, and it behaves just as it would in plain JS. I
wouldn't use Angular 2/4 either, because of its needless complexity and over
engineering — but not because of TypeScript. If anything, TypeScript is a
bonus.

> React mixes both JSX/HTML with JS code which I just don’t like since I
> strongly believe in separation of concerns and it looks ugly IMHO.

This is valid only if you think separation of concerns is the same as
separation of technologies. I don't think so. It makes more sense to group
code based on function.

In fact Vue.js allows single file components that mix HTML, CSS and JS in a
way that would violate the author's definition of separation of concern. From
Vue.js' documentation: "One important thing to note is that separation of
concerns is not equal to separation of file types." [1]

> Coding speed was an area Vue.js won by far, not having to learn JSX was of
> huge help.

It should take no more than 20 minutes to learn JSX.

1\. [https://vuejs.org/v2/guide/single-file-
components.html#What-...](https://vuejs.org/v2/guide/single-file-
components.html#What-About-Separation-of-Concerns)

~~~
che_shirecat
> It should take no more than 20 minutes to learn JSX.

it should, but in practicality, for most front-end devs especially junior
ones, it's not. Moving Angular 1 devs to Vue gets actual work going 3-4 times
(anecdotal experience) quicker than with React. For most smaller
shops/startups Vue is almost always a better idea - it's much easier finding
devs (especially remote/<100k comp ones) with previous Angular 1 experience
and the learning curve is alot nicer. React is overengineering for most web
apps.

~~~
christophilus
If you know only JS, JSX is _much_ easier to pick up than some proprietary
templating language. How do I do an if, a loop, a map, ... any code at all? In
JSX, the answer is squiggly-brackets and regular old JS code. In Angular's
templating system and Vue's, you've got to relearn all of these and more.

~~~
rocky1138
> proprietary templating language

Isn't that exactly what JSX is?

~~~
jsd1982
No. JSX is a small domain-specific language for expressing a hierarchy of
virtual DOM nodes. Angular is a template language in that it eschews
JavaScript compatibility in favor of its own directives that try to emulate
basic iteration and conditional expression evaluation.

~~~
davidjnelson
I wish you could write non string based jsx in angular. Or at least make aot
fast enough for the regular webpack watch / recompile workflow.

------
jinder
"We invested in a beta product and then shock horror - it changes before it's
released. Let's blame the framework on that poor choice."

"We were unable to learn how to use TypeScript properly, so let's abandon
gradual typing and suffer a net loss in productivity over the longer term."

~~~
camus2
> "We invested in a beta product and then shock horror - it changes before
> it's released. Let's blame the framework on that poor choice."

Angular.2 has been in beta for years. And when it went out of beta it
basically became something else. This is not a good thing. It's normal for
teams to be excepting at least some level of stability in the library they are
using. And now that Angular.X pretends to be using semver, it's going to be
even worse.

The Angular team doesn't care about stability or lacked vision when they
started 2, but a stable API is a valid expectation for a developer team.

But it's not surprising as frameworks with huge API surfaces like ExtJS have
pulled the same trick for years, with the same results. Their downfall is more
the consequence of API breaking than anything else.

~~~
jinder
If you rely on a beta product you should have no expectation of API stability.

It's very easy to blame vendors when it's your own poor decision making that
got you in the mess to begin with.

~~~
camus2
> If you rely on a beta product you should have no expectation of API
> stability.

If i rely on a beta product, i don't expect a complete rewrite of the API when
a stable version is released. That's exactly what happened, several times with
Angular. Now you can't have it both ways as a vendor. You can't expect people
to try out your product and test it in a professional setting then change
everything at the last moment either. Or you're saying developers shouldn't
even checkout Angular until it is out of beta. If that's what you're saying
then the vendor shouldn't expect broad adoption.

~~~
thehardsphere
I don't know what he's saying, but I would say that you should not have your
product depend on something that is subject to change. Thus, although the
vendor can do wrong by changing their product API when it is in Beta, it's
still ultimately your fault for relying on something that hasn't had a stable
release.

Although I get what people are saying about Beta products, the truth is that
different vendors use the term "Beta" with different levels of precision, and
thus should not typically be trusted not to pull the rug out from under you in
some way if they haven't firmly committed to stability.

------
ArchReaper
Maybe my viewpoint is too 'elitist' or something, but I have a hard time
taking this seriously when one of the chief complaints of Typescript is that
it is too "difficult"

It really makes me question the validity of the rest of the points.

~~~
jcroll
Yeah was interested to hear what their points would be but couldn't get past
when they started complaining about typescript.

------
seanwilson
> I didn’t feel Typescript added substantial value and even worse, we noticed
> that our coding speed was reduced. With Typescript things that were really
> easy to do on Javascript like defining a simple object were more complicated
> to do on Typescript. I highly recommend you to read the following articles
> before you start using Typescript. It is not the right solution for
> everyone.

If you read the linked article, it's using a graph of the number of GitHub
issues labelled "bug" to justify that languages with strong static types don't
reduce the number of bugs which isn't meaningful or convincing...

> The main thing we didn’t like and we still don’t like about Angular 2 is
> Typescript. I know Angular 2 can be used with Javascript but again, the
> decision to use Typescript was already taken and from what I understand,
> using pure Javascript with Angular 2 is not the ideal way you should be
> using Angular 2. In any case, getting rid of Typescript meant a full rewrite
> of the project. ... > I still remember how easy to work with Angular 1 was,
> it certainly had it’s own problems, but it was nice to work with it compared
> to other frameworks, something that Angular 2 lost somewhere on the way.

I recently moved from Angular 1 because it didn't work well with TypeScript.
The rest of my project was in TypeScript and all the bugs were coming from the
Angular 1 layer because there was no static checking there.

TypeScript is an enormous improvement over plain JavaScript in my opinion in
terms of productivity (better refactoring, better autocomplete) and making
your code more robust (no unexpected null/undefined variables, no more mixing
up strings and arrays). Ignoring TypeScript for large projects is a big
mistake.

Angular 2 felt too verbose and overly complex so I switched to Vue which has
decent add ons to work with TypeScript. If you use JSX for Vue templates as
well, you get type checking for your templates.

------
dugmartin
> With Typescript things that were really easy to do on Javascript like
> defining a simple object were more complicated to do on Typescript.

Sure defining a simple JS object has no overhead as opposed to _maybe_ the
15-30 seconds of overhead that creating the Typescript interface entails. But
that few additional seconds of overhead gives you this for rest of the (weeks,
months and years) of the systems lifetime:

    
    
      1. Instant IDE/editor code completion and error checking
      2. Compile time checked contracts when that object is passed to another function
      3. Compile time checks for misspelled or non-existent members of the object.
      4. Instant refactoring of member names across files with any number of editors and IDEs
      5. A chance to take a little higher level look at the design of your system.
    

After using Typescript for a couple of years now I've found that when I design
my types well the overall design and flow of the system tends towards beauty.
That is probably why the Haskell folks are always over on the sidelines
smirking.

------
jorblumesea
Angular is a application framework, Vue is a view library. It's really
frustrating to see these two compared, because they have different purposes
and intentions.

Vue just renders components. There's no state management, built in routing, or
any of the other things you get for free with Ember/Angular/etc.

By the time you slap all of that on top, you may have well just stuck with
Angular. I noticed in React by the time you added the required add-ons (mobx
or redux, polyfills, react router, styled components) it was extremely heavy.
Furthermore, maintaining these addons, with their own release cycles and bugs
is an additional burden on a team.

~~~
RussianCow
> Vue just renders components. There's no state management, built in routing,
> or any of the other things you get for free with Ember/Angular/etc.

That's not really true anymore; there is now an official router[1] and state
management library[2] for Vue. You don't _have_ to use them, but I think the
comparison is still completely fair.

[1]: [https://github.com/vuejs/vue-router](https://github.com/vuejs/vue-
router)

[2]: [https://github.com/vuejs/vuex](https://github.com/vuejs/vuex)

~~~
jorblumesea
This is a great point, I did not know it was officially in the build. Thanks!

------
rajeshamara
2 flaws with this article. 1) Using a Beta product and complaining on
Angular2. You could have waited till the product is matured 2) Blaming for the
developers inefficiency on Typescript. If your developers coding speed is
reduced blame on your developers. Your title and article appears that
something is wrong with Angular2 and moved to Vue.js. Before you post such
articles make sure what your write makes sense

~~~
ballenf
He cites two articles going into much more detail on the line of thinking
regarding the tradeoff that is static typing. I realize this is one of those
tab/spaces kinds of religious debates, but hopefully all sides can acknowledge
that we are talking tradeoffs and not universal truths. Maybe one day we'll
see loose typing as evil as "goto" statements, but the evidence isn't there
yet. IMO.

~~~
mhd
Goto statements still have their fans, and on the other end of the spectrum
you'll find people arguing that things like multiple return statements and
exceptions are basically the same. It's hard to find absolute truths in
computing. I bet there are a few people who'd like us to ditch that whole
binary kerfuffle, too.

But yeah, they're trying to be productive in the short term, so it's probably
not worth overanalyzing whether a distaste of static typing isn't emblematic
of other issues. Getting things rolling has a higher priority...

~~~
jnbiche
> I bet there are a few people who'd like us to ditch that whole binary
> kerfuffle, too.

[https://en.wikipedia.org/wiki/Setun](https://en.wikipedia.org/wiki/Setun)

Knuth has also hypothesized that we may one day start producing ternary
computers again due to their efficiency and elegance.

------
keymone
everybody who feels so strongly about separation of code from templates - do
you realize that down there it's still just bunch of string concat calls? it's
literally what ERB templates in Ruby compile to, and similarly in literally
every other template language.

rather than focusing on "omg html in my js" you should focus on "omg
presentation code in my business logic code" because that's when you realize
where the real boundary is.

it's one of the reasons i love clojurescript's hiccup so much - i'm still
clearly writing idiomatic clojure code but now the boundary is not some
arbitrary "this file is named .html and this .js", but actual
namespaces/functions, where it's obvious from scope and signature what data my
templates depend on.

~~~
pweissbrod
I got a theory about that. Somewhere along the way our IDEs and code editors
trained us that different languages always belong in different files.
Eventually people saw this as an aesthetically tidy arrangement to strive for.

Mixing bits of different languages "inline" within the same file got a bad rap
despite the fact it was often a sensible approach to organizing common logic
together.

You write html inside js? or sql inside python? omg noob!

Ironically I think our tools have programmed us to think/operate in a specific
fashion that was convenient for IDE .

~~~
emodendroket
My theory is that a lot of us have gone down this road, eventually found the
thing getting unwieldy and difficult to maintain, and swearing never again.

------
pete_b
Angular 2 in beta made bold claims about being 'production ready' which reads
'almost done', it was frustrating just how long it then took to become what I
would consider production ready.

I consider Angular 4 the first release to produce _just about_ acceptable
sized app bundle. On the whole though it's a very ambitious project and I
think it will be increasingly hard to ignore, we've currently no intention of
changing framework.

~~~
stupidcar
I think this had to more to do with internal pressures at Google than the
actual state of the code. They had been working on it for a _long_ time, and,
I think were under some pressure to actually ship something. Angular v4 is
what the first production version should have looked like.

Having just upgraded a large AngularJS v1 project to Angular v4, I'm actually
very happy with where it's ended up. It feels like a very good combination of
power and flexibility. There are still some complex bits, but it feels more
like the complexity is necessary and sanely designed, rather than the
craziness of what AngularJS's directive stuff evolved into.

~~~
growtofill
Would you share some stats about the upgrade? How many LoCs was the codebase
and how many man/hours it took?

~~~
camus2
s/upgrade/rewrite . I don't believe a second there is a reasonable way to
upgrade 1.X from 4.X without rewriting all UI related code.

------
sgt
We moved from Angular 1.3 to Vue.js. Vue came at a right time and I especially
liked its ease of use, similarity to Angular and footprint. The most important
thing to me personally was the speed and the development feedback cycle.

~~~
ergo14
I like Vue, but one thing that worries me is that 99% of commits are being
made by a single person.

~~~
baybal2
I like it, a mirror opposite of extreme "designed by committee" practices of
big co. funded frameworks.

I feel purposefulness of Vue's design. There are no gigatons of features and
behaviors which make you scratch your head and think "why it is there to begin
with" like why Ang2 insists on using observer objects for HTTP responses, or
why Ang1 had a such an extensive buildover around its component zoo to do just
"new mySerice", or reasons for React's component rendering order
peculiarities, or logic behind their choice of syntax.

Vue is very bare bones thing. It provides no reactive layer over complex
object with non-primitive content. Lack of native support for maps or sets
from ES6 is inconvenient a bit, but it is not hard to provide a function
wrapper around any logic that uses them. I usually keep all business logic
outside of Vue's instance and only wire though its inputs and outputs.

What I lack in all common frameworks is the ability to play smoothly with
really complex DOM manipulations, like swapping prototypes of a DOM elements
and mergings. Trying to do something like complex drag and drop logic usually
means doing a lot of "do it within DOM element, or do it within framework's
element" thinking

~~~
ergo14
I'm not talking about the API design, I'm more worried what happens if Evan
dies, or just loses interest in it. Bus factor of 1.

~~~
super-serial
What happened to jQuery when John Resig focused on other things?

I'm actually hoping Vue.js builds everything needed for a Reactive minimalist
framework and then development slows down similar to the speed of jQuery. I
think people are sick of frameworks doing overhauls of their entire codebases
every major version release.

------
jbergens
It's always a bit strange when someone chooses a framework based on how far
they get in a few hours or days of testing. For medium sized or larger
projects it's much more interesting how it will work long term with a large
code base.

I'm not saying that Vue is no good or that it was not a good choice for the
author, but the way he described their process makes me think that they
optimized the wrong thing.

------
Pigo
I've been attempting to learn Angular2 and React, but haven't delved into Vue.
Angular2 is just different, but it makes more sense to me than 1 if you take
the time to learn the concepts. If you go into 2 thinking your 1 skills will
translate, then I get why you'd be frustrated. But I found 1 to be very vague
conceptually, so many different ways to do the same thing that you end up with
many bad implementations. And compared to React, Angular2 is cake imo. There's
so much more materials to draw from, and ui libraries to use, and you have to
import so much in order to do the same things in React. That may allow for
more flexibility, but it makes the learning curve that much more difficult.
I'm still not a fan of Typescript, but it seems important to get familiar with
ES6.

Also angular-cli and create-react-app are both excellent tools that take a lot
of the guess work out of the process, at the very least they show you how to
do things right way and keep up to date with what's important.

~~~
camus2
> Angular2 is cake imo.

Angular.X totally lacks of vision. For years it didn't know what it wanted to
be, pilling up layers of layers of complexity with IoC containers (useless in
a weakly and dynamically typed language such as javascript), Some custom HTML
that even needs its own parser, Rx.JS (which is self sufficient if you use it,
you literally do not need something on top of that). For what result? it's not
faster, snappier in the client, lighter when it comes to the payload, not
easier to learn or to test or to use. You don't need some ajax libs either,
the fetch API already exists. Angular.X is trying to be the "JEE" of the
front-end, except it miss the point of JEE which are a bunch of stable specs,
which Angular isn't.

~~~
pas
The vision is finally having a good UI kit. Components, templates, lazy
loading, isomorphic/universal JS, precompilation, maintainability, code
discoverability, ease of team development, testing, etc.

Angular CLI does the compilation, provides the boilerplate management (no need
for IDE, if you don't want that), provides the language service (for static
checking templates).

Google dogfoods it, they are on the latest rc always. Somehow they can manage
the API changes/breaks. (And so far it wasn't much problem for us either.)

I don't know if rx is now a hard or optional dependency, but at least they
haven't NIH-ed another Observable lib.

------
sailfast
Just wanted to come here and say thanks to the author for writing up your
assessment of their tech stack and the pluses and minuses - it's brave to do
so and it's obviously spurred discussion.

Thanks for sharing some of your learning and having the guts to put it out
there, and congrats on shipping the results.

I have a couple of questions:

1) You had two people working on the project - how do you think it would scale
out to 10? React's componentized / functional nature allows for that pretty
easily which is a consideration for me.

2) Managing JavaScript in templates (html) with Angular 1.x was always weird
because you couldn't necessarily tell if the execution was happening in the
view or the controller. Does Vue make that any easier when it mixes templates
and JS together? I also appreciate knowing that this file is where everything
is contained for X element or function.

3) How are the test harnesses?

------
Zelphyr
The thing I find amusing about posts like these is that they come about once
every 18 months. Just substitute the left framework for last years shiny and
the right for the latest shiny. We developers are nothing if not consistent in
our ability to chase the latest shiny. I do wish more developers would take
the time to master languages instead of learning new frameworks though.

------
wambotron
I still say Mithril ([https://mithril.js.org/](https://mithril.js.org/)) is
where it's at. I am at a company now that uses Angular 4.x and I'm not
impressed with it. IMO, it's a way to make JS seem more like Spring/Java
(especially with Typescript) rather than understand how JS works and use it as
it is.

Not to mention the learning curve even for senior developers. Mithril took me
maybe 30 minutes to understand. The entire source
([https://github.com/MithrilJS/mithril.js](https://github.com/MithrilJS/mithril.js))
is easily read in a few hours. They have multiple committers and an active
gitter chat room for any problems. Plus you can use JSX if you like it that
much. And it has a nice license.

More folks need to try it out.

~~~
seanwilson
Are you not at a disadvantage with it having a smaller community or is there
enough content out there? I like to support new innovations but knowing I can
easily find a prewritten component for Vue or Angular is a big selling point.

~~~
wambotron
I never felt like I had any problems, to be honest. It was so quick and easy
to write things, I never worried. There are a decent amount of plugins out
there on github, though. Give it a shot!

------
kumarvvr
Vue seems to be less taxing on the mind. Compared to React, I feel Vue is more
easy to build with. Just my 2 Cents

~~~
sayurichick
I agree. Having used both on small projects I was able to get started and
finish quicker on Vue.

That being said, I use React more because of the larger community, (easier to
find answers, and components) as well as more jobs for React vs Vue.

Also, Fiber introduces better animation performance, which i'll eventually
use.

~~~
kumarvvr
Things have become easier with create-react-app though.

------
vladimir-y
The article says to me that the team/company had no initial actual need to use
TypeScript as seems author doesn't get a point of its purpose (of course code
writing will be slower on the initial stage as it's not just about writing the
code, but also about defining its structure which gives you the benefits with
the growth of the project) and so a bad decision was initially made.

In my opinion Vue is ok for the one kind of projects, with smaller team,
smaller project lifetime and Angular is ok for other types of projects. React
is alien here, ie not really needed.

------
davidw
No experience with Vue.js or React, but I used Angular 2 recently and I did
not like it much. Too much magic, too much 'do our things our way or woe
betide you'.

------
jordache
The author made some really weak arguments.

In his comparison matrix, why was Reactivity a criteria? Why did Angular score
a "Kind-of"? Reactivity is just another word for the framework's underlying
change detection logic. Obviously all of these frameworks have that. The fact
that he put the term "reactivity" up on a pedestal and rated angular down
tells me the lack of understanding on the author's side

------
jordache
Angular 2+ does require more up front investment. However once you get going,
the framework's convention is pretty seamless and on can create rather
structured, team friendly projects, and iterate functions quickly.

The Angular CLI tool is a must! Without it, the friction to get dive into the
Angular 2+ world is significantly more.

------
joelennon
> At the time we were thinking about Vue.js vs React, we were also considering
> rewriting our mobile app and React Native looked like a really good choice.
> That was a big plus for React since Vue.js didn’t have anything remotely
> stable that resembles what React Native is trying to do, so the possibility
> of reusing code between the web and app clients was a huge plus, but I
> decided that I wasn’t going to consider possibilities that might or might
> not happen. After all, from my experience, with Node.js I reuse a really
> insignificant amount of code between the browser and the server.

The main benefit of using React if you are considering using React Native is
that you and your team won't need to learn another framework in order to build
native mobile apps for iOS and Android - if they know React already, they'll
be up to speed with React Native very quickly.

~~~
dayvid
Alibaba's working on a Vue-based mobile alternative called Weex. It's still in
its infancy, but it's worth checking out:

[https://weex.incubator.apache.org/](https://weex.incubator.apache.org/)
[https://github.com/alibaba/weex](https://github.com/alibaba/weex)

------
ralmidani
Ember user here, looking for a breath of fresh air from the limitations of
Emblem/Handlebars and the endless layers of complex objects.

I am enrolled in Udacity's React Nanodegree, but recently took a closer look
at Vue. It seems to offer everything React does (VDOM, one-way data flow,
centralized state management, support for JSX), but without the patent drama.

I previously took a nuanced approach to Facebook's unfair patent license, and
will probably never need or want to sue them for patent infringement. But Vue
is quite a viable alternative, so I see no reason to reward Facebook's
unwillingness to play fair.

I plan to finish the Nanodegree, but will probably be skipping React and using
Vue for my own real-world projects.

------
zerr
While we are at it - any success stories with Weex? (a la Vue.js native)

~~~
sgt
A few months later: "Try Weact, a Weex alternative."

The speed at which these frameworks pop up is almost exhausting.

~~~
mrighele
My approach for a JS framework or library is that the time I can hope it will
be maintained for is at most the time that it has already been maintained.
This way, depending on how long my project is supposed to be supported I can
make a reasonable choice about what to use. I call it "JS half-life time".

~~~
ameliaquining
There's a name for this in the literature:
[https://en.wikipedia.org/wiki/Lindy_effect](https://en.wikipedia.org/wiki/Lindy_effect)

~~~
mrighele
I didn't know about that, thanks for sharing.

------
OutsmartDan
I just broke your Vue website.

[http://cl.ly/2I2r2S2v171T](http://cl.ly/2I2r2S2v171T)

------
water42
Clickbait. The author switched from Angular 2 beta 9 (not even a release
candidate) because he was unable to migrate to Angular 2.0.0 since 'too many
things broke to make the upgrade non trivial'. Yet somehow rewriting the
entire app in Vue is easier?

~~~
scriptkiddy
You'd be surprised how simple it is to re-write an application in Vue. As
someone who just finished doing so, I can say that development speed is like
nothing I've ever experienced. The application I rebuilt initially took about
2 months to build with React. I rebuilt it with Vue in 2 weeks by myself. I am
not venerating Vue, just simply responding to your concerns about rebuilding
entire applications.

~~~
seanwilson
I did a rewrite from Angular 1 to Vue recently and it didn't take long at all
plus it fixed a bunch of bugs that were problematic to fix in Angular. If you
write your Angular 1 code in component style, moving them to Vue is pretty
straightforward and a lot of the template conversions just involve changing
keywords (e.g. ng-if -> v-if).

------
bojanvidanovic
I envy how some companies can migrate from one to another framework like that.
Beside that, TypeScript is just fine once you get more time with it, you don't
need to type everything. On the other side I find Angular more stable
framework on the long run.

------
samblr
Have been using angular 1 and I so wish that I had used vue instead. vue is
easy and intuitive compared to angular bloat. May be will take less than half
hour to understand basics coming from angular.

Can anybody share experience with nuxt.js ?

------
emodendroket
People are already migrating from ng2? It just came out!

~~~
bdcravens
ng2 final was released in September 2016, but many were using it well before
then, as in the article. (first beta was in January 2016 I believe)

~~~
emodendroket
I guess maybe it because I am not a frontend person but completely redoing a
project in less than two years seems kind of crazy to me.

------
caludio
I stopped reading at "The main thing we didn’t like and we still don’t like
about Angular 2 is Typescript". Sorry.

------
alexro
Wait, but TypeScript makes inheritance a joy. So, how you do it - unless you
don'r really reuse the implementation?

------
thinbeige
> JSX was also a problem since we could not reuse HTML code

Who has source code in native HTML lying around?

~~~
dwaltrip
Even more, a simple find and replace for "class" to "className", and wrap it
in a render function. There, now the HTML is being reused as JSX.

------
stephenhuey
What I want to know is, why didn't you choose Aurelia? :)

------
arkadiytehgraet
I wonder why nowadays anyone would choose React and give away _all_ patent
rights to the E̶v̶i̶l̶ ̶c̶o̶r̶p̶o̶r̶a̶t̶i̶o̶n̶ Facebook (or not, in which case
one would need to rewrite the app completely, since he cannot use React
anymore). This alone should make choice way easier, if you decided to not use
Angular anyway.

