
Vue.js vs. React - fanf2
https://vuejs.org/v2/guide/comparison.html#React
======
pier25
We moved away from React to Vue about 8 months ago and everyone on the team is
a lot happier.

First reason is we hate JSX. It forces you to write loops, conditionals, etc,
outside of the markup you are currently writing/reading. It's like writing
shitty PHP code without templates. It also forces you to use a lot of
boilerplate like bind(), Object.keys(), etc.

Another problem with React is that it only really solves one problem. There is
no official React router and we hated using the unofficial react-router for a
number of reasons. A lot of people end up using MobX too.

With Vue there is no need to resort to third parties for your essential
blocks. It provides an official router and store called Vuex, which IMO blows
Redux out of the water when combined with Vue's reactive data.

Vue docs are probably one of the best I've used. They provide technical docs,
plus excellent narrative docs (guides) for all their projects (Vue, Router,
Vuex, templates, etc).

I won't say that Vue is perfect, but we would never go back to React.

If you don't like Vue but want to get out of React, check out Marko, the UI
library by Ebay. It's better in every way than Vue or React except that the
community and ecosystem are almost non existent.

[http://markojs.com/](http://markojs.com/)

~~~
thomasDE
> It's like writing shitty PHP code without templates.

For me, it's the other way around. I feel like you can still separate the
logic and markup, but instead of the template engine syntax you can just
JavaScript.

From the top of my head, I can at least remember six template engines' syntax
I've learned: Smarty (PHP), Mustache, Blade (PHP), EJS, Angular and another
custom template engine. When I tried React I was so happy that I did not have
to learn another template syntax as it all was _just JavaScript_.

Another template engine syntax? No, thank you. I stick to React.

~~~
Bahamut
To be fair, JSX has its own idiosyncracies too for templating, such as
className, htmlFor, and the obnoxious attribute name for dynamically inserted
html. It is not immune to the criticism that it requires learning.

~~~
twhb
Those names have nothing to do with JSX or React, they're the actual
properties you're setting. JS properties don't map 1:1 to HTML attributes:
while for example the "src" attribute is controlled using the "src" property,
the "for" attribute is controlled using the "htmlFor" property, and the
"class" attribute with the "className" property. All React is doing is setting
the properties you tell it to.

(The reason for the name change is that old versions of JS couldn't use
keywords - like "for" and "class" \- as property names.)

~~~
baddox
I agree. Those examples have nothing to do with learning a new template
syntax, it's simply the API of React.Component.

Granted, there is still _some_ syntax you need to learn for JSX, but it's very
little. If you already know HTML's syntax, the only new things I can think of
are the curly braces for using JS expressions as prop values (you also need to
know what a JS expression is, lest you try to use an if statement), and spread
attributes.

~~~
twhb
I think you misunderstand. The names are unrelated to React as well, they are
native. Defined by the same standards bodies that define JavaScript itself,
implemented by the browsers themselves. On a blank HTML page that includes
neither React nor anything else, the line `document.body.className = "foo";`
sets the body's class to "foo". (And `document.body.class = "foo";` does not.)

All JSX is doing is transforming `<div className="foo">` into `[create div
element]; div.className = "foo";`. If you wrote `<div class="foo">`, JSX would
faithfully transform it into `[create div element]; div.class = "foo";` -
which doesn't work.

~~~
allover
Whilst you're correct, that's where the names are from, it's also not totally
accurate to suggest it has nothing to do with React.

React defines `React.createElement`, `<div class="foo"/>` transforms to
`React.createElement("div", { "class": "foo" })`, so React could convert that
under the hood to set className correctly.

Preact does something similar to allow this. However it now seems it is now
too late for React for too little benefit. And there's a downside [1]:

> The JSX transform used to do that, but we don't recommend it because it's
> confusing if you ever try to pass class= or for= as a prop to your own
> components – you wouldn't expect to access them with a different name.

[1]
[https://github.com/facebook/react/issues/4433#issuecomment-1...](https://github.com/facebook/react/issues/4433#issuecomment-143842840)

------
a13n
You'll see quotes in this thread like "The demand for both React and Vue.js is
growing tremendously" thrown around. It's good to check out npm install stats
to get an unopinionated comparison.

[https://npm-stat.com/charts.html?package=react&package=vue&p...](https://npm-
stat.com/charts.html?package=react&package=vue&package=angular&from=2016-01-01&to=2017-08-19)

In reality, React is downloaded roughly 4-5x more than angular and 7-8x more
than Vue. In August so far, React has 75% market share among these three libs.
Interestingly, this share has grown in August compared to both last month
(July) and beginning of year (January).

While this thread and the license thread might indicate that React is dying,
it's not. It's growing.

If Vue is going to be what React is today, it has quite a long way to go.

~~~
yunyu
Something worth noting is that both Angular and Vue are far more script-embed-
directly-into-page friendly (mostly due to templating) compared to React.
Almost all React users get it from NPM, while I would expect that the
proportion of Angular or Vue users who get them from NPM is lower. I've seen a
_lot_ of projects for those two run without any build system (and anecdotally,
I'm pretty sure I'm not the only one who's learned Vue with just a script
embed).

~~~
madmax108
Perfectly said. I've used Vue for a couple of months now (a couple personal
projects, experiments and some dashboards) and used Angular for ~2 years
before (admittedly, mostly Angular 1), and have literally never had to start
off from 'npm install', unlike react (which I used for a year or so before),
where everything needed a lot of boilerplate setup.

Most devs I know start a react application by cloning some standard git repo
which has a working webpack/tidyCSS/redux/some test suite etc. and then write
your first line of useful code. The boilerplate is enormous!

~~~
chrisco255
Most Angular 1 projects I saw would start off with a Yeoman/Bower MEAN stack
implementation. The boilerplate no less enormous there. I'll admit Vue is
nicer about these things than either Angular or React, but Angular has tons of
boiler plate.

------
Kiro
I've built semi-large applications in both Vue.js and React. I like both but
prefer React.

For me Vue.js is like a light-weight Angular 1, in a good way. It's very
intuitive and you can start working immediately. It does however easily end up
in confusion about where the state lives with the two-way binding. I've run
into a lot of implicit state changes wrecking havoc. The declarative nature of
React definitely wins here, especially working with stateless functional
components. If you're serious about Vue you should adhere to unidirectional
bindings, components and use Vuex.

The best thing about Vue.js for me is the single file components. It's such a
nice feeling to know that everything affecting a certain component is right
before your eyes. That's also the reason I started adapting CSS-in-JS in my
React components.

The biggest problem for me with Vue.js is the template DSL. You often think
"how do I do this complicated tree render in Vue's template syntax? In JSX I
would just use JavaScript". For me, that was the best upgrade going from
Angular to React and it feels like a step backwards when using Vue.js.

~~~
eibrahim
I have been building web apps for 19+ years. I like many of the frameworks out
there but for some reason I HATE React. I think JSX is a huge turnoff for me.
I just can't get past html in javascript. It feels wrong.

With that said, there are so many VERY smart people embracing React, so I am
always questioning my "hate". Maybe one day I will change my mind.

I haven't use Vue but watched/read about it and seems very cool and simple to
use.

For now, my favorite framework by far is Ember JS and it really blows my mind
why it is not the most popular framework out there. The amount of stuff you
get out of the box and the incredible productivity and happiness it brings to
the developer experience is IMPRESSIVE. It will take you 2 weeks of work to
make a new React app have the same feature set as an Ember app*

* I could be wrong.

~~~
Bahamut
Interestingly, I had recently joined a team that was using Ember, and we found
that Ember hampered our productivity. We switched to React and was able to
rebuild 4 months of Ember work in about 3 weeks of work in React (not sure how
many developers were working on the Ember app originally, but it was mainly 2
of us who built the React app), including requisite tests.

I’m of the opinion that Angular is much better than Ember (note: I have 4.5
years of experience in the Angular ecosystem, including in open source), and I
think I am overall perhaps more productive with React than Angular, although I
feel like there are less issues with state management in Angular, which has
been a pita in React. All the libraries/frameworks have various tradeoffs
ultimately, so I don’t believe there is a cure all for everyone’s preferences.

A note about JSX - I am not a big fan of it, but I see it more as having
tradeoffs like more traditional templating languages, but different ones. I
have been a bit resigned that this is the direction the ecosystem has turned
towards, so I have personally decided to hold that dislike more loosely and
focus on more important architecture issues. It does little good to let
dislike over style paper over higher level issues if you can help it IMO. I
don’t think we’ll ever see a perfect template language.

~~~
felideon
A rewrite is always going to take less time to build than the original poorly-
specified version when people were trying to figure out what to do.

And the original team could have been more junior, or if similarly-experienced
than your 2-person team, adding more people to the team without good
leadership can also affect productivity---or as they say in Scrum, "velocity".

------
blumomo
In this thread people are fighting about their _opinions_ why they use Vue.js
or React. And why X is really better than Y.

In reality these programmers don't want to have the feeling they might have
made the wrong choice when they used X instead of Y. The idea that they might
have taken the poorer choice hurts so much that they need to defend their
decision so heavily while in reality taking ReactJS or Vue.js is like ordering
pizza or pasta. You usually don't want to have both at the same time. So you
need to explain why pizza is better than pasta tonight. Only that you usually
have to stick longer around with Vue.js or ReactJS once chosen. Enjoy your
choice and solve real problems, but stop fighting about it, programmers. Pasta
and pizza will always both win.

~~~
tigershark
You can't compare react and vue with pizza and pasta. Pizza and pasta are two
finished products, while react and vue are two different ways of building the
same product. Your comparison doesn't make sense at all to me.

~~~
nartubio
Say you're about to cook pizza or pasta, you use flour and tomato for both.
Comparison not 100% off IMO.

~~~
tigershark
No. 1000 times no. For the pizza base you use flour, water, salt and yeast.
For _fresh_ pasta most of the time you use flour and eggs. The process
moreover is _completely_ different. You NEVER use tomato for making the fresh
pasta or the pizza base. You _may_ use tomato as a condiment for pasta and
pizza. This comparison is even more wrong than comparing apples and oranges.
But I expect that unlike me you never cooked pizza and fresh pasta if you
can't see the obvious difference.

~~~
nartubio
In fact I'm a seasoned pizza cook but pasta is still a pending subject of
mine.

~~~
Mz
_In fact I 'm a seasoned pizza_

I completely misunderstood your comment. I might need to go get food soon.

------
spion
To me the whole idea of client-side HTML templates seems bad. They start out
easy enough, but then they either limit you in power or introduce new and
weird concepts to replace things that are easy, familiar and often better
designed in the host language.

Here is an example on which I'd love to be proven wrong:

[https://jsfiddle.net/j2sxgat2/2/](https://jsfiddle.net/j2sxgat2/2/)

Its a generic spinner component that waits on a promise then passes off the
fetched data to any other custom jsx. It can also take onFulfill and onReject
handlers to run code when the promise resolves.

The concrete example shown in the fiddle renders a select list with the
options received after waiting for a response from the "server". An onFulfill
handler pre-selects the first option once data arrives. The observable
selected item is also used from outside the spinner component.

With React+mobx and JSX its all simple functions/closures (some of them
returning jsx), lexical scope and components. With Vue I'm not sure where to
start - I assume I would need to register a custom component for the inner
content and use slots?

~~~
al2o3cr

        or introduce new and weird concepts to replace things that
        are easy, familiar and often better designed in the host
        language.
    

Oddly, that's exactly how I feel about the "{condition_expression &&
template_evaluation}" idiom in JSX.

~~~
spion
Personally I prefer the ternary operator in those cases, however I think do
expressions will fix most of the if/else awkward stuff:
[https://babeljs.io/docs/plugins/transform-do-
expressions/](https://babeljs.io/docs/plugins/transform-do-expressions/)

~~~
gunn
Can that actually help react look better here? I'm currently imagining:

    
    
      { do {
        if (condition_expression) {
          template_evaluation
        }
      }}

~~~
spion
For a single expression some of it can be omitted:

    
    
      { do { if (condition_expression) template_evaluation }}
    

But I gues thats not really better.

I'm hoping jsx will eventually default to `do` expressions though, and then it
becomes

    
    
      { if (conditional_expression) template_evaluation }

------
kennysmoothx
I used React for a few years and it was great and powerful, there were many
things however that I disliked.. Particularly I was not a fan of JSX. I liked
React but I did not feel comfortable using it.

When I first saw VueJS I had a hard time understanding how it would be any
better than React, that is until I saw single file components.

[https://vuejs.org/images/vue-component.png](https://vuejs.org/images/vue-
component.png)

I fell in love with the eloquence of being able to separate my HTML, JS,
Styles for a single component.. it seemed /right/ to me..

In any case, I've been using VueJS ever since for my new projects moving
forward and I'm very happy with it. It has everything I would ever need from
React but in what I feel is a more polished and thought-out way.

Just my two cents :)

~~~
meagher
Completely agree! Single-file components are more natural to how I think about
the web.

It's worth noting that Vue also supports render functions with JSX
([https://vuejs.org/v2/guide/render-
function.html](https://vuejs.org/v2/guide/render-function.html)).

~~~
wolco
One of the reasons I moved to vue was the template section allowed normal
html. Saved me so much time styling.

I do like jsx for simple things but always felt it bogged down the design
piece having to convert even if its just the class to className

------
keyle
I've used both. What makes me pick Vue in the end is the fact that there is no
compiler needed, no jsx and all the non-sense that goes with that.

If you want a full blown huge application to last years, then go Angular...
Although who knows if Angular will be there in 5 or so years.

There is no perfect library/framework but I love Vue because Vue does exactly
what it says on the tin.

~~~
paulgrimes1
No application lasts "years" nowadays, so I'd suggest not go "go Angular"
simply because it's Angular. The modularity and speed-to-productivity of Vue
is the reason I choose it. Plus, the community is quite supportive; always
nice.

~~~
recursive
I work near, but not directly on, an application that's lasted about 20 years
so far. It's still actively maintained, and still making money. It's mostly
written in vb6 and classic asp. Yes. Some applications far outside the hype
cycle can last decades.

------
conradfr
In a way VueJS is "React for those who liked Angular1".

I've done many Angular apps. I've done a bit of React (with Reflux &
Browserify).

I tried moving to React/Redux/Webpack but it's not an easy task to grasp the
whole thing. Webpack itself was close to make me throw the towel on side
projects.

I tried VueJS because of a job interview and quite liked it and got productive
really fast thanks to good documentation and my previous experience in angular
& React.

Professionally I wouldn't mind any of those but for side projects it will be
VueJS from now on.

As a side note I don't get why all the boilerplates always mix backend and
frontend code and dependencies. If you're not interested in a node backend and
learning it's overwhelming.

The worst thing is that boilerplates you find are always outdated (router,
hot-reloading etc) and worst of all mingling server and client deps so if
you're not interested in a node backend you have to

~~~
buchanaf
I feel like a broken record, but definitely take a look at create-react-app if
you haven't already. Its extremely well documented and takes care of managing
the 20+ dev dependencies that are typically associated with a project.

~~~
conradfr
It's useful but doesn't take care of state management AFAIK which can be a big
part.

------
ergo14
Another option that is interesting right now is Polymer 2.x if you haven't
tried it recently, give it a shot.

[https://vuejs.org/v2/guide/comparison.html#Polymer](https://vuejs.org/v2/guide/comparison.html#Polymer)
There are some similarities shared between polymer and react/vue (personally
only used react and angular 1.x before).

I've built applications with it using polyfills and things worked just fine
with legacy applications on IE10 + jquery interacting with web components.

Performance is nice, there is more and more adoption from giant enterprises
like Netflix, IBM, GE, Gannett, Electronics Arts, CocaCola, ING, BBVA.

Webcomponents.org has over 1k components to choose from and is growing.

Now with `lit-html` arriving soon we might see alternative to JSX if someone
wants that, polymer-redux or polymer-uniflow is available as an option too.

[https://hnpwa.com/](https://hnpwa.com/) \- one of fastest Hacker News
implementations is based on Polymer - and that is even without SSR.

SvelteJS also seems nice, although it seems one-man project for now :( On
Polymer end I hope that on the summit next week they will announce proper NPM
support finally and I miss that.

~~~
jacquesc
I used Polymer 2 to build a couple of highly used internal web components
recently. And I'm currently in the process of ripping it all out. Why? It's
not technically Polymer's fault, but the performance and stability on iOS and
Safari are complete crap. Often crashes the browser on both desktop and
mobile.

Also, the Shadow DOM is one concept that I liked in theory and hated in
practice. Made it very difficult to do very simple styling tasks that were
accomplished easily with plain css and proper naming (e.g. having parent
components provide default styles for child components).

The polymer bundler in 2.0 is a buggy mess (it's still in beta) and I couldn't
find any decent way to use Webpack with Polymer.

Many other complaints about Polymer that I won't go into. It's way too green
in my opinion and I'd recommend avoiding it for at least the near future.

~~~
ergo14
I got into same problem you had - the trick is to have view/parent components
not use Shadow DOM - then you can use normal css styling, or alternatively
prepare a `shared-styles` file that will contain styles shared across
elements.

IMO having everything inside Shadow DOM is an anti-pattern.

I use my own pipeline based on gulp so I don't know much about polymer
bundler, webpack support was recently added though, I haven't used it yet.

------
jvvw
For anybody looking into vue.js for the first time, I highly recommend
starting with Laracasts series of screencasts which I found much more helpful
than the information on the vue.js site itself when I was getting to grips to
with it:

[https://laracasts.com/series/learn-vue-2-step-by-
step](https://laracasts.com/series/learn-vue-2-step-by-step)

------
jameslk
These are the things I find to be killer features of React and it's ecosystem:

\- React Native (I know there's Weex but it's not production ready, nor as
feature rich)

\- _Streaming_ server side rendering

\- React Relay (GraphQL integration)

\- JSX _by default_. VueJS pushes an Angular-esque template language where I
have to learn new syntax, binding concepts, directives and conditional
statements.

\- Corporate backing

I've used React in very large projects, where these features have been fairly
critical. React's licensing is odd but not odd enough for me to ditch it. I'd
really hate to see the community churn once again on frontend libraries, but
that's JavaScript for you I guess.

~~~
jaequery
i was in the same boat as you regards to syntax but in 10 mins you will grasp
everything about vuejs.

of all the frameworks, vuejs has the simplest syntax to learn. its no where as
complex as angular and way more elegant. also beats jsx in terms of making
your code more cleaner and prettier. im never going back to jsx.

~~~
dmitriid
Which part of this is clean or pretty?

    
    
       <button v-bind:disabled="isButtonDisabled">Button</button>
       <div v-bind:id="'list-' + id"></div>
       <form v-on:submit.prevent="onSubmit"></form>
       <a @click="doSomething"></a>
       
    

There are _some_ redeeming qualities compared to say, Polymer. But it's
neither clean nor pretty

~~~
chj
You can make it cleaner:

    
    
       <button :disabled="isButtonDisabled">Button</button>
       <div :id="'list-' + id"></div>
       <form @submit.prevent="onSubmit"></form>
       <a @click="doSomething"></a>

~~~
hansede
Vue allows you to use Pug syntax in your templates, so this can be even
simpler:

    
    
      button(:disabled='isButtonDisabled') Button
      div(:id='`list-${id}`")
      form(@submit.prevent='onSubmit')
      a(@click='doSomething')

~~~
scottmf
I'm sorry but that is hideous.

JSX is incredibly simple. Why would you do _that_ to yourself and other devs?

~~~
hansede
Eloquently put.

------
steinuil
What's with the hate for JSX? I think handling HTML as data makes much more
sense and is much more convenient than dealing with dumb templates or weird
DSLs like Vue's or Angular's.

~~~
mediumdeviation
JSX is closer to JS than HTML, which means it annoying to write in some cases.
Quick, what does this render as?

    
    
      <a href="...">Link 1</a> |
      <a href="...">Link 2</a> | 
      <a href="...">Link 3</a>
    

It's not

    
    
      Link 1 | Link 2 | Link 3
    

as you'd expect - instead, the whitespace after the pipe character is eaten by
JSX. This is because HTML is whitespace sensitive, but JS is not, and so to
allow indentation, JSX trims whitespace.

Here's another -

    
    
      <dl>
        { Object.entries(definitions).map(([term, definition]) => (
           <dt>{ term }</dt>
           <dd>{ definition }</dd>
        )}
      </dl>
    

This does not work - instead, you need to return an array, but the result is
ugly - the commas are part of JS, not HTML, and don't appear in the output,
but reading this quickly it's hard to see that (the difference is the braces
surrounding the block).

    
    
      <dl>
        { Object.entries(definitions).map(([term, definition]) => ([
           <dt>{ term }</dt>,
           <dd>{ definition }</dd>,
        ])}
      </dl>
    

Vue's 'weird DSL' _is_ HTML (the same is not quite true for Angular's). What
you see is exactly what you get. Having a DSL also means you can define your
own syntax. Things that are verbose (due to historical reasons in JS), such as
iterating over an object, can be made simple -

    
    
      <dl>
        <template v-for="(definition, term) in definitions">
          <dt>{{ term }}</dt>
          <dd>{{ definition }}</dd>
        </template>
      </dl>

~~~
steinuil
Good point about the whitespace, but I'd still rather have the templates
inside my code than separate the two, mentally parsing two separate languages
with different syntax and stitching them together is a lot more mental
overhead IMO.

~~~
mediumdeviation
It's a matter of personal opinion, but I guess I'm more used to server-side
templating languages, which Vue's looks much more similar to. I have the same
problem as you for JSX - I keep trying to read it as HTML, except it's not,
and mentally translating it is annoying.

------
zpr
One of the biggest things React has going for it, other than being maintained
by Facebook and having a much larger community, is React Native. You can learn
one web framework and now also make compelling, real native apps. To me those
are both deal makers.

Surprised I haven't seen this mentioned more in the thread.

~~~
XCSme
Or you can just compile any HTML5 mobile app using Cordova and in 99% of the
cases your users won't notice any performance difference between native-app
and HTML5 app.

~~~
jdiaz5513
Maybe for extremely simple webapps that might be true, but for any non-trivial
Cordova+React based app you can't come anywhere close to the UX you can get
with React Native without some extreme engineering effort. I'd much rather eat
the cost to port the HTML5 app to React Native instead. Yes, the users DO
notice.

Inability to have the same level of control over soft keyboard behavior is one
of the top problems with Cordova, IMO.

Source: wrote & maintained a Cordova+React app on iOS/Android for 3 yrs.

~~~
XCSme
Yeah, you are right, I was mostly referring to the performance part. If you
need native UI elements or native UI interaction it's harder to do that in a
HTML5 app.

I mostly worked on games, where the UI is custom and there are very few
similarities to the UI of the OS, so it worked pretty good.

------
pasta
My #1: download vue(.min).js and you are ready to go. No packagemanager,
bundler and what not needed.

~~~
nightski
You can do the same with react. Unfortunately with either library you are
going to want it for any serious project.

~~~
k__
This whole "React is complicated" is a strawman.

How is JSX more complicated than any template language?

How are Vue components any simpler than React components?

~~~
yunyu
You can't write JSX without a template compiler (how ergonomic is it to hand
write a render function?). It's painful to write React components with just a
script embed (this might not be important to _you_ , but it's important for
newbies coming from jQuery), while Vue lets you get away with HTML attributes
and Vue.extend(). Lastly, Vue's style scoping is superior to anything React
has to offer.

~~~
k__
Hu?

You can write JSX with just script embed.

~~~
yunyu
..How? You'd just get a syntax error. Embedding a runtime babel compiler isn't
mentioned in the docs at all (though I guess it would work albeit killing load
performance, but it's not something that you would expect newbies to know,
especially if it's not in the docs).

------
IgorPartola
I happily used Angular 1 for a few things. When it became clear that Angular 2
was the party line, I looked at it and unfortunately found an overengineered
framework chasing what React was.

I looked at React, but without a cohesive framework, that ecosystem is just a
bit too much of a mess. A gazillion starter app templates that can't quite
agree and always seem a little out of date with the fast moving components.
JSX is just ugly. At least to me. I regularly use Django templates, so the
clean leap to Handlebars-style templates feels very natural to me. Redux is
straight up unapproachable to someone new to the concepts, but at the same
time it feels like it simply reinvents events and event handlers.

Vue was a revelation. It is simple, cohesive and I feel productive.

------
colordrops
I know this is about Vue vs React, but a lot of the things people are saying
they like about Vue can be found in Google's Polymer. It's very simple to
comprehend and you can make single file components. And it's based on W3C
standard web components so you won't be building yourself into future
obsolescence. With Polymer 2 components are now built using classes, so your
code is clear and 100% native JS. Lastly, the goal of the Polymer team is to
get rid of Polymer by advancing web standards, and with 2.0 you can see they
are definitely following this approach as Polymer doesn't add much to web
components other than ease of use functionality such as template binding and
cross browser shims.

~~~
mStreamTeam
I've used polymer and I wasn't impressed. I found it was much slower than Vue
and the docs left a lot to be desired.

~~~
colordrops
What was slow about it? Depending on how you use template binding, it should
be as fast as anything else.

~~~
Andrex
It's possible he was using Polymer v1, which was pretty slow.

Polymer v2 in a web browser that supports Web Components v1 should be pretty
fast, though. But that was only released last May.

------
coolvd1312
This discussion might just get a lot of light just cause of Facebook rejecting
the licensing issue.

~~~
Chirael
Absolutely. I just checked and vue.js uses the MIT license which would seem to
be much more startup (and investor) friendly than the React license.

------
codehaks
I used both react and Vue, and I would always choose Vue.js over react. beside
all the features Vue has, its the documentation that I really like. it makes
you want to read more and more.

------
JoshMnem
Elm is also promising: [http://www.oreilly.com/web-platform/free/files/why-
elm.pdf](http://www.oreilly.com/web-platform/free/files/why-elm.pdf)

~~~
Rotareti
I'm using react and like its functional approaches. I started implementing
libraries such as immutablejs, recompose and ramda. I also make use of pure
functional components exclusively. Then I had a look at Elm and I realized
that, with all the libraries I have put together, I created my own crippled
frankenstein'ish version of Elm. I think I really should give Elm a try!

~~~
grav
Agree that Elm is a good all-in-one solution for SPAs.

You should also give ClojureScript with the simple React-wrapper Reagent a
spin. All the functional stuff is built into the language, like Elm, albeit
without the types, which both has its pros and cons.

------
shams93
I don't know why inferno isn't more popular, I use a lot of html5 apis so for
what I'm working on inferno is more useful to me than react or Vue. I'm doing
webaudio so react native doesn't help me. Also inferno doesn't require me to
enter into a patent agreement with Facebook and yet I get all the benefits of
react from using inferno. Now if I were needing to use native APIs then I
might need react native but then you have to balance that need with the
potential license issues

------
bennyp101
I'm currently investigating Vue to see how it compares to the current React
code I have. So far I'm liking it.

The main things that I like so far;

* Single file components - I actually _really_ like this, I find it much easier on my brain to have everything related to a component in the same file.

* The router and data modules - having the router and Vuex as "official" parts of the ecosystem (as opposed to in React where they are "adopted") means that everything just clicks.

* Styling - when I first started out with React, it was a pain to find a nice way to do CSS - do you use modules? Just have files that you import? Inline? Having it automatically scope the styling to the component if wanted, or using modules if thats your thing - is so much nicer than having to think about it. I just add <style lang="scss" scoped> and I don't have to worry.

The only downside I have at the moment, is having to learn the "v-" bindings
(which is what put me off Angular when it first came out) but I think that it
is something I can live with. Although you can use JSX and have a render
method so I might try that and see how that flows for me.

------
bluepnume
For me, the best thing about jsx is the fact that it's so easy to create
different implementations of `React.createElement` to solve different problems
outside of the scope of React itself. Want a render function that uses jsx but
returns a string, a DOM tree, or something entirely different? Totally
possible! I didn't like jsx at first, but the fact that it's so decoupled from
React itself counts extremely in its favor, in my view.

For example, for one of my libraries I wanted a really simple way to allow
people to include custom templates. I started with string-based templates, but
quickly realized that this was inflexible for any kind of event binding or
later dom mutations. Achieving that was super easy with jsx -- I just
implemented a custom jsx function which directly outputs DOM elements.

Step 1: implement a jsxDom function [^1] which takes (name, props, children)
(e.g.
[https://github.com/krakenjs/xcomponent/blob/master/.babelrc#...](https://github.com/krakenjs/xcomponent/blob/master/.babelrc#L11))

Step 2: point babel to my jsxDom function (e.g.
[https://github.com/krakenjs/xcomponent/blob/master/src/lib/d...](https://github.com/krakenjs/xcomponent/blob/master/src/lib/dom.js#L938-L1015))

This even allowed some cool hacks like including iframes directly in the jsx,
to sandbox sections of the page (since the library is geared towards creating
components to be embedded on 3rd party sites):

    
    
      containerTemplate({ jsxDom }) {
        return (
          <iframe>
            <style>
              p {
                margin-top: 40px;
              }
            </style>
    
            <p>I can be sure the styles in this iframe won't affect the parent page</p>
          </iframe>
        )
      }

------
hammerandtongs
How are people getting along with Vuex vs Redux?

It looks pretty clean and grokable in the examples and deals with async out of
the gate -

[https://github.com/vuejs/vuex/tree/dev/examples/counter](https://github.com/vuejs/vuex/tree/dev/examples/counter)

~~~
mariusandra
If you use something like Kea ([https://kea.js.org](https://kea.js.org)), the
amount of boilerplate for Redux goes down dramatically. The syntax is actually
pretty simiar to Vuex, perhaps with even less boilerplate.

~~~
hammerandtongs
You've done a nice job with kea. The examples are pretty clear. Somehow the
selection of verbs and structure is more readable for me in the vuex example
but I'm not sure you could do much about that.

I won't be using this as it definitely sets off my library-depth spidey sense.

The multiple libraries it abstracts would all change versions over time and
lead my applications to be even more brittle.

Vuex being mainline with Vuejs is a major plus as I look at its long term
stability, though whether it insists on vuejs I need to look into.

~~~
mariusandra
Hey, thanks for the comments/feedback!

For the library-depth spidey sense, there's really no getting around that. In
a way, as React itself is just the view library, you're forced to add new
pieces to your app until it all clicks together. Kea is just one more of these
pieces... And I wrote it so the other ones would click together. The
alternative to abstracting libs like that is to write and bundle everything
yourself, but that is a hard and, in this case, unnecessary path to take.

Two of the libraries it abstracts (redux and reselect) are as stable as a
rock. There have been no breaking changes for many major releases. The third
one, redux-saga, is a bit more brittle, but as it gets passed direct control
over its domain, I don't see how kea would break anything there, at least not
in the near future.

Of course I'll do my best to keep up with new releases of all dependencies. I
do have a few apps with Kea that I actively maintain.

There's still the chance that Kea itself will change drastically. I hope not.
I'm actually trying to stabilise the API for a 1.0 release.

------
sudders
Go for Ember: \- Proven tech \- No licensing issues \- Solid community \-
Community driven, no company calling the shots

~~~
fny
I was a huge Ember evangelist until I started trying to onboard other devs
into my project. It took months for people to figure out which way was up. In
comparison, other devs picked up Vue in a week or so.

~~~
soneca
Interesting, because my company chosen Ember precisely because it would start
a hiring wave of new developers, often junior ones. Mostly because of Ember's
"convention over configuration".

I dont see much of this problem, including myself as one of these just hired
jr devs.

~~~
fny
The projects I work typically have very fast turn around times (2-4 months),
so I don't have the time to teach a dev use a framework, and I definitely
don't have the time to onboard junior developers.

I need a framework where any experienced JavaScript developer can pick up the
project and deliver working product in a week. With Ember/Angular/React+Redux,
I have to hunt for a developer that specializes in that particular framework.
With Vue, the hiring pool is vastly larger.

------
vladimir-y
Vue.js is going to win because simplicity and easier bootstrapping matter. In
the same time Vue.js is powerful enough for building the complex and scalable
apps.

~~~
danielharrison
Onboarding green devs into anything more than a simple Vue app is a lot more
complex than a React app of similar complexity, from my experience.

The simplicity of the nested, inception style architecture of React makes it
super easy to onboard and up-ramp.

~~~
zmmmmm
Couldn't disagree more. Or perhaps, more accurately, I think the scenario you
are referring to isn't the one that matters.

It's not about taking a massively existing complex application written using
one of VueJS or React and onboarding someone completely green into it.
Adoption is about "how easily can I incrementally adopt this technology into
my legacy app". And the problem is that React is nearly unusable without
switching entirely over to a Webpack / transpiler system and learning JSX,
which makes it almost a non-starter for someone who isn't planning a major
rewrite of their legacy app front end. By contrast VueJS "just works" after
dropping a simple JS bundle into a page and the first templates you write are
barely distinguishable from regular HTML. You can start by just enhancing the
odd page element here and there, and slowly build up to a fully based VueJS
app.

~~~
vladimir-y
> learning JSX

Not just learning, JSX/React.createElement approach is the hell itself, it
increases the technical debt every time you use it, but some people prefer to
make a blind eye to this. When juniors come to work with React I guess it
makes them think that React way is the only way, but it's more like the 10
years old PHP code.

Let's imagine that for some reason in 2-3 years there will be a silver bullet
like framework. So most likely hipsters will be going to switch to it and I'd
like to see how they will be cherry-picking all the template's parts from the
JS/JSX code to the single holistic template (I don't think the sliver bullet
like framework will follow the mixing template with code ideas).

------
baxtr
The single best argument for vue is that we should not support large internet
monopolies. vue is so awesome even more so once you realize that it is
basically driven by a single person

------
coding123
Actually my major complaint of React is the state of state. There seems to be
no common knowledge about how to do this right. I just joined a team that has
two React projects that development started about two months ago (I just
joined like a week ago). There is a a large component that I am working on
that is completely bound to Redux. There are major state update issues and the
team had opted to assign IDs and data to the DOM elements and use those to
look up state in the redux store before modifying it. On top of all that, the
application is completely unable to handle 2 instances of any component they
wrote. I am trying to re-write some of it to encapsulate the state in at the
component level. It's pretty awful compared to the Angular (not AngularJS) app
I recently rolled off of.

Edit : Also wanted to add, while I think a lot of people really don't like
JSX, I actually do like it but I think someone could take that aspect and come
up with a better state management system outside of redux and friends. I think
something along the lines of Angular (not AngularJS) with JSX would be great.

~~~
mmcnl
> There are major state update issues and the team had opted to assign IDs and
> data to the DOM elements and use those to look up state in the redux store
> before modifying it.

This sounds awful and seems like an anti-pattern. I don't think this anything
to do with React (other than perhapps that React gives you the freedom to do
things wrong). Your devs don't have a proper understanding how React (or Vue)
works. Define state model, define view, modify/interact with state, let React
modify view. That way you'll never need dirty hacks like fetching state from
Redux by using the DOM ID.

------
saganus
Maybe a bit off-topic, but not so much IMO.

Everyone talks about react, angular and vue.js. How about Polymer?

What are your experiences with it, if any? I'm no expert in either technology,
but Polymer seems much more lean, needs no build process as far as I know, and
is quite flexible.

Why wouldn't it be an option to replace react/angular/vue? Any thoughts?

~~~
ergo14
It is an option to replace other frameworks - I've built an SPA with it, it
was very clean and natural feeling to me.

Building Polymer components is very similar to building Angualar 1.5
`component()`s or react components (or actually any component system for that
matter).

New elements are true DOM nodes which is quite an advantage in my opinion.

You can add redux/uniflow on top of that or some vdom lib like preact too if
you need that - I wonder what will come out of `lit-html` that is supposed to
be vdom alternative.

One interesting thing one should understand that applications view components
that are not meant to reusable should NOT use Shadow DOM (just regular DOM)-
this way you can use bootstrap or whatever else to provide "traditional"
styling of your application.

BTW I think right now Polymer also requires a build process - because 2.0 is
written in ES6 so that means building to support older browsers like IE10/11.

------
_nalply
I experimented a little bit with Vue. I was a little bit disappointed about
two points:

1\. I couldn't CSS style a Vue component. I find components very important and
they should behave like HTML elements. It should be possible to write a
<video> element in Vue if that element didn't exist.

2\. I find the state management Vuex somewhat an afterthought. Some people say
you will know when you need state management, but I think if the integration
of state management is really seamless there is no need to avoid state
management even for the most simple apps. So don't listen to these people and
start with Vuex straight away, even if it takes a little bit more effort.

I'm sure that there are more points for an even better solution. However for
the moment Vue seems to me the simplest, the most elegant and most intuitive
framework. So I will use it for my future projects.

~~~
yunyu
One of the biggest selling points for single file components is styling (with
optional scoping): [https://vue-loader.vuejs.org/en/features/scoped-
css.html](https://vue-loader.vuejs.org/en/features/scoped-css.html)

If you need to override child component styles from a parent (bad idea in
99.999% of cases), /deep/ would work.

~~~
_nalply
Vue components are second class citizens compared to HTML elements, because
you don't style them, you pass them props.

This idea with stylable components is for a different framework, perhaps.

------
mycat
Vue.js is like perl. Too many ways to do a single thing

~~~
erichdongubler
Out of curiousity, examples?

~~~
k__
They bait newbies with their easy data-binding and switch them to components
later.

------
obilgic

        In React, everything is just JavaScript. Not only are HTML structures expressed via JSX, the recent trends also tend to put CSS management inside JavaScript as well. 
    

for me this is the deal breaker, just JS should be enough.

------
mshenfield
The conciliatory tone is refreshing - as a community it doesn't have to be a
"Vue vs. React" death match. Both are reasonable approaches that incorporate
some pretty dope technology in slightly different ways.

------
jrs95
For what it's worth, I tried Vue first and ended up moving to React and it
just seems to click better with me. More/better libraries too. Nothing on the
Vue side of things is as good as Material UI.

~~~
okramcivokram
There's also [http://vuematerial.io](http://vuematerial.io)

~~~
equasar
Vuetify is better IMO: [http://vuetifyjs.com](http://vuetifyjs.com)

------
kiwee
Vue is good for simple things. But it do not shines for complex apps and
sometime makes it even harder than it should be. React can appears complicated
when beginning, but it pays off on complex apps.

~~~
tomduncalf
This is the impression I get, but I've not got any Vue experience to back it
up so it's literally just based on first impressions.

I completely agree that React can feel like overkill for simple stuff, but
really shines as the apps get more complex - complexity feels a lot more
manageable.

For example, I built this in-browser Illustrator-inspired site/app using React
and couldn't have imagined doing it without (in terms of making managing state
and reasoning about things easy as the app grows more complex):
[http://f37foundry.com](http://f37foundry.com) (the type tester on the desktop
homepage, apologies for limited browser support!). Curious if you could do
that sort of complex app with Vue.

~~~
majewsky
> please visit this site using some recent version of [browser that sends all
> your data to Google]

 _slowclap_

If using a JS framework means you don't have time to test your website in more
than one browser, I'll happily continue writing plain JS (or better yet, no
JS).

~~~
tomduncalf
It's just the type tester element which is not accessible with browsers other
than Safari or Chrome, because there's quite a lot of CSS trickery/hacks to
make it work which didn't work in Firefox.

As mentioned in my other comment, due to the target audience it was decided
that it wasn't worth the investment to get it working on other browsers right
now, but the rest of the site should still work.

Not React's fault, just a lack of time/budget and a lack of native browser
support for advanced typography.

------
davidw
Not knowing much about either one, I find 'scaling down' very appealing. I
recently did some work with Angular 2, and found it very distasteful because
of the big learning curve.

------
baybal2
Angular - has appeal for "corporate apps," well, because of Angular 1.*

React - has influence wherever Facebook has influence

Vue - took off in China as FB did not bother to proselytize developers there

------
tycho01
Dunno if it's just me, but I read these Vue articles and all I see is a bunch
of hypocrites with an identity crisis, criticizing React for fragmentation,
Angular for having 'one Right Way'. So they're better than React for offering
one Right Way, then they're better than Angular for offering fragmentation? I
mean, jeez, pick one stance and stick with it.

------
chj
I checked React, didn't like JSX, then I find out about vue, and after an hour
or two into its guide, I am completely hooked. Especially love the fact that
you don't need a compiler, or a node installation. Although single file
component looks very nice, I don't want to "bring in a whole jungle just to
have a banana".

------
kraf
I prefer React. I do like a lot of the ideas in Vue.js, but when it comes down
to it I prefer the lower abstraction level of React.

Where React wins for me:

\- Higher order components \- Stateless functional components \- React 16,
especially the scheduler

Also I really like building the virtual DOM directly (JSX) but that doesn't
seem to be very popular reading the other comments.

------
baybal2
It surprises me how this "vue vs react" gets to the first line for the 10th
time in one or another form

~~~
seattle_spring
Let me guess-- you're going to argue that "shills" are behind the quick rise?

~~~
baybal2
Tell why should I?

------
taphangum
If anyone is interested in more Vue talk and some back and forth, check out
the VueJS subreddit here:
[https://www.reddit.com/r/vuejs](https://www.reddit.com/r/vuejs). It's
probably the most active VueJS community online.

------
xxxmaster
This part of the documentation is pretty unchanged for the last 6 months I
think, how come it gained so much attention today? We've been using Vue
instead of Angular 2 and we are pretty happy with our everyday work. So +1 for
the VueJS team.

------
hellofunk
So Vue is based on the same Virtual DOM as Elm, or its own implementation? Do
non-react tools in this arena still have react-like lifecycle hooks, or
different ways of handling "on mount" behavior, for example?

~~~
hanley
I'm not very familiar with React, but Vue does have lifecycle hooks that work
well: [https://vuejs.org/v2/guide/instance.html#Instance-
Lifecycle-...](https://vuejs.org/v2/guide/instance.html#Instance-Lifecycle-
Hooks)

------
crisopolis
I'm curious Vue.js has always had this comparison guide. Why re-post it now?

------
Xeoncross
I use material design. Angular and React have the best MD libs as of a month
ago.

I also make mobile apps. Angular and React have the best native apps as of a
month ago.

I use old devices. React and Vue are the most responsive.

Large companies use React on desktop and mobile.

React it is.

------
jaequery
i sense there may be a flood of react devs switching to vuejs. once their
react projects are finished.

honestly react devs are missing out on how great the vue experience is. it
didnt take me too long to see how much better vue is.

~~~
growtofill
I would say that experience-defining tools are webpack-dev-server with hot
reload, ability to use modern ES features and type definitions via TypeScript
or Babel+Flow.

These are available for both Vue and React. Is there something on top of that
available for Vue?

~~~
jaequery
[https://nuxtjs.org/](https://nuxtjs.org/). here you get all of that out of
the box

------
DonnyV
A lot of people don't know about RactiveJS
[https://ractive.js.org/](https://ractive.js.org/). Which I think is better
and easier to use then most.

------
sheeshkebab
Vue feels like a framework written by AngularJs developers. It's not "better
React", it's more like better angularjs.

Html templates are a major turn off for me there, and using JSX is not
optimal.

------
mrtracy
As someone who has been maintaining a growing React/Redux app for a while now,
this one has kept me up at night.

The main arguments in favor of Vue.js revolve around the idea that it is
easier for new developers to understand; that people can pick it up and
immediately be productive, with React/Redux being much harder to understand.
As someone who wants to onboard new developers onto my project, it makes me
wonder if I need to look into a switch, if not for my current project then for
the next one.

A lot of the commonly touted differences are either a wash, or are only
benefits for very small applications with perhaps a single developer. These
would be Templates vs. JSX (This is a wash, they're the same thing, but this
maybe even favors JSX for large applications), running Vue.js without a build
system (you will want a build system regardless for any production
application), "Two-way data binding" (Fools gold, will cause horrors if you
ever use watches, you will end up hoisting almost all of your data to Vuex
anyway in a production application) and "Single-file components" (Really
skeptical that this will make a difference in development vs. any other
organizational strategy). I can expand on any of these, but they've already
been discussed to death.

\+ Where I think Vue.js is _actually_ superior to React:

Vue.js is quite opinionated and clear on where to put both data and computed
properties. That's basically it, but it's a huge difference.

React itself is _very_ hand-wavy about where to put data and how to interact
with it; it basically leaves the problem for someone else to solve. Even
Redux, which is designed specifically to store application data, has a weird
interface to connect your data to the React application and has _no_ opinion
on where to put computed properties. React-router suffers from this same
problem as well; you basically end up looking for blog posts on Medium to
figure out how to construct an actual SPA out of these components.

This is a gigantic failing of the React ecosystem, and I think this represents
almost 100% of the perception (or perhaps even reality) that developers
understand Vue.js better than React.

\+ Where I think React/Redux is still better

The React ecosystem takes a lot of inspiration from functional programming; it
prefers "immutability" and pure functions whenever possible, and I think this
becomes increasingly valuable as your application grows; not just for enormous
applications, but even for medium-sized applications.

Even if you're exercising maximum discipline with Vue by hoisting your state
to Vuex, you've still got many opportunities to create difficult bugs based on
the mutable state. Are you sure you're not referencing mutated state in one
your actions? Does one of your components hold onto mutable state in order to
do a custom transition or animation? If you're using watchers, you're really
risking some dangerous bugs here. Now, I know _you_ probably won't do
something silly like this, but as your development team grows and you can't
code review everything going in anymore; can you vouch for everyone on your
team not to make a subtle mistake with a mutable reference?

React/Redux also enables a few very useful patterns that Vue/Vuex doesn't
offer at all. For example, the famous optimistic application is nearly a
first-class use case for Redux, but would be quite difficult to implement in
Vue. This doesn't matter for small applications; it _does_ matter for large
applications. Will it matter for your medium application? The same thing about
Isomorphic rendering; Redux was built with this squarely in mind. It won't
matter for your small app; are you planning for your app to be small forever?

Finally, because it is all Javascript, I think React/Redux has a much better
ecosystem of tooling. That includes both linters and transpilers; for example,
writing Vue in typescript isn't especially natural, but it works _great_ with
React/Redux. When considering my own purposes, effectiveness with Typescript
is one of React/Redux's greatest advantages.

In summary, I would still maintain that React/Redux is better for medium to
large applications than Vue, due to its commitment to pure JS and the
inspiration it takes from functional programming. However, I definitely see
the appeal of Vue.js, and I wish that the React ecosystem would take a note on
how to provide clear opinions for developers.

------
andrew_wc_brown
MithrilJS

~~~
porsager
Oh if only mentioning mithrils name would be enough to explain it's benefit I
think a lot more people would be using it, but we need to do a bit better than
that. Mithril is one of the few libraries that really embraces JavaScript and
the beauty of a clean abstraction and lean API. There's no heavy learning
curve, just learn a couple of method signatures, and you're ready to go. Once
you need to do something advanced or use a third party library mithril won't
be in your way! I still haven't seen anyone happily go back to react or vue
for that matter after experiencing mithril.

[https://mithril.js.org](https://mithril.js.org)

~~~
tropshop
I left mithril for domvm. It has a smaller focus and less magic.

[https://github.com/leeoniya/domvm](https://github.com/leeoniya/domvm)

------
msoad
Is there a compiler for Vue components to web components?

I'm worried about forward compability of all this React components I'm
building

------
dcsan
it seems odd that vuex is part of core but there isn't a default way to do
get/post requests. [http://jrmeyer.github.io/tutorial/2016/02/01/TensorFlow-
Tuto...](http://jrmeyer.github.io/tutorial/2016/02/01/TensorFlow-
Tutorial.html)

------
erdle
These are the threads that are often to the most frustrating to picking
anything...

------
iwebdevfromhome
If the licensing is an issue with React, then what about Preact?

------
tomelders
Ugh. Vue.js is just Angular 1.

------
idibidiart
I have to many points associated with this handle. I'd like a 100 or so shaved
off

React is for CS-savvy programmers. Vue is for those who like to think of
themselves as programmers.

------
holydude
I would go with react just because it is more popular. Unless you are someone
with free hand picking a technology that is more widespread (hence more in
demand) is in this era the wise choice to make.

~~~
hobofan
The demand for both React and Vue.js is growing tremendously. There isn't
really a wrong choice to make here.

(I would also say the same goes for picking programming languages, as long as
it's one of the top ~15, and you stay somewhat flexible.)

~~~
azr79
There is way more demand for Angular and react than there is for Vue

