
Vue.js vs. React: what happened in 2017 - jetter
http://pixeljets.com/blog/vue-js-vs-react-what-to-expect-in-2018/
======
wjossey
I’m the founder writing code (but not the only technical person) for my three
person startup. In October I started migrating our MVP from server side
templates to Vue, given we had direction and traction on a product line that
justified the time investment. It’s turned out to be a great decision
(although likely one that could have been made with react as the choice as
well).

My “success story” is how Vue helped me to massively improve our user
experience in low bandwidth or high latency environments. Our startup is
trying to reinvent the ways that companies approach their review process, and
one of the things we do is run a workshop on delivering actionable feedback
during the review cycle. We have users log into our app during the workshop,
and this often happens in conference rooms over congested WiFi. Our MVP used
turbolinks, so it felt generally “snappy” during normal use, but could feel
sluggish if moderate latency was introduced (such as a congested router).

Since I completed the rewrite to Vue (which took only about two weeks because
of how simple it was to pick up, even for a non frontend person like myself),
we’ve had multiple launches that both would have likely bombed had we not done
the work to move to something less dependent on a tradition client -> server
-> client response cycle to render the next “page”.

Either way, I’ve become an advocate for vue. I love single file components,
love the documentation, and am very happy with the community libraries. All in
all, I’m very bullish for Vue in 2018 as a happy new users.

~~~
platz
What is a turbolink?

~~~
wjossey
Yes, sorry for just tossing this one in there. Our product is build on top of
rails 5.x, and rails has support for turbolinks. They make your server-side
rendered application 'Feel' more SPA, by only refreshing the parts of the page
that have actually changed upon server response.

It still requires a massive payload to be sent across the wire, as well as a
full render on the server, so it's not the "king of efficiency", but it
definitely improves the end user experience in many ways.

In my case, I wanted an even snappier experience, where a user clicking on a
button would trigger an immediate transition, with the "saving" happening
behind the scenes. Before, on a slow or bogged down connection, you could see
page transitions take second(s), which felt like an eternity when you had to
go through our 50+ screens during our workshop. Now, with heavier
backgrounding, those transitions are instantaneous, and the end-user doesn't
need to wait but a millisecond (draw time) for the next page.

~~~
shostack
When would you recommend using turbo links over Vue? Or, conversely, would you
recommend people not even bother with turbolinks?

I'm learning Rails and haven't gotten to that stuff yet, but I'm wondering
whether I should even waste my time learning them if something like Vue is
just superior and just as easy to implement.

~~~
pqdbr
You can have both at the same time. If you want to build a SPA, go for Vue
only. Build if you want to have a more traditional application and only use
Vue for some views, it will work with turbolinks, you just have to use a gem
to help you with the caching (turbolinks cachês the body tag to speed up the
back button, and the gem clears the Vue app before the caching happens making
it idempotent).

Turbolinks is amazing.

------
badbanana
Having used both React (with Typescript and Redux) and the latest Vue (with
es6 and Vuex) I prefer React, and I don't even use React Native.

Vue is better for onboarding people more in tune with "classic" html + js
development; and that's where the advantages end as far as I'm concerned. This
might be a big win for some people.

The way I reason about it is that React is simple, Vue is easy. When you take
into account Vue's templating language, React's api is small in comparison. A
beginner won't know how to do some common use cases reading React's docs, when
Vue might have a something built-in in its templating language (e.g. slots, or
the component tag for dynamic components).

Slightly annoyed with Vuex too because of its slightly leaky abstraction. You
have to remember to setup the properties you mutate so the reactivity will
detect a change; and also remember not use array indexes arrays cause it can't
detect changes otherwise. The array index thing will be fixed in the next
version when they drop support for some older IE. Using Typescript would
probably help a bit here, although Typescript being useless for checking Vue
templates really feels like a huge chunk of its value is wasted.

Typescript is not currently available in the official blessed boilerplate
which greatly affects its uptake in the Vue community.

Anyway, if you already know React, there is zero advantage in investing time
in Vue.

~~~
shard972
I have already moved to using React for my larger projects and Mithril for my
smaller ones instead of Vue because of the lack of typescript support.

That and when you add JSX to mithril, the api just feels so simple and i
rarely find myself checking the docs for something.

~~~
rsyring
Glad to see Mithril mentioned. I like it better than React when comparing the
APIs, It just seems simpler. But React obviously has the mind share. I'd love
to see Mithril gain momentum.

I especially like the fact that I can easily include it as a script, like Vue,
and don't have to have a build chain. That really decreases complexity for
smaller projects.

