
Why we chose Vue.js over React - jetter
http://pixeljets.com/blog/why-we-chose-vuejs-over-react
======
guntars
The arguments against JSX and React requiring many small components are very
surface level and sound like "we couldn't figure out how to make it work for
us so it must be impossible".

1\. This was mentioned already, but, yes, you can use ternaries and boolean
logic for simple conditionals (loggedIn && <a>Logout</a> || <a>Login</a>)

2\. When you need more markup, put them in an if-else statement in the same
render function.

    
    
      render()
        if (loggedIn) {
          var login = <a>Logout</a>
        else
          var login = <form onSubmit={ ... } />
        
    
        return <div>
          { login }
        </div>
    

3\. With SFC it's trivial to split these out into new components. You can even
use bound methods to reuse the component state and props.

    
    
      class Navbar {
        LoginForm = () => {
          if (this.state.loggedIn) { ... } else { ... }
        }
    
        render() {
          const {LoginForm} = this
          return <div>
            <LoginForm />
          </div>
        }
      }
    

4\. And finally, what stops you from creating a custom component that works
like this?

    
    
      render() {
        return <If cond={ this.state.loggedIn }>
          <Then>Hello { this.state.userName }</Then>
          <Else>Please log in</Else>
        </If>
      }
    

There's a continuum of ways you can structure your code, it just takes some
experimentation to find what works for you.

After working with Angular templates for a long time and then switching to
JSX, I'm never going back to having my markup in a string blob with magical
attributes that make it do stuff.

~~~
olegkikin
Wow. Do people consider this kind of coding acceptable now? We spent decades
trying to separate templates, business logic, and inlined JS, and you managed
to cram all three into a short snippet.

~~~
madeofpalk
It's actually no different to any other templating solution. Take a look at
this[1] Mustache.js example and note the logic! At least JSX is honest about
what it is.

[1]:
[https://news.ycombinator.com/item?id=13153298](https://news.ycombinator.com/item?id=13153298)

~~~
orange8888
I guess honest can be a nice way of saying more verbose, just like elegant is
another way of saying more terse and simple for those who get it

------
welanes
One of the most impressive thing about Vue.js was the ability of the framework
to enter a field saturated with dozens of options, that was becoming dominated
by a well-resourced oligopoly (Angular, React), and still win over developers
jaded from Javascript-fatigue.

The _give-a-shit_ factor from Evan (the creator) is extremely high and was key
to its success.

Inspiration for anyone building a product in an established market: there's
almost always room for better.

~~~
devoply
The reason for its success is good documentation and simplicity. Anything like
this aims to empower users, and get the fuck out of the way and let them do
their work has a space no matter how crowded the market.

Angular and React want you to do things their way and therefore get in the
way, and then make you do a bunch of work to make things work their way. I
have a PHP app that I rigged up using Vue.js. Took two days to do. Had to
change nothing in the app, instead of rendering views with PHP they are output
using JSON simple enough. Powerful. Can't do that with Angular for sure. Don't
have time to deal with react and its nuances.

~~~
kentor
What does "want you to do things their way" even mean? Aren't you doing things
a certain way by virtue of using a framework? Maybe angular/react is just
making you do things in a way that you prefer not to, while vue.js is making
you do things in a way that you find reasonable. For other people, it's the
reverse.

~~~
a-real-dinosaur
If you have to do things in a specific way, then you are forced to learn that
at the same time as you are learning the technology. Learning just vue on the
other hand, is much easier when you can retrofit your existing knowledge into
it. Then worry about the 'proper way' later when you have made your first few
apps. I already have boatloads of knowledge, and whilst it may not be '2016',
it's been good enough for the past 5 years.

React on the other hand, whilst it gets described as 'just the view', but I
haven't seen a single tutorial that uses anything other than React/Redux to
drive it.

To even get started in React, you need a babel, npm, gulp or webpack, node and
a data-store of your choice. On top of this, any of the tutorials you can find
from a full-stack perspective get made obsolete within months. This is
javascript fatigue, all you have to do is look at this recent article.

[https://www.fullstackreact.com/articles/react-tutorial-
cloni...](https://www.fullstackreact.com/articles/react-tutorial-cloning-
yelp/)

It makes me wonder how many 'npm install' developers actually understand what
is happening under the hood. This is not worse than the DOM ignorance that
jQuery causes IMHO.

~~~
ng12
> To even get started in React, you need a babel, npm, gulp or webpack, node
> and a data-store of your choice

This is patently not true. You don't need any of that to make a React app --
you can just download the min.js files and get coding. React is perfectly
capable of handling it's own state management and webpack/babel/npm are just
to make your life easy. The problem is people follow full-stack, real-world
tutorials like the one you linked without first just learning React.

------
pacnw
I've used Vue pretty much daily over the last year in a fairly complex app
(some 150+ components, Vuex store with 100+ actions, full client side router
navigation) and it has been pretty pleasant. I even contribute a nominal
amount to the Patreon campaign. However, the upgrade path from v1 to v2 is not
a quick undertaking. Certain changes require a revisit to practically all
components (e.g. change of 'ready' to 'mounted', v-el to ref etc.) that don't
really bring a lot of value to the end user other than change in semantics.
The upgrade diagnostic tool is a great feature, but seeing 600+ breaks in your
app is not so much fun. Changes in Vuex (e.g. no more vuex: getters in the
components, 'dispatch' is now 'commit' in the store modules) translates to
significant work in a largish app just to upgrade semantics. Also, the article
references the verbosity of Redux with respect to forms. In all fairness, all
Flux implementations, including Vuex, have pretty much similar verbosity.

Just providing some balancing thoughts for folks to be aware of before
investing heavy time in any framework, including this one.

~~~
agumonkey
I just heard about vuex, any curated resources about it ?

~~~
pacnw
The main Vuex docs are quite good, with the included shopping cart example.
[https://vuex.vuejs.org/en/](https://vuex.vuejs.org/en/)

------
sergiotapia
My man, a lot of the pain described in this article can be solved by Mobx:
[https://stackshare.io/mobx](https://stackshare.io/mobx)

One of our engineers at StackShare[0] suggested it and it's fantastic.

Mobx is very simple to understand and will make writing a "React" page a real
joy again. Redux was way too complicated for what it gave, and just shot term
after term after term at me that left me with a headache. I still don't
understand Redux proper.

>Why do you have to type so much?

I know! I nope'd away from Redux because of that same reason.

But Mobx clicked for me. And if it clicked for me, it'll click for you.

Basically you have a store and you use that store anywhere in your components
to share store state. When you update that store state everywhere else updates
as well. Simple.

Another great reason to use React as opposed to alternatives is react-native.
A _lot_ of knowledge transfer between the web and mobile with react native.
It's pretty insane.

[0] -
[https://stackshare.io/stackshare/stackshare](https://stackshare.io/stackshare/stackshare)

~~~
Kiro
> Simple, scalable state management

[https://github.com/mobxjs/mobx](https://github.com/mobxjs/mobx)

It says "simple" but looks complicated. Any pointers? Is it because I don't
know how decorators work it looks complicated?

~~~
inglor
MobX is _incredibly_ simple.

If you have a property you need observed - add a `@observable`.

If you have a react component you want to update automatically, add
`@observer`.

Derive as much as you can using `@computed`. You can but shouldn't use
`autorun` which monitors side effects.

If you're already used to Vue it's very similar except it works with React.

That's pretty much it - just clone a boilerplate - the API surface is _tiny_
and everything "just works". I have a hard time describing how stupid I felt
for using Redux after playing with MobX for 10-20 minutes.

~~~
eiriklv
I get the feeling that the terms "easy" and "simple" are being mixed up here.
MobX is a lot more complex than Redux (core), as it tries to do a lot more
things that are braided together as a package. In Redux you choose to bring in
that complexity (reselect, redux-saga, etc) if necessary. "Easy" is
subjective, "simple" is not.

~~~
inglor
Save me the Rich Hickey talk.

MobX is dead simple, it's a short write and here's how it works:

\- observables: add a getter/setter pair in place of the property - when it
gets modified emit an event. \- observer: when an observable getter gets
called inside the `render` in React - listen to future updates and re-render.
\- computed: do the same thing as observer - but emit the value instead of
rendering.

All MobX does is change detection, it has a very low API surface, it can be
implement in a lot less code (but optimizes heavily) and it is one of the
simplest packages I worked with without middlewares and connectors and
selectors and so on.

In Redux you have a dispatcher, actions, a reducer and so on. In MobX you just
have plain JavaScript objects for state and plain functions. MobX also
composes much better with things like Rx.

~~~
jolux
Redux core is like less than 60 LoC. It can't possibly be more complex.

~~~
cocktailpeanuts
Except it is. I have worked on a couple of react/redux production projects and
they all work well, but I still think redux is way too convoluted for most use
cases. Too many abstract concepts.

Also their naming of the features could have been better. For example
"reducer" makes sense ONLY after you understand what's going on. It should be
the other way around--the naming should be intuitive enough to actually help
me understand the concept easier.

A lot of physics theories are distilled down to a single equation, but that
doesn't mean it's simple concept to understand. I personally think a library
with 10000 lines of code that operate using setters and getters is much more
simple to understand than a library with 100 lines of code that has all these
esoteric concepts.

------
fnordsensei
I'm a designer and not a coder, so I feel obliged to provide my comments with
salt added up front.

That being said, JSX vs. wrapping HTML in if-statements seems like the same
kind of trouble to me. I've done a few simple prototypes in Clojure/Script, so
my reasoning is heavily influenced by the fact that I know very little about
other languages, and only have moderate amount of knowledge about Clojure.

The solution I've encountered in Clojure is to represent the entire page as a
data structure. Conditionals and transformations are applied directly to this
data structure, which is then sent as-is into the rendering pipeline (which
commonly seems to be React). The HTML is never really written by hand, it's
just a final "coat of paint" on top of the data.

To me, this seems far easier to wrap my head around than splicing two
languages together in the same file and potentially finding that the
interaction between the two is not as harmonious as one may wish.

Rendering _to_ HTML, rather than rendering _within_ HTML (so to speak), seems
like it would remove the entire decision point where you have to pick between
one library or the other based on the quirks of how it looks when it's spliced
into HTML.

~~~
mark_edward
Can you tell me what clojure libraries/frameworks work the way you describe?
I'm learning clojure and would like to build some toy web apps because I've
never done webdev before.

~~~
serpix
All you need is re-frame. It is well documented and the philosophy is
explained as well.

~~~
fnordsensei
Thanks for the tip, I enjoyed their comprehensive readme. I might give this a
go next time around.

[https://github.com/Day8/re-frame](https://github.com/Day8/re-frame)

~~~
bschwindHN
Definitely try it sooner rather than later, it's good stuff. I feel like re-
frame is what you would get if you put the time into selecting the best
libraries to integrate with React, and then removed as much boilerplate as
possible.

------
jplusplus
I believe React is popular (among other reasons) because you don't need to
learn what is v-if v-else and other repeative commands when you have plain and
simple JS equivalents.

React has te philosophy "It jusy works", and people love this

~~~
k__
Yes, I think the main selling point of React is it's tiny and intuitive API.

I don't know how these frameworks compare in bigger sized applications, but if
you just do a POC in Angular2, React and Vue.js, then React beats all of them.
This probably leads to many people considering React for their new
applications.

If you go for bigger stuff, I don't know which would be better. I like React,
but I also found it a bit cumbersome to create all these Redux actions and
stores etc. Also async stuff, especially righ datarate websocket stuff, seem a
bit awkward with Redux.

~~~
Bahamut
Do you have numbers? Angular 2 is quite small if you're using treeshaking.

~~~
boubiyeah
Not really; it has a big unshakable core

~~~
Bahamut
Got numbers? I know someone who was able to get a simple app down to below
30kb including polyfills (albeit with a lot of work using Google Closure), and
from what I understand that was before AoT compilation was there.

Much of the core is shakeable, I don't believe your assertion at all. As you
use more features, the app size would grow would be true due to using parts
that were previously shakeable becoming unshakable, but that complexity being
in a unified language/base of a framework worked on by very smart people is
most of the time better than homebrewed business logic by an above average
developer

------
straye
If you prefer html templates you're going to choose a framework like Vue,
Angular or Svelte. If you prefer Javascript driving the show you'll be more
comfortable with something like React. The two approaches are duals of each
other.

Personally I prefer an all JS solution because it's better suited to handle
conditions and loops as compared to using custom SGML markup with framework-
specific tags and attributes. In my opinion SGML/XML should only be used for
markup, not program logic.

There are a few things I think React got wrong though - handling of children
being one. Having different code paths to handle a single child versus
multiple children was a design mistake. The Children convenience module is
awkward to use. The state life cycle and immutability in React takes a while
to get used to. It does seem more complicated than it needs to be and has
spawned a plethora of React state management add ons.

~~~
tannhaeuser
I agree about conditionals and other kind of programming language constructs
not belonging in markup. But the point of markup for content-driven web sites
is that its a text format and can be contributed by persons other than web
developers (authors, site users, syndicated content providers, etc).

You can see a modern approach for this is at work here:
[http://sgmljs.net/docs/sgmlweb.html](http://sgmljs.net/docs/sgmlweb.html)
("isomorphic" rendering to HTML in the browser and server-side using full
SGML, no less).

Disclaimer: my project

------
kimshibal
Our company migrated to vue.js, 6 months ago. Our complex app is messy with
JSX, router, and new dev can't keep up with code. Now we start every new app
with Vue.js. The gap between junior dev and senior dev comes closer. They can
collaborate with less bugs, less problems and less time to develop.

~~~
jackyb
Interesting. I'm also looking at Vue.js and wondering how it can benefit me.
Just one thing that I want to know: how do you do checks and tests in it? Are
there any frameworks or tools to do that?

------
caleblloyd
> Fun fact: Yii was created by a Chinese speaking guy - Qiang Xue. So, you
> might call Yii+Vue stack not just very difficult to pronounce, but also a
> Chinese stack :)

Fun fact: Qiang Xue got his PhD at Duke University and developed Yii2 while
living in the D.C. Area by leading a multi-national team of core contributors,
the top 3 being from Germany, Russia, and Ukraine.

He also moved on from the project mid-2015 and the other maintainers have run
day-to-day operations since then. It's not a "Chinese stack". I've read the
source and issues extensively and it is high quality code that welcomes high
quality contributions - no matter where people are from.

~~~
jetter
I was never trying to put anything negative into this statement that both
these bright people are Chinese-speaking. I know they both live in US (though
it might be unfortunate for us that Qiang is currently doing Go programming in
Capital One instead of actively developing Yii2). Yii2 and Vue.js are top
notch.

~~~
caleblloyd
I didn't so much read it as a negative, it's just that readers unfamiliar with
the projects may think that "Chinese stack" means 1) code/issues are in
Chinese and/or 2) the main contributor base is located in China.

I've been a long time user of Yii1 and Yii2. Qiang has created 3 PHP
Frameworks between 2004-2015: PRADO, Yii1, and Yii2. At one point he was on a
>700 day commit streak with work on Yii2. I can't blame him for needing to
focus on his own professional career - OSS doesn't always pay the bills and
can be very demanding.

~~~
jetter
I agree with you, and I definitely do not blame Qiang on choosing his way. I
just miss him as Yii2 contributor and visionaire because that could make a
real competitor to Laravel some day, in terms of community, and popularity
across US and Europe. Right now Yii2 seems to move in direction of becoming a
niche framework for Eastern Europe and parts of China, instead.

~~~
caleblloyd
I agree, I miss Qiang's visionary leadership on the project also. Given his
history of building frameworks I'd say there's a good chance of him doing
another. It may not be PHP next time, though.

I wonder if Yii2 adoption moving more towards Eastern Europe and China is more
a macro trend of PHP in general. I feel like US firms are typically choosing
other languages when starting new projects based off postings and job boards
I've seen recently. Maybe my view is tainted from reading too much HN though,
PHP doesn't get much love here...

------
tyingq
I was initially confused about why a Drupal shop would need either Vue.js or
React, since Drupal sites are most typically blog like things.

Appears it's for their backend though, and this is actually pretty nice:
[http://pixeljets.com/sites/default/files/why-we-chose-
vuejs-...](http://pixeljets.com/sites/default/files/why-we-chose-vuejs-over-
react-282.gif)

~~~
fabian2k
Drupal is a bit overkill for a blog-like site, my impression is that it is
usually used for more complex sites than e.g. Wordpress.

With the latest version Drupal 8 there also was a push to make headless Drupal
easier, which is pretty much just the Drupal data exposed as an API so that
you can create SPAs for it.

~~~
tyingq
More complex, sure. But it's still very centered around taxonomy with
dates/sections, end user editing of nodes with WYSIWYG, page centric tags,
etc. Very blog like.

Seems like a big hammer for use as a datastore for an SPA.

~~~
snurycombinator
That was true back in Drupal 6 in 2008.

Drupal 7 and 8 use entities, which are arbitrary combinations of fields that
can be composed through the UI and accessed through APIs via JS or other
methods.

One thing we use it for is its user management which is good enough out of the
box.

------
joatmon-snoo
Out of curiosity, one reason the author mentions (and I know, it's not his
selling point) which I've seen others reiterate is that React's render()
method doesn't support if statements. I know you can write something like the
code below in React, so what exactly does that criticism refer to?

    
    
        function Home(props) {
          return (
            <div>
              <h2>HELLO</h2>
              <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p>
              { (() => {
                if (props.location.query.home) {
                  return ( <p>You specified a home query: { props.location.query.home }</p> );
                }
                else {
                  return ( <p>No home query was specified.</p> );
                }
              })()}
            </div>
          );
        }

~~~
M4v3R
Yeah, it's possible in React do to it. But compare that to how Vue handles
conditionals:

    
    
        <template>
        <div>
            <h2>HELLO</h2>
            <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p>
            <p v-if="location.query.home">You specified a home query: {{location.query.home}}</p>
            <p v-else>No home query was specified </p>
        </div>
        </template>
    

I don't know about you, but to me this code is 100% more readable than the
React example you gave.

~~~
insin
This is how I've come to write that in React, after giving up on attempting to
find a consistent way to write ternaries which I would find acceptable when
revisiting them (it just _never_ happened):

    
    
        let Home = ({location}) => <div>
          <h2>HELLO</h2>
          <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p>
          {!location.query.home && <p>No home query was specified.</p>}
          {location.query.home && <p>You specified a home query: {location.query.home}</p>}
        </div>
    

I usually put all the possible negative cases first because outside of micro-
snippets they tend to be short and sweet compared to the positive condition.

------
jolux
I hope I don't get downvoted for asking this but is React going out of fashion
already? A lot of the talk about it was "React is here to stay" or "React is
as permanent as JS itself" but now this is the second or third time people
seem to be going for Vue instead. What happened?

~~~
heysunshine123
Well, there's a difference between going out of fashion and being revealed as
something that shouldn't be used (like Angular and Ember).

Maybe Vue is just becoming the new shiny.

~~~
sotojuan
Ember should be used more often. It saves a ton of time with large apps and
has really neat plugins like FastBoot. It's underrated.

~~~
c0achmcguirk
I think the pendulum will keep swinging between the minimalists (React/Vue.js)
and the frameworks (Ember/Angular).

Ember is completely underrated and overshadowed by React right now. It takes
some of the best ideas from React (components, shadow DOM, FastBoot) and puts
them in a cohesive framework that has an incredible support ecosystem and
upgrade path.

------
thewhitetulip
It has been quite some time since I started writing front end code, tried
understanding angular, left it. I was lucky that I came across Vue.JS via HN,
it was gitlab's post. I haven't ever tried React, because Vue is amazing. With
nearly no knowledge of JS, I was able to write an app in Vue reading just the
official docs, they are downright amazing. I faced the issue of webpack et al,
thus I started writing a guide to write vue apps in vanilla JS,

[https://github.com/thewhitetulip/intro-to-
vuejs](https://github.com/thewhitetulip/intro-to-vuejs)

This is a work in progress.

I feel Vue is gaining ground because of it's simple syntax, there isn't much
magic to it, just enough magic.

~~~
jgorn
Thanks for posting. I've just had a quick glance over the first chapter of
your book and I like the simple approach you take to explaining the core
elements of vue.js and SPAs.

Will be keeping an eye on your progress.

~~~
thewhitetulip
Thank you :-)

I plan to finish everything off in the next few days. The chapter5 contains a
working version of the code, but it sure needs some refactoring.

If you want, I'll email you when the book is done. Leave an email id somehow
:)

------
anupshinde
Vuejs looks great for POCs or small projects. It feels better like Angular-1
to start with. I use VueJs a lot for small stuff i.e. usually something that I
can fit into one index.html file and forget about it. React killed that
simplicity (i.e. stopped supporting it). Angular2 - I can't figure out why
anybody uses that.

But when it comes to larger projects - I still go back to React, TypeScript
and Redux. While Vuejs makes it simpler to code, React+TS+Redux make the end-
product very much reliable.

~~~
mixmastamyk
More reliable?

------
rmason
One small point to add here. Evan You is a pretty amazing individual, but he
is no longer alone. There is a core team of six members.

I know because the guy who got me interested in Vue.js, Chris V. Fritz, lives
in the Lansing, Michigan area and is responsible for the excellent docs on
Vue.

I haven't been able to locate a list online but I know there's a core member
in Paris and another one in Japan.

~~~
codegeek
Other than Evan, could this be the list ?

[https://github.com/orgs/vuejs/people](https://github.com/orgs/vuejs/people)

~~~
rmason
You might be correct, heard that the core team would be expanding to 17. That
list is more than 17 but the names that I recognize are on that list.

Bottom line is that Vue.js is growing up to better handle the popularity it's
getting.

------
mstijak
I would recommend Cx to anyone building complex forms. It's one package that
covers all common problems related to forms - validation, data-binding, multi-
value lookup fields, horizontal form layout, theming etc.

[https://cx.codaxy.com/starter/admin/orders/1](https://cx.codaxy.com/starter/admin/orders/1)

Disclaimer: I'm the author.

------
halis
The author says they don't like purity and immutability, because it limits
their ability to "get stuff done". But in the long run you get many benefits,
whether you have 1000 developers or one. Namely that a whole class of bugs
will be eliminated and you can do quick reference comparisons to tell if
something changed.

Every time I go to look at Vue I can't stand the fact that it DOESN'T have
JSX. I've used every template system you can think of and they always fall
apart when things get hard.

JSX is basically JavaScript but a much easier and nicer syntax (basically
HTML).

You get the same flexibility with Elm, but even there you don't get the nice
JSX syntax:

ul [class "grocery-list"] [ li [] [text "Pamplemousse"] , li [] [text
"Ananas"] , li [] [text "Jus d'orange"] ]

The one criticism I happen to agree with is certain aspects of using forms in
React. Checkboxes and radio buttons are pretty buggy and stupid. Kind of
unacceptable at this point.

~~~
pm
If I remember correctly the latest version of Vue.js does support JSX.

------
TekMol
I am still unsure if there is a legit use case for Vue or React over plain
HTML+CSS+JS.

I can understand the use case for React native. To build native applications
on multiple platforms.

But what is the use case for React, Angular, Vue etc? Can somebody give a
minimal example?

~~~
edoceo
It's about maintaining complex UI state for me. Not sure how to fit that in a
minimal example. Those all look like Vanilla JS can handle it.

But when things get big, or sorta complex, or try to have very fine UI
behavior for complex workflows then React, Vue or my fave Riot really shine.

If it's minimal you don't need these. When it's not you'll be glad you have
them.

------
adamnemecek
It's been a while since I've needed a front end framework but if react doesn't
scratch your itch, you should check out cycle.js.

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

~~~
k__
Really good framework indeed. One of the few who are really good in handling
realtime data. Its dataflow-components are much more flexible than React
components, which makes it really more flexible.

~~~
adamnemecek
Also everything I've read from the author
[http://staltz.com/](http://staltz.com/) I either agreed with
([http://staltz.com/all-js-libraries-should-be-authored-in-
typ...](http://staltz.com/all-js-libraries-should-be-authored-in-
typescript.html)) or found really illuminating
([http://staltz.com/unidirectional-user-interface-
architecture...](http://staltz.com/unidirectional-user-interface-
architectures.html)).

------
ronocod
I'm not sold on the whole "code quality" vs "getting things done" mentality
here.

I think there are diminishing returns in reducing technical debt and keeping a
high quality codebase, but the point of doing it that you can maintain a
sustained, relatively high "getting things done" rate over the project's
lifetime. There are times where you should implement something in a quick and
easy way, but if code is going to be present and important for a long time
then going the extra mile usually pays off.

~~~
eternalban
> I'm not sold on the whole "code quality" vs "getting things done" mentality
> here.

[https://vuejs.org/v2/guide/comparison.html](https://vuejs.org/v2/guide/comparison.html)

Based on above, I don't think the dichotomy you pose is applicable in this
comparative case.

------
conradk
I've been using Vue.js at work for this kind of thing: [http://reassurez-
moi.fr/taux-pret-immobilier](http://reassurez-moi.fr/taux-pret-immobilier)

It was as simple as adding Vue.js itself and one JS file for custom code. I
tried using Angular but right off the bat, I had to install hundreds of
dependencies via NPM.

That's what I like about Vue.js. It's simple to reason about for the kind of
use case I linked above.

------
dirkg
The arguments against Redux (which this article doesn't really make, but
still) are very valid - it is a nice abstraction and way to think about data
flow, but its simply too much boilerplate.

Almost every Redux example is tons of repetitive code because of this, and
that's before you add in middleware, thunk, saga, reselect etc. Yes I know Dan
himself wrote a bunch of articles on how you don't really need to use it and
how its conceptually simple, none of that changes what most of the libs and
code looks like.

I don't have the answer but I can't help but think there has to be a better
way to handle this. We had templates and generics decades ago exactly to
reduce repetitive boilerplate.

Redux should never have been adopted in its current form. Its exactly the sort
of thing that should be handled by a framework/tooling for you. Imagine if for
every React component you had to write a custom parser/resolver/reconciler,
all of which had 99% common code and just passed params around. That's what
redux boils down to.

------
nojvek
Thanks for the detailed write up and comparisons. Also kudos for not bashing
other frameworks and giving a level headed comparison.

Two big things I noticed that drove you away from react.

1) too many subcomponents: I think jsx can be improved to have logic tags
within them. E.g <js:for> and <js:if> tags that the transpiler can move to
ternery and array map calls.

2) too much verbosity: something like mobx or deep-observable can help here.

Honestly react has become the Java of UI. Going back to fundamentals. All you
need is a tiny library that diffs a vdom tree to real dom.

And you need a tiny library that allows you to observe a single source of
truth object and connect it to view.update() changes.

All in all this shouldn't take more than 5kb of code.

We all want: good abstractions, fast performance, actionable errors and small
library so the page loads in no time.

------
butu5
Vue JS framework is very simple yet powerful, also better in performance wise.
Learning curve is very easy. You can pick the fundamentals in a day or two.
Within a week you can reach intermediate level.

It comes with all the basic stuff of SPA like data binding, event handling,
routing, state management, components.

I have been creating a video tutorials series on Vue js 2 framework.

Vue.js Tutorials:
[http://www.youtube.com/playlist?list=PLJ6Y8JfXAV-8_2lHNgP1Dh...](http://www.youtube.com/playlist?list=PLJ6Y8JfXAV-8_2lHNgP1DhCwvB6le3rty)

~~~
merb
what I always wanted how many Vue instances do I need for a SPA? Do I just
export every javascript object and register them globally? how does Vue.JS
work with DI?

------
dongslol
I find it completely unbearable to use React with plain JS. I have to use at
least Coffeescript and if possible Livescript or Clojurescript. Vanilla JS is
just too clunky.

The problem with JS is there are too many patterns in the code, like the
mentioned list.map(function(whatever) { ... }). Because JS is a medium power
language it doesn't let you abstract this stuff with macros or at least
rewrite the syntax.

Coffee and Live provide some relief, but Clojurescript is heaven.

------
jondot
While this is a good overview of why _they_ chose Vue over React, I wouldn't
risk deriving that you should do the same too.

To balance the scale a bit, this is what they gave up, in favor of "shit that
just works" (because this is the tone I'm getting from the article):

1\. They decided they want off the enormous driving force for developer
experience that is Facebook, and more importantly the Facebook codebase that
shapes decisions in React, see [1] and [2].

2\. They opted out of major innovation that directly stem from (1), see [3].

3\. Parting with Redux, they also decided to part with a community that thinks
functionally. This is a big deal not because of writing "pure functional
code", but because these group of people can reason about the implications of
bad citizenship on the browser - which really, is something the Javascript
community really needs.

4\. Moving away from functional-esque (for lack of a better term), they also
move away from predictable testing. Forget purity and sideeffects. A good
litmus test - think about how easy it is to test any given framework at scale,
and if a framework is "built with testing in mind" (read: angular) how many
hacks would be involved. When you have good foundations for testing, you can
do this [6] and be sure everything can be covered [7] .

The only thing I see as a down side with React is the bundle size. The
physical size. However I'm not worried one bit because of (1) and (2).

For Redux, I take the liberty to use MobX for small-medium projects (which
probably is the overwhelming majority of projects), and Redux for large
projects, or projects that I want great testing story in (in many ways these
correlate, but some times they don't).

Redux is "boilerplatey" because it is highly granular. This is why the
ecosystem around it exploded. But because of (3) the ecosystem around it has a
sharp focus around the patterns and practices it applies, which makes choosing
the "wrong" library not such a big deal; in a sense its ecosystem is
predictable, because it is simple.

JSX or templates, I don't think this deserve a major part of the discussion.
Both ideas exists for a long while, and even their predecessors exist for more
than a few decades [4] and [5]. I don't think anyone is tilting the scales any
where in a major way. I personally am convinced JSX is a new thing because you
have first-class IDE support across the board (which you don't have for a
given data-properties backed templating language unless it becomes ginormous
like Angular). JSX is also simple to hack and you can opt-out or implement
your own dumb-templating solution-to-JSX.

Having said that, I see Vue coupled with PHP quite a bit, like, it's an
informal standard stack, so it may make sense if you're coming from PHP (but
then again so did Facebook, right?). Maybe someone can explain that (is it the
Laravel backing?).

[1] [https://facebook.github.io/react/contributing/design-
princip...](https://facebook.github.io/react/contributing/design-
principles.html)

[2]
[https://facebook.github.io/react/contributing/implementation...](https://facebook.github.io/react/contributing/implementation-
notes.html)

[3] [http://isfiberreadyyet.com/](http://isfiberreadyyet.com/)

[4] [http://blog.vjeux.com/2013/javascript/jsx-e4x-the-good-
parts...](http://blog.vjeux.com/2013/javascript/jsx-e4x-the-good-parts.html)

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

[6] [https://facebook.github.io/jest/](https://facebook.github.io/jest/)

[7] [https://medium.com/@jondot/how-to-snapshot-test-
everything-i...](https://medium.com/@jondot/how-to-snapshot-test-everything-
in-your-redux-app-with-jest-fde305ebedea)

------
insin
I think your opinion on putting weird stuff in your HTML attributes vs.
putting weird HTML-like stuff in your JavaScript is enough to make an early
call on whether you'll prefer React-like libraries or Vue-like libraries.

As a programmer, React has been my go-to UI library for quite a while because
I see always being in JavaScript mode as a benefit (no invented scope to learn
or inject things into, no invented logic to learn, _everything_ is lintable,
easy-to-follow state change flow) that's worth the drawbacks (un-pretty
conditionals in render(), manually handling form input), but I can also echo
the feedback in this article when it comes to having designers working on your
components.

> JSX is also the reason when you have to keep splitting your 15-lines-of-
> html-code component to 3 components, 5-lines-of-code-in-each.

> ...this approach of splitting components into super-dumb components because
> of JSX restrictions will always put you out of flow when you are solving
> real business task

I don't understand what this has to do with JSX without an example.

> ...now you have to create 10 functions to get input from 10 inputs. 80% of
> these functions will contain single line with this.setState() call

Working with forms is definitely one of the most painful parts of React, and
one of the differences I most enjoyed when porting our sample app to Vue.js
1.x for inputs which only affect the value they bind (most interesting thing I
learnt: the React component structure the original was written with mapped
almost verbatim to Vue.js components, the main difference was in flexiblity of
what you can pass down the tree - e.g. React components as props, but I
believe Vue.js 2.x is now closer to React's flexibility), but most of this
section comes across as hyperbolic.

Writing onChange handlers which are as generic as you can get away with for
the current form is key, but it generalises to setting state based on input
names, which can as be simple as the name of the state variable, or a path in
state which should be set for simple form input even in deeply-nested forms,
plus the appropriate value based on the input type.

e.g. if you're doing a simple form with text inputs, selects, radios etc.
where checkboxes always correspond to boolean state, you could use this for
every field (you don't even have to put it on each input, you can let onChange
bubble up to a form with onChange={this.handleChange}):

    
    
        handleChange(e) {
          let {name, type} = e.target
          let valueProp = type === 'checkbox' ? 'checked' : 'value'
          this.setState({[name]: e.target[valueProp]})
        }
    

(It's game over for simplicity once you want to do _proper_ , user-friendly
form validation, but that's a truth universally acknowledged :))

------
juandazapata
I'm glad to see that Vue is getting more adepts. Kudos to the core team for
making it so easy and accessible for everyone.

------
johntran
"I expect Vue to become a primary JS framework in 16-24 months if Evan You
makes right steps, at least around backenders and smaller teams of
frontenders."

When Vue.js gets a big enough community passionate enough to host their own
conference, we'll be able to consider this as a possibility. :)

~~~
posva
Ha, well just wait for 2017

------
caub
I wonder why people need Redux, Using simply React is great and enough if you
understand it well

~~~
exception_e
React is just the UI piece of the puzzle. Here's a nice description of when to
use Redux:

"[Redux is justified when] you have a piece of data that needs to be used in
multiple places in your app, and passing it via props makes your components
break the single-responsibility principle (i.e. makes their interface make
less sense)" ([https://github.com/petehunt/react-
howto/issues/12#issuecomme...](https://github.com/petehunt/react-
howto/issues/12#issuecomment-169546558))

This comment was written for Flux, but it is completely applicable for Redux.

When building something non-trivial, there are other pieces you'll want to
pull in with React such as routing, messaging, etc.

~~~
caub
Yea I know what Flux, Redux are, and honestly I think they are completely not
needed if you understand and use React well, see comment below

------
amelius
I once wanted to use React as a virtual DOM library, nothing more. Turned out
that I had to create "components" for every div I wanted to draw. Of course,
this was a nuisance to the point that I had to let go of React.

~~~
mambodog
You seem to be mistaken. You don't need to create components if you just want
to render some divs. You can just do

    
    
        const {render} = require('react-dom');
        const {DOM} = require('react');
    
        render(
          DOM.div({className="something"},
            DOM.div({className="something-else"},
              'some text',
            ),
          ),
          document.getElementById('root'),
        );
    

Components become useful pretty quickly as your views grow in size, but even
then, function components require very little extra code to use.

~~~
amelius
Interesting, I didn't know, although I can recall searching through the
documentation for answers. Does calling the "render" function multiple times
perform the DOM-diffing and updating?

And can I be sure that React will not perform updates behind the scenes at
other moments than when calling "render"?

~~~
mambodog
In answer to your first question, yes. See the documentation for `render`:
[https://facebook.github.io/react/docs/react-
dom.html#render](https://facebook.github.io/react/docs/react-dom.html#render)

In answer to your second question, yes, React currently only does anything as
a consequence of calling `render`, or `.setState()`/`.forceUpdate()` in the
case of a component class (not relevant if you're not using component
classes).

In future, the (currently experimental) 'fiber' render will allow some
rendering to be deferred until after the current call stack has finished (to
avoid blocking the UI), but there should be away to tell React to do all
rendering synchronously if you desire (which is necessary for eg. rendering on
the server). There's no reason why the current behavior couldn't be supported
on top of the new experimental renderer though.

------
marclave
"JSX is also the reason when you have to keep splitting your 15-lines-of-html-
code component to 3 components, 5-lines-of-code-in-each." this stuck with me
the most

------
albertTJames
I have just learned React !!!

That's it, I am learning C++.

------
sebringj
My only issue with Vue is using programming flow within tags. This gives me
acid flashbacks of coldfusion spaghetti horror.

------
hoodoof
You don't need to use Redux, and I don't - it gives me nothing I need and adds
complexity.

------
cdevs
Can't comment on vue much other than I think it would be the one I would go
with if I had to pick one of these js frameworks due to some of the nice
projects I've seen in little code. But yii2 for admin panels seems like
another great selection for generating quick ugly forms only 5 people might
see a month.

------
andrew_wc_brown
MITHRIL JS

------
romanovcode
In short: FOTM

------
Steeeve
With all the evangelism I've seen on HN about React, I have yet to see a
cohesive post about the benefits that it provides that makes it worth the
investment in learning.

Nor have I seen a seen a good review of tooling that provides a good path for
someone who wants to try it out.

What I do see, are arguments that "it can do that too if you only knew how to
use it!" That and a lot of sample code that embeds html within the code, which
frankly looks like a delegation nightmare. (and scattered postings about
documentation not being up to date)

You could downvote me. Or... you could point me to a helpful and up to date
resource or recent posting that is actually helpful. Or better yet, write one.

~~~
matt4077
[https://github.com/facebookincubator/create-react-
app](https://github.com/facebookincubator/create-react-app)

------
sapeien
Clickbait title for the HN crowd, I sense that articles like these are
analogous to the old _which color to paint the bikeshed_ debate.

Front-end libraries and frameworks should be trivial because front-end web
development is largely trivial, it's the ecosystem around it that has bloated
in complexity, including Vue.js and React.

Take a standard API that is already simple enough to understand and use (DOM),
and re-package it for people who wish to call themselves "software engineers"
to justify the time they spend on making simple things work in a complicated
fashion. If you disagree that front-end complexity is getting way out of hand,
just read the source code of any modern single-page app including its
dependencies.

I think that code written by amateurs cobbling together vanilla JS is
generally faster in development and performance, more easily understood, and
easier to maintain than code written by a professional web developer using
whatever framework. The early web itself was largely cobbled together by
hobbyists, and so should it continue to be.

The industry disagrees with me, that's fine. I'm aware there are many reasons
why my views are the exception not the norm. I just hope that something far
better supercedes this era of web development, which would require social and
cultural shifts to occur.

------
jayajay
This is a great article, thanks for sharing.

"Not being able to put plain old IF condition to some block of HTML code
sucks"

In my usage of React, I found that this limitation forces me to use functions
to break down my code, a skill which is simply required when working on large
projects. Of course, that's what everyone else says, too.

"JSX is also the reason when you have to keep splitting your 15-lines-of-html-
code component to 3 components, 5-lines-of-code-in-each."

Truth to this -- React can make things slower when your project is inherently
monolithic, but you're tempted to abstract things into ugly Listwrappers,
ListViews, ListViewData, ListViewDataContainers, etc. It gets ugly if you
aren't good at abstracting things very well.

 _React should approached with caution._ I think this guy has the right idea,
don't put all your eggs into the React basket. Don't underestimate the cunning
of Mark Zuckerberg. If possible, don't rely on React, because if you create
something groundbreaking, you _will_ be in for a legal situation with
Facebook.