~~~
acemarke
FWIW, you can absolutely use React as just a pair of script tags - see the
"React Single-File Example" template [0].

It's certainly common to use React in a larger application that uses a build
chain, and that's the recommended approach, but it's not required.

[0]
[https://raw.githubusercontent.com/reactjs/reactjs.org/master...](https://raw.githubusercontent.com/reactjs/reactjs.org/master/static/html/single-
file-example.html)

------
lsdafjklsd
I really don't get the love around vue... I always read the glowing sentiment
and go, "Ok, I'm missing something, let me go back to the vue.js docs and see
what's good"

Things that are a deal breaker for me:

Template language... You can call it 'separation of concerns' all you want,
but just let me generate templates using the language I already know, JSX is
great

State management... I cut my teeth with Ember professionally for a few years,
and really loved it up until I built a data intensive app. Having state spread
across different controllers is great when you have many different routes and
pages, but if one page turns in to a photoshop like app, controllers make a
terrible state management tool. It doesn't seem overly complicated to me to
use redux along with react-redux's connect function to connect regular
functions returning JSX to your state object. Looking at Vue.js, it seems like
I need to learn Ember-lite + Angular (custom directives).

~~~
nawitus
"Template language... You can call it 'separation of concerns' all you want,
but just let me generate templates using the language I already know, JSX is
great"

Not everyone knows JSX, so while that argument applies to you, it doesn't
apply in general.

~~~
jonreem
They mean javascript; jsx is a very small amount of new syntax and is embedded
in normal javascript. Learning a completely separate template language with
all of its own constructs for conditionals, iteration, etc. is significantly
more work.

~~~
bpicolo
There’s not any more to learn vs html than jsx. It’s like 5 relevant
constructs that all follow the same form, and the colon. Takes 20 minutes to
have it down pat.

v-if is actually a big reason I prefer Vue. Ternary operators in JSX are
pretty ugly. The other is that Vuex just feels so perfectly integrated. I've
never felt Redux blends in particularly cleanly, though I certainly don't
judge people that do prefer it.

~~~
dmitriid
Ternary operators in JSX are _valid javascript expressions_. As is anything
that goes into {}

All of the following is neither Javascript nor HTML:

    
    
        v-for=”x in list”
        v-if=”conditional”
        v-on:click=“function”
        v-bind:key=“something.id”
    

etc. etc. etc.

~~~
bpicolo
I'm aware of that bit, I just think they're an ugly piece of control flow
inside JSX, and they're also not a particularly versatile piece of control
flow.

Especially for the else-if case - you end up with repetitive conditionals to
replicate that.

------
git-pull
I think both of them are awesome and have great communities. Especially seeing
as webpack has stabilized.

If you're a startup, it's tempting for many founders to go in headfirst with a
Vue or React. In my opinion, it's rarely necessary, and in the end a lot of
the stuff has to be thrown out if underlying foundations change. I see it as
web development's version of premature optimization.

On the other hand, when I kept all my work in django templates, erb, blade,
etc. and just script JS by hand, there's less of a penalty when the data flow
changes. When I was using a JS framework, the refactoring was so painful I
seriously considered throwing the whole thing out and starting from scratch.
Heh, I'd have been better off not buying in so early on.

As a stop-gap, I'm using pjax. ([https://github.com/defunkt/jquery-
pjax](https://github.com/defunkt/jquery-pjax))

My plan is after stuff is solid and in production and the
product/service/business is moving forward, taking an incremental approach to
moving to vue/react/etc.

P.S. kudos to react for removing the patent stuff in v16.

~~~
kortex
I disagree. Coming from python, my first foray into web frontend was a SPA for
mobile. Both my coworkers convinced me to go right to react + redux (after
some bumbling first with more "traditional" ajax). After a few weeks of utter
bewilderment, I have to say I really enjoy this stack. Some say it's overkill,
but the framework really helps me organize things into cognitive chunks, and
makes debugging so much easier.

Ever had a class in school which you hated at the time because it felt super
hard, but loved in hindsight because of how much you learned? same sort of
vibe. Fight through the pain.

------
dustingetz
I write ClojureScript

A good indicator of if a technology is going to explode, is if emerging
language users are excited about it, as good ideas tend to trickle down from
the more advanced/research-y ecosystems which aren't as constrained by legacy.
So for example React was built by a user of OCaml.

ClojureScript early adopted React.js through the Om project in 2013 and there
is a growing number of competing React adapters, Clojure rewrites etc. I first
saw virtual-dom in ClojureScript in 2012 (eight months before React came out).

Number of ClojureScript projects with traction that are based on vue? Zero,
that I am aware of.

~~~
moomin
Speaking as someone who writes ClojureScript themselves, ClojureScript is
definitely in the category of technologies that show no sign of explosion
whatsoever.

React and Vue are both great technologies, but with Teact the template syntax
is optional, and no lisp user wants another syntax...

~~~
wirrbel
I picked up ClojureScript at the end of 2013. I was a C++ developer then in a
small firm and was tasked to write a web frontend. Outsourcing that project
had failed before (2 times iirc), so my boss bet on me to do it. I knew HTML
and had written probably < 1000 lines of Javascript code in my life before.
Anyway, I needed to write an interactive single page app (basically it was a
visualization of simulation results), so I needed Javascript. But it was so
frustrating to write Javascript (also, tooling was mediocre back then or I
didn't know it). So at the same time, I stumbled over ClojureScript and had a
try (I new Scheme before and was especially outraged by JS syntax quirks, so I
hoped S-expressions would rescue me). With ClojureScript in 2013 I had a
module system that handled dependencies, an emerging library ecosystem that
had what I needed for that specific case, I was pretty happy. This was more
advanced than what I got with JS (I might not have found the viable options
for such stuff with JS, but at least information on them wasn't widely found
then).

Last year I had another look at ClojureScript and it felt like a ghost town.
This saddens me. There are a few inspiring talks now and then, but nothing I
found worth using in a project.

~~~
yogthos
I'm really surprised by this assessment. I've been working with ClojureScript
for the past three years, and I find the ecosystem is very vibrant.
ClojureScript itself has been evolving rapidly. Lately there's been a lot of
focus on Js ecosystem integration allowing you to do things such as consuming
NPM modules directly. The compiler itself is very efficient doing things like
dead code elimination and minification out of the box.

In terms of libraries, I haven't found anything that comes close to
reagent/re-frame for building complex UIs.

Meanwhile, hot code reloading with Figwheel works beautifully, and you have a
REPL for running code in the browser straight from the editor.

My team is very happy with the results of building ClojureScript based
applications. I'd be curious to hear why you feel that there's nothing that's
worth putting in a project.

------
santoriv
What I find most interesting in these results is the satisfaction percentage
i.e. (Used it before and would use again) / (Used it before and would use
again + Used before and would not use again).

\- In 2016:

React - 91% satisfaction

Vue - 91% satisfaction

Angular 2 - 65% satisfaction

No framework - 65% satisfaction

Ember - 50% satisfaction

Angular - 40% satisfaction

Backbone - 31% satisfaction

\- In 2017:

React - 93% satisfaction

Vue - 91% satisfaction

Angular 2 - 66% satisfaction

No framework - 65% satisfaction

Aurelia - 56% satisfaction

Polymer - 53% satisfaction

Ember - 41% satisfaction

Angular - 33% satisfaction

Backbone - 23% satisfaction

It's especially interesting that many of the frameworks have a lower
satisfaction percentage than using "no framework". Of course this could be
largely attributed to who is using no framework. I have encountered a minority
of developers (usually backend devs) who think front-end frameworks are
nonsense and prefer to just write a bunch of jQuery. Also, if you are working
on Wordpress sites, then frameworks are often not necessary.

I've written production code in some of these frameworks (Backbone, Angular 1,
Ember, and React) and I would have to say these results are more or less
consistent with my experience. I love React and don't feel the need to try
anything else.

~~~
philliphaydon
Angular 2 I would like to never use again. It’s caused far more problems than
it’s solved. It requires deep knowledge to build large applications or else it
will suffer performance problems.

------
platz
OP predicts with absolute certainty vue "will become dominant" next year many
times.

Also OP has skin in the game to justify to his team that vue was the correct
choice.

Nice as an opinion piece but too many red flags to be considered fair and
unbiased.

~~~
ec109685
Huh? OP said the power of the React ecosystem and change in license will keep
it on top in 2018 and that if they were starting from scratch they probably
would have used React for their website.

~~~
platz
> next year would be the year of Vue.js success

> Vue.js will be dominating only in the web

OP did not say they would've used React given the choice, they said it would
have made _some_ things simpler

Your reading and subtle re-wording of OPs comments misrepresent what OP
actually says.

> our stack would be simpler if we chose React.js for the web. We definitely
> do not regret choosing Vue.js for web, read more in my previous post why we
> did that, my expectations on Vue.js web domination are becoming the reality

~~~
ec109685
> Synergy, my friends, is the key to React upcoming monopoly.

------
dmitriid
The simple answer is in reading the chart. Look at "I've USED it before, and
WOULD use it again".

React isn't just popular. It also consistently provides good developer
experience. You have to compete not only against React's popularity, but also
against _that_.

React:

\- Used it, would use again: 14k

\- Used it, would _not_ use it again: 1k (7%)

Vue:

\- Used it, would use again: 4.6k

\- Used it, would _not_ use it again: 454 (9.8%)

That ~3% difference in people who tried it, and didn't like it could be the
difference between make it and break it when coming up against React. "I've
heard about it, and I'm _not_ interested" is another important metric.

\---

Personal take:

Things I personally don't like in Vue:

\- String-based programming so prevalent these days.

JSX is a thin layer on top of regular Javascript/Typescript. Where as Vue is
often this:

    
    
        <li v-for="todo in todos">
    

Really?

\- It breaks Javascript and how it works:

    
    
        var app5 = new Vue({
          el: '#app-5',
          data: {
            message: 'Hello Vue.js!'
          },
          methods: {
            reverseMessage: function () {
              this.message = this.message.split('').reverse().join('')
            }
          }
        })
    

There's no chance in hell that `this.message` exists on app5. And yet, there
it is. And then data becomes $data and a lot of other weird stuff such as
computed properties being also hoisted up to the top-level object etc. etc.
etc.

~~~
caseymarquis
It's not really fair to make a comparison between react with JSX and vue
without webpack. In practice you use webpack for making components with
separated js/html/css, so Vue ends up looking a lot better than the above.
That's actually the big draw for me, organization into single file components
which can be parsed as simple html. The js component structure is just another
piece of that. You're passing vue a template for creating components in an
organized/standard way. You can define your own render function if you want
the freedom, but you start out with something clean and well organized.

Vue is definitely doing things behind the scenes, but it's nothing all that
complicated.

I wouldn't say it's hoisting. It uses the data function to create component
instance objects which it then adds the template's computed
props/methods/watchers etc on to, and links with the life cycle hooks.

If you created the component object yourself instead of a definition for it,
there would be less magic going on for sure, but things would be much less
organized.

(Minor: I don't use vue without webpack, but I assume data should be a
function which returns a data instance, so what you've written won't work in
Vue unless it's different for the top level component?)

~~~
caseymarquis
Follow up, I was on my phone before, this is what working with Vue typically
looks like:

    
    
        <template>
            <p v-text="message" class="some-class">
            </p>
            <button v-on:click="reverseMessage">
            </button>
        </template>
    
        <script>
            export default {
                data() {
                    return {
                        message: "Hello Vue.js!"
                    };
                },
                methods: {
                    reverseMessage(){
                        this.message = this.message.split('').reverse().join('');
                    },
                },
            }
        </script>
    
        <style>
            .some-class{
                color: black;
            }
        </style>
    

The thing to note is that there are other objects which can be added to the
component definition which add a lot of utility and keeps things standardized:
created, mounted, computed, watch, etc. There's a bit of magic behind the
scenes to make it work, but it's worth it for the standardization/organization
in my opinion.

------
chvid
React IMHO is good enough that I don't want to change framework/basic frontend
technology again.

~~~
rvanmil
Agreed, it’ll take another paradigm shift to switch to something else.

~~~
murukesh_s
Not necessarily.. I wonder had react not been backed by FB, it certainly would
have had a beating in its popularity given lighter and arguably faster
alternatives like vue. Remember, performance was one of the main argument
React had when compare to Angular. Now since performance is no more a
differentiating factor, developers might look into other aspects like better
ROI in short and long term..

~~~
Silhouette
Just as one anecdotal data point, we didn't choose React for its performance
when evaluating tools for our recent projects. (React can still be orders of
magnitude slower than localised direct DOM updates on demand, after all, and
in cases where performance really matters that might still be what you have to
fall back on.)

The game-changer with React is that it presents a declarative way to specify
your DOM content, which in turn can significantly reduce the number of cases
you have to consider in your rendering and state management code, and it's
_fast enough_ to make that work in a lot of real world situations.

~~~
murukesh_s
Could be for you, but have you wondered if React was say way slower than
Angular and heavier, the adoption would have been much much lower?. Agreed,
the model that React brought is superior but the catalyst was performance.
They even highlighted performance as the main selling point with introducing
the virtual dom, where the computation (dom querying) happens not in the dom
but in the javascript, which is arguably faster and only differential updates
are applied to the actual dom.

In my friend circle everyone wanted/were using Angular.js but it was too heavy
for actual production use while react showed much better performance in the
benchmarks (almost closer to Dom).

~~~
Silhouette
React and Angular are solutions to different problems. I don't think React
would have succeeded without adequate performance, but I also don't think it
is why React has been successful or the main reason it has displaced some of
Angular's "market share"; being fast enough is necessary but not sufficient to
do its job.

------
ng12
Do Vue templates play nicely with Typescript? That's something I love about
JSX -- "it's just JavaScript" is an incredibly sublime feature. I know you can
use JSX with Vue but I'm skeptical since it's a first-order feature with
React.

~~~
KitDuncan
Since October (I think) vue single file components work flawlessly with
typescript. Can't speak for jsx though.

~~~
tomonl
It works in the <script lang="ts"> part of your .vue file, but not the
<template> part.

~~~
ng12
Ah, that's a bummer. Vue Templates seem wildly regressive to me -- I can't
fathom going back to stringly-typed Handlebars wrangling after using JSX/TSX.

After looking into this further it seems like Vue Templates also differentiate
between values and components. In React I often write components which can
take in either: a good example is text which the consumer might want to
format. You can easily write the component so that they pass in a string or a
<span /> element.

Vue has a lot of good ideas but the templates are almost a non-starter for me.

~~~
CaveTech
You can use slots to pass HTML or Components into child components.

You can have vue render jsx or templates, but in practice you can make
interactive components very simply using templates which are foundationally
simpler and easier to grasp than JSX.

~~~
ng12
How so? In my mind templates and JSX are equally complex from a user
standpoint. In fact I'd argue that JSX is simpler because you don't have to
invent slots -- it's an obvious side effect of using JavaScript to generate
your structure.

Just reading about slot and slot-scope makes me think Vue's reputation for
simplicity is overblown.

~~~
ricardobeat
It may seem "obvious" to you after being in the water with JSX for a while,
but the free-style abstractions afforded by being 'just' JavaScript, like the
one you mention, look incredibly complex for someone approaching an unknown
codebase.

------
d357r0y3r
React + TypeScript is simply too good to not use for me. The idea of going
back to unsafe templates is just not acceptable.

------
hbhakhra
Good assessment. To summarize the argument, Vue.js is just as good and some
would argue better than React for web development, but the React ecosystem
really puts it over the top, especially React Native.

~~~
hakcermani
For those like me in the Vue camp, with the React-native dilemma, there is
Fuse tools for the interim till week matures. Very clean separation between UI
and JS logic.

------
sarahcross
React changing their license probably saved them. My web dev office was going
to transition from them until they changed it.

~~~
jjeaff
Same here. For us personally, the license made no difference. We know we will
never come across any patent issues with Facebook. But the fact that it
existed led us to believe that in the long run an alternative would emerge
since larger corps would avoid it because of the license.

Now that they got rid of it, I have no such concern investing time in react
for the short/mid term term.

------
throwaway0255
One thing I'm noticing about SPAs is that they're often slower to load, but
the slowness and loading animations gives me a higher perception of the
quality of the application.

The same application loading and doing things instantly as server-side
templates feels comparatively cheap and un-modern.

What is wrong with me?

------
jordache
Coming from Angular, I'm biased towards entities declared in the form of a
class. It's a style that is easy to manage and familiar to most programmers.

Vue currently seems to be a mix bag of styles. My take away from the little
that I dabbled: \- You need the vue-class-component dependency in order to
declare class based components, otherwise, you're stuck with the awkward
object literal notation \- For state management using Vuex. You are are
limited to the object literal style to declare your state store. Very awkward
to work with.

Yes to get some data bound to a template and rendered out, Vue takes very
little amount of code. However that is not a meaningful benefit to me. I feel
Angular's complete framework and class based convention is much more suitable
for a team environment.

~~~
philliphaydon
I couldn’t disagree more. Unless your team have Super in depth knowledge of
angular then it’s the wrong choice. It’s defaults to progagate changes cause
rendering perf issues that are so frustrating to fix. Out of the box react or
vue performs better than angular hands down. I hate that after learning
angular 2 I realise I should not followed tutorials and advice and just
switched all the defaults off on classes and manually propagate changes when
required cos it’s a painful task to do.

~~~
jordache
I don't know what convoluted patterns you where implementing, but out of the
box, the default change detection in angular is performant, esp if you start
to leverage observables and the async pipe (to eliminate the need for
component onDestroy maintenance tasks). It's a joy to use. Yes Angular
provides a lot more options than react or vue, and maybe confusing given the
scope of what's possible. However, after the initial learning curve, Angular
is a very efficient framework / pattern to work with in a team setting.

If you resort to manual change detection, then it's an obvious sign of needing
to refactor your design.

~~~
philliphaydon
The default change detection can cause the whole page to redraw. Especially if
you have a lot of data. It gets even worse.

~~~
jordache
it's pretty much the same change detection logic across all of these
frameworks. Immutable data is key to performant change detection. Angular
provides the ability to bind template to immutable state data so the framework
can provide the most performant change detection

~~~
philliphaydon
Except it's not the same across all these frameworks.

If I build a grid with 15 columns and 3500 rows (actual issue faced) which
contains 3 characters in a cell and a menu when clicking on the cell.

Out of the box Angular took ~8 seconds to make it appear on the screen.

Vue and React were both less than 1 second.

If I changed the value of a cell, then Angular would redraw the entire grid,
Vue and React just updated the cell.

You know what the Angular gitter room told me to do... turn off change
detection...

Changing it to 1 way binding resolved the rendering time and made it on par
with the other 2, but it's still frustrating, especially when the same example
in Angular 1 worked in less than 1s with 2 way binding.

~~~
jordache
>Changing it to 1 way binding resolved the rendering time and made it on par
with the other 2,

You have to explicitly enable 2 way data binding in Angular 2.x +. Angular
2.x+ is 1 way data binding by default. This is a key differentiation between
AngularJS 1.x and Angular 2.x+

The fact that you imply you had 2 way data binding initially means you were
using angularJS 1.x (not Angular 2.x +) Or if the latter, you had some very
poor design decisions to settle on a 2 way data binding solution. Vue and
React both are by default 1 way data binding.

~~~
philliphaydon
/facepalm

I WANT 2 way binding so I could achieve what I wanted to achieve.

The only way to get the performance out of angular 2 was to NOT use 2 way
binding and hack it together.

Vue / React examples didn't suffer from 8 seconds of render time using 2 way
binding on a large number of elements.

You can sit and defend angular 2 all you want, doesn't change the fact it's
terrible.

Let's not even get into the angular api 2 changing after they said it
wouldn't. And regressions of the angular cli, and breaking changes on minor
updates.

~~~
jordache
all performan comparisons out there have the three frameworks neck and neck.
Your anecdote is certainly interesting in terms of the diffference in
performance. I would chalk it up as poor implementation / understanding of
angular, rather than some special edge case that tested the limitation of
angular

------
simonhamp
I personally prefer Vue because it is approachable and easy to adopt. I
believe that if Vue embraces PWAs in a pragmatic way that performs and is
accessible, it will be top for a while.

At the moment, PWA is not a viable replacement for some cases, but it’s about
to explode to everyone.

------
fictionfuture
I see a lot of commits from the Vue team into the core repo that are meant to
support use in native.

Likely, we can expect something comprehensive for native this year.

I also believe it's a smart strategy to avoid Facebook codebases because they
are all meant to somehow benefit FB in some (usually dubious) way.

Also the Vue approach is 1000% cleaner in practice than React, just doesn't
have the bandwagon effect going for it

~~~
scardine
My typical use case doesn't need native apps - a PWA is good enough for me. I
will not comment on speculation about the compile-to-native feature because
personally it is irrelevant.

I can say that as you I prefer Vue over React and some of my personal reasons
are:

* I like opinionated frameworks

* I don't like to mix Javascript and HTML - I can handle a Vue template to any designer but I would not trust a JSX file to a non-programmer.

* Vue is easier for developer onboarding - with Vue the gap between a junior and a senior developer is way smaller.

React may be better, I don't care, Vue is easier for my development style.

~~~
marcosdumay
The one reason why I favor Vue more than React is:

* Vue downscales. If you have a single scripted component in a page, you will get a simple page, with a small amount of Vue added.

------
kumarvvr
I have spent quite a bit time into learning Angular (4/5). I am new to front-
end dev, and found that the structured approach of Angular more appealing than
React.

Should I continue with Angular or move on to React?

My goal is to create a data-driven website, with expressJS & PostgreSQL
backend. Not very complicated, but not simple either.

~~~
code_chimp
IMHO, keep on the path you are on until you are really comfortable with
Angular, then learn React as well.

I went the opposite direction - put up a large React/Redux codebase and now
have moved on to a position that requires Angular. There is no harm in knowing
more than one framework, I find that both will get the job done.

~~~
kumarvvr
Thanks. I am thinking in a similar way. I guess knowing concepts is more
important than any framework / library in particular.

I suppose Angular is more suited for me as it is semi-rigid in the way things
have to be done. Complaints about TS eco-system are unfounded in my view as
the basic building blocks for building any site, HTML templates, CSS
(SASS/SCSS/LESS etc), client side scripting, etc are built in.

------
apatheticonion
Having used all of the big three. Am I the only one who likes and prefers
Angular?

~~~
nikkwong
Curious—what makes you prefer angular?

~~~
apatheticonion
It's very well structured, easy to understand, batteries included, lends
itself well to maintainability and scale.

When working for a company with staff below me who had very basic
understanding of JS (having just done HTML/CSS/JQuery, had no idea what a
promise was), there was almost no learning curve with Angular. The hardest
part was understanding what a component was, then learning the folder
structure.

Angular's seamless use of templating, the built in support for CSS pre-
processing and simplicity of uni-directional databinding had the entire team
pick it up and be productive almost immediately.

Using decorators to declare inputs/outputs on dumb components is clear,
readable and easy to understand.

Class based components are also very clear.

Some say TS is annoying and all power to you, but using types is optional.
Personally, TS has allowed me to save on some test cases by virtue of the
compiler catching those issues. Plus there is a comfort in quality
intellisense.

Vue is cool, it's like a less opinionated Angular. In my opinion, it's
strength is its ability to be dropped into any project, giving you client side
components and databinding irrespective of your stack. However I have
experienced growing pains in larger projects as a result of people over
complicating simple solutions.

I am still relatively inexperienced though, and I intend to spend more time
with Vue to see if I can't like it more. I'm sure all of my concerns are
addressable. So far though, Angular has treated me very kindly, both in large
and small scale projects.

------
hypercluster
I like the simplicity of React though I don't mind the Vue templating language
that much either. Sometimes I actually prefer Vue templates because with React
you often see components where it's not so clear how the rendered output will
look like.

------
cyberferret
I evaluated both earlier in the year, and to me (spending the last 30 years
developing software), Vue just seemed to fit my mindset better. I just
couldn't "get" React, no matter how many times I tried.

I guess it is just how my "programming mind" thinks about problems. I am sure
developers who approach problems differently may enjoy React more, but for me,
I guess I am a lot more old fashioned and 'structured' in the way I see
things.

------
dbrgn
Elm would deserve a mention too. One of the very few sane frontend development
approaches.

------
guru4consulting
Any suggestion for the below use case? Whether to use Vue or React?

\- I develop APIs and plan to hire freelancers to do the web/mobile clients
(so, higher availability of skills in the market is important to me)

\- I have a web designer developing the UI with just plain html/css. And this
is going thru multiple iterations and the web-designer is able to make all the
changes (cheaper because this is just a web-designer, not a programmer).

\- Once, the UI is finalized (and fully designed with html/css), I plan to
hire a Javascript programmer to do the SPA front-end (so, being able to use
existing plain html/css templates with minimal change is a big benefit).

\- I do not plan to create native mobile client, just a hybrid app based on
webkit. If the web app was developed with React, then will it benefit the
mobile clients to be developed with React Native? or, does it matter at all?
If Vue.js was used for SPA webapp, what do the Vue programmers use for mobile
client? I assume React guys might naturally use React Native.

------
perlgeek
Isn't it funny how you can read different things into the same data?

> So, 1 year passed, and Vue.js is clearly the leader in "would like to learn"
> by a huge margin

For me, the main takeaway of the newer chart is "React is the clear winner in
the 'Happy Customer' category".

For the record, I never used any of the frameworks, though I think I will,
some day.

------
toddmorey
Just to set record clear, vue components can be written in pure JS or using
JSX, in addition to the template files.

~~~
Can_Not
And pug/jade.

------
diminish
I truly love Vue and hope it evolves and spreads everywhere.

------
vitro
The reason I am not even remotely considering React is the Facebook itself and
what this company represents - exploiting people's minds and emotions to
fulfill their business plan. I can't help it but if I would use react, I would
not be able to get this feeling out of my mind, so if there is viable
alternative - vue.js, I am definitely going that way.

Something similar like using cosmetics that have been tested on animals, if I
can choose, I choose something else.

I know this should be more of a technical discussion, just I can't help but
think of this aspect when it comes to React.

------
qdoop
Which is faster? Vue; Which is more modular? Vue; Which is simpler to grasp
and reason about? Vue; Build in CSS support? Vue;

P.S. Vue contains React. You could in principle write your components React
style.

------
ausjke
vuejs does gain strong interests from large companies such as alibaba,baidu
and tencent, the three are called BATs in China similar(or larger) to amazon,
google and facebook in US.

One of the BAT should acquire Vue.js to make it a strong player for the long
run, that may happen in 2018 I hope.

Both laravel and vue.js (vue.js is the default frontend choice and embedded in
Laravel) are from one core developer, I liked them, but am concerned about the
bus factor. I eventually choose nodejs+react because of that.

------
faitswulff
It's a shame there's no first party supported Vue native library, but I
suppose that's too much even for Evan.

~~~
benatkin
That might not matter that much. There's still a strong argument for
implementing native apps using their own SDKs. There are more developers with
experience with them, there is more boilerplate and examples, third party
integrations are typically designed for them, and more books and documentation
are for them. On the front page of HN today there was a stackshare post about
a startup with only three engineers that used a lot of cutting edge tools, but
React Native was not one of them.

------
homakov
I had trouble getting started with React but Vue was a breeze. Better for
newbies imo.

------
baybal2
I'm afraid React is eventually turning into Angular. At some point, I felt
that Angular is somebody's PhD work exploring arcane computer science
concepts, not a piece of software for practical use.

React gets closer to that with each year.

~~~
acemarke
Can you clarify that comment? What aspects of React's development are you
concerned with?

~~~
baybal2
First, probably was their approach to implicitly require use of Observable
objects everywhere.

Second, use of arcane CS lingo and authors writing 10 pages long pages on
every known MVC model, FLUX, SCHMUX and etc with weekly regularity.

Third, during transition to Fiber, they went on gigantic increase of
complexity by introducing a lot of what can be said to be heuristic rules, and
all for non-guaranteed, minor performance gain.

~~~
baybal2
There is no explicit dependency on RXJS or its analogs, but the whole
ecosystem is heavily tied to on them.

A question "how to do thing A when user changes thing B" on React forums is
usually dismissed with "just use MobX/Rxjs/Kefir/Bacon"

~~~
acemarke
Citation Needed, please.

The most basic approach for responding to a change in data is to compare the
previous and current props in the `componentWillReceiveProps` or
`componentDidUpdate` lifecycle methods.

Meanwhile, Redux is the most common state management library used with React
apps.

You certainly _can_ use MobX, RxJS, or some other FRP-type library with React,
but to claim that "the whole ecosystem is heavily tied to them" is simply
wrong, and shows a gross misunderstanding of the React world.

~~~
baybal2
>but to claim that "the whole ecosystem is heavily tied to them" is simply
wrong, and shows a gross misunderstanding of the React world.

May be, but this is how it looks from my part of the world, which is Russia or
China when I am doing term contracts there from time to time.

Here, the so called "software evangelists", apparently paid or hired by FB,
swarm tech events to lecture people on how to do "10 tricks to transform your
eCommerce business with Agile management, and FLUX pattern". And they get
pretty annoying. My experience with React ends with my interaction with them
and doing basic demos for recruitment interviews. I have not yet heard of a
FRP-framework-free React site being considered norm for a "serious project"
here.

Just like those FB "evangelists" do today, Angular proponents were doing the
same 5 years ago with their maxim: "the magic provider/factory/service pattern
is the new best thing since a sliced bread" without elaborating much why. That
lead to many mentally-infirm developers trying to shove it everywhere, making
usage of Angular ecosystem without zealous following of that pattern
impossible.

I have impression that the same is happening with FRP-everywhere crowd and
React.

If this isn't how it is, I am glad.

~~~
acemarke
I certainly don't claim to know everything that goes on in the React ecosystem
(especially outside the US), but I _am_ pretty tuned in with the major trends
and discussions that are going on, and I've seen plenty of real-world React
applications and codebases. None of that matches anything I've seen thus far.

I have never heard of Facebook paying "software evangelists". I suppose it's
possible, but it really doesn't match with what I know about how Facebook
develops and uses React.

------
buamaharami
Why in earth people would like to to use anything from facebook in they
business ? Why do you trust they licensing ?

I would choose riotjs or vuejs anyday before any facebook's code in my apps.

~~~
joobus
You apparently aren't keeping up with the latest about riotjs:
[https://github.com/riot/riot/issues/2283](https://github.com/riot/riot/issues/2283)

I wouldn't feel confident picking that as my company's future.

~~~
ricardobeat
Whoa. Thanks for the link, wasn't aware of that. A lesson on how not to run
OSS:
[https://github.com/riot/riot/issues/2512](https://github.com/riot/riot/issues/2512)

