
Why I left React for Vue - hogu
https://blog.sourcerer.io/why-you-should-leave-react-for-vue-and-never-use-it-again-5e274bef27c2
======
crubier
I disagree with everything in this article, except maybe about saving a few kb
in bundle size, and the better CSS experience.

Everything else is biased and mostly wrong. In terms of performance, recent
versions of react with Fiber can achieve figures vue can only dream of.

The conditional in react is just pure JS. He could have written an if
statement instead of the anti pattern use of && for a non Boolean expression.
And arguing that the v-if followed by code _in a string_ is simpler sounds
dishonest to me. Or we don’t have the same frame of reference.

The main problem to me is that the author compares his experience with react
in 2015 with his experience in Vue in 2018.

~~~
sergiotapia
>The conditional in react is just pure JS.

Who cares? You still write a JS conditional in the v-if string, right?

~~~
crubier
> Who cares?

Me. As a CTO I am not confortable having significant amounts of code embedded
in strings inside html attributes. Also we use Flow / Typescript.

React is typesafe and sound. No templates, no strings, just functions. This is
the basis of the pyramids of developer's needs.

~~~
sergiotapia
> This is the basis of the pyramids of developer's needs.

Apparently not though, thousands of people use Angular, even more people use
VueJS now.

~~~
crubier
> thousands of people

Animals*. Not people, FTFY.

Joke aside though, I think this is an artifact of old school web development,
which was a mess. People didn’t mind these kinds of hacks. But the number of
people willing to accept such incongruities is going to go down in the next
years as web development has now normalized into more sane practices that are
standard in the software development world.

------
ystrdytmrrw
I just can't get behind ` <div v-if="unreadMessages.length > 0">` after years
of React. At least with React it is pure JS/TS - No magic.

However I must admit, the css story within vue is more interesting than React
and its collection of CSS-IN-JS libraries.

~~~
mattigames
That's also how angular does it, i don't see anything magical to be honest,
just syntax sugar over

    
    
        if (unreadMessages.length > 0) {  addComponent(this) }

~~~
ng12
But it's a lot of syntactic sugar. There's a second, stringly-typed language
embedded in your HTML template.

~~~
mattigames
The only reason for it to be "stringly-typed" is that your IDE doesn't support
it.

~~~
nv-vn
At the end of the day, it's much more of a hack. The IDE having to guess at
what the string does is ridiculous to me, and it's just a ton of extra work
for the person who wrote the IDE for no real reason. And now if you want to
embed a string inside you need to switch quotes. Plus formatting gets super
weird if you have a multiline condition. It's also super confusing for new
users. There are so many issues I see with that design that I can't begin to
understand why someone would argue in favor of it.

~~~
mattigames
An IDE doesn't have to guess anything, if the string is preceded by v-if then
is code, that's it. Pretty much how a string literal inside eval() could be
parsed as code.

~~~
nv-vn
What if another library uses v-if? Or there's no library loaded at all? What
if I just wrote a new library that uses c-if? I imagine most IDEs approach
this by looking at the string and trying to guess whether it's HTML code or
not.

------
_hardwaregeek
Ah yes, the classic "I spent a couple weeks learning technology X, got
confused and gave up, so therefore it's bad". What a lot of these articles
miss is a good analysis of _why_. Generally if something is confusing, weird,
or wrong, it's for a particular reason. Even if the reason is poor, it's
important to know it before you bash. So here's some of the reasons:

The whole v-if statement versus JSX is rather superficial imo. Personally I
don't like awkward DSLs that depend on code inside a string, but that aside,
did the author ever wonder why JSX uses &&? JSX is fundamentally a fancy
syntax over function composition. What's nice about this is that it's a more
general abstraction than what Vue offers. Vue has to give the user all these
v-if, v-for, v-whatever directives, while React just gives two tools: function
composition and brackets to return an expression. You could argue that this is
more tedious, more code to write, whatever, but it also means that you don't
have to depend on your library writers to add more directives. That being
said, I understand the joys of syntactic sugar and I guess v-if is kind of
nice.

Binding is a JS problem not a React problem. The fact that these are confused
leaves me even less credence in the author. If the author learned about the
mess that is JS scoping, they'd understand why binding is necessary.

setState exists for a reason as well: state updates in React should be
controlled and minimized when possible. I don't want my state in React to
update like a normal JS object. In fact, I'd prefer if React moved to a
ReasonReact style reducer format just to emphasize that state should be
treated immutably.

All the "code is smaller in Vue" is extremely subjective. I'd need better
examples than v-if to judge that. Plus, terseness comes at a cost. I can write
extremely terse, metaprogrammed Ruby or even worse, Perl. Chances are I won't
understand it within a month.

Finally, I see the author using the word "template" repeatedly. React is NOT
templating. This is a very important point. Components are a far far more
important abstraction than templating. Components can be wrappers that provide
state, or a way of abstracting API calls, or a way to control routing. In the
end, they're functions (or rather closures) that call other functions. Calling
components "templates" betrays a fundamental misunderstanding of React's core
principles.

~~~
BigJono
> Binding is a JS problem not a React problem. The fact that these are
> confused leaves me even less credence in the author. If the author learned
> about the mess that is JS scoping, they'd understand why binding is
> necessary.

This is going to be a huge problem going forward since the React documentation
team seems to have made it their mission to try and obfuscate the details of
JS away from their readers rather than educate them. Which is a terrible
decision.

~~~
_hardwaregeek
Yeah this is a common problem when your library/framework/tool becomes too
popular. Your users focus too much on learning the shiny tech and not the
foundation. Rails faced a similar issue where people would come in without
understanding Ruby and struggle with even the most simple tasks. Of course it
didn't help that Rails also tried to hide many of the details of Ruby.

------
androidgirl
I don't buy into Vue being easier to learn than React.

This year I picked up and started learning React after some experience with
vanilla JS and jquery. I first tried Vue and for whatever reason, non-trivial
examples were so hard to wrap my head around.

The documentation was hard to follow sometimes, and I had some issues with
documentation on other projects like Nuxt.js, whereas the Create React App and
Gatsby docs are so good.

I tried React just when I was about to swear off front end web development,
and everything clicked. I've never felt like I had superpowers until I started
using React to replace jquery soup.

Nowadays, I use vue occasionally if a project is using it, and it's easier to
understand for me now. I still greatly prefer React, though, and JSX is a joy
to use.

~~~
BigJono
Vue might be easier to "learn" under some metrics, but there's no way it's
easier to actually understand. Look at the amount of hidden build-time logic
in each system. Vue has it's own entire stringly typed DSL, React has _one_
fairly trivial transform that's easily doable in your head, and is totally
optional _.

_ which still matters, even though nobody chooses to go that route, because in
theory it allows beginners to learn the JSX abstraction seperately, and helps
smooth out the learning curve. Unfortunately nobody actually seems to learn
this way because there's so much emphasis on getting devs up to speed and
working on production systems as quick as possible, at the expense of actually
imparting them with any wisdom or knowledge. The React team are the worst at
this (although Vue is a very close second), there's no good reason that I need
to go to Dan Abramov's twitter and blog to find out how the library I'm using
works. It should be in the official docs. Otherwise you're just training devs
to code through rote memorisation of patterns instead of any actual knowledge
or understanding.

------
thangngoc89
The reason I choose JSX over Vue weird template system is because it's
Javascript after all. I don't have to relearn how to do if-else, for loops
statement for every template language. But the css story of Vue is definitely
better than React.

~~~
wjossey
By the same logic, couldn't you argue that you should be programmatically
writing all of your HTML, because then it would "just be Javascript after
all"?

I'm sympathetic to not reinventing the wheel when unnecessary, but on the flip
side, I haven't found the vue templating syntax to be anything but intuitive
and cognitively easy to predict. It's not like you're prolog all of a sudden.

~~~
BigJono
No, because HTML is built into the platform and is a necessity for every web
app. Vue is used in like 10% of them, and everything Vue-specific you learn
will be useless for 90% of use cases.

------
yunyu
The author's gripe with having to manually bind methods is solved by property
initializers, which have been around for a while now.

~~~
roddds
Or using arrow functions.

------
dfee
I went the other way. I enjoyed using VueJS. But the quality of the library
and community on React seems a bit better.

It probably helps that I’ve really been learning JS with TS after a decade of
Python, and the TS community is pretty good in Reactiflux.

a couple other thoughts:

\- the single file concept with Vue is awesome. But I find it irrelevant with
JSX - and I never could get it fully working in my IDE (VSCode or VIM)

\- the patterns seem to be more established in React (which is helpful to
someone who’s learning and developing).

\- the VueJS libraries that I used were often a reaction to a React library
and seemed to be an afterthought, unfortunately.

All in all, I like having experience in both, but I don’t see a reason to go
back to VueJS in the near future.

------
makeupsomething
I have gone the other way, after using Vue at work for the last year it feels
like such a relief when I get to go back to React and just write plain
Javascript.

------
ezxs
I have done a medium size project in React and didn't have a lot of fun
working with it. Since then I tried VueJS and found it a lot more readable.
Maybe the applications I wrote didn't have absolutely everything dynamically
generated, but it seems like big chunks of pages were not actually that
dynamic and it was nice to just see it in a form that was close to what it was
supposed to render to.

------
kevinsimper
The stats at the start of the article is with multiple years old versions of
angular and React, doesn’t make much sense for an argument?

------
pkulak
JS in an XML property string is just never going to work for me, sorry.

------
dschu
1\. JSX puts HTML into JS, which gives you compile errors. While Vue puts JS
into HTML again.. 2\. Never use bind inside render functions.

------
gtoprak
Unfortunately, the author doesn’t seem to understand what React is about and
what problems it’s trying to solve as a framework.

------
revskill
React-Router or anything using centralized router in React Component is bad
pattern for scalability. In this case, you, library authors, could learn from
Next.JS. The fact is that, by splitting your route into something like
`pages`, you can do code splitting for your application as well.

------
_nalply
When I started Vue I was somewhat disappointed that Vue components aren't
first-class HTML.

I looked at W3C web components instead and I liked the concept better. For
example why not define control flow elements like, for example <c-if> or
<c-loop>? However I didn't gain enough practical experience to be able to
recommend them. Perhaps there are problems lurking behind them.

So this left me wondering why web components aren't as popular, even including
accompanying frameworks like Polymer. I suspect that in a few years Vue will
maybe again being overtaken by another framework basing on W3C web components,
just because web components feel more natural than Vue components.

------
sergiotapia
I've been writing React code for years now, and recently have a gig where we
use VueJS exclusively for the frontend. First time using VueJS and I completed
a few tickets on my first two days. I couldn't imagine doing the same with
React.

I'm now 100% on team VueJS.

You get stuff done quicker, the files contain templates and logic separately,
and it makes me happier to work with VueJS. For those people preferring React
over "muh its just js", please - it's just code, to get the job done. Use
whatever gets the job done and makes you happy. After a few days of VueJS
you'll find it incredibly nice to use.

~~~
molszanski
It sounds that you feel more productive in Vue. Why? What was holding you back
in React? After all, those are component based JS frameworks, with comparable
data layer patterns and user facing architecture. So what was so different for
you? Having everything in one file? Not having to deal with classes?

------
stevev
To each his own. React makes sense for some developers. They love the
verbosity and powerful libraries. However I prefer Vue.js on many levels. The
creator initially worked as a designer; therefore a lot of the vision for the
tool adheres to a strict usability and designing standards for the user or
developer. I feel react was rushed giving priority to features over usability,
adoption and clean apis.

------
Tade0
No mention of Vuex? This, to me, is Vue's major selling point - Redux in
comparison looks as if someone tried to shoehorn a few things for the sake of
"abstraction".

Also I don't know anything about React's material design component set, but I
know Vue's Vuetify is really well made, especially comparing to the equivalent
in Angular.

------
candillon
Type safety is also one of the reasons why I prefer React over other
frameworks such as Angular or Vue. With JSX, we have a unified type system
across the logic of the application, its styling, and its presentation. The
same level of type safety doesn’t seem to be available with other libraries.

------
kangoo1707
Where Vue is better:

1\. Template syntax. While this is just my own preference, my Vue template is
20% shorter than JSX equivalent, mostly due to fewer brackets and better
HTML's class support.

2\. Computed property: this is so cool and efficient because computed
properties are cached (equivalent to Mobx). We also have computed setter as
well.

3\. Built-in 2-way binding for inputs. Yes I know React people will condemn me
to hell for this, but this has been a heaven for form-heavy application. This
also makes the HTML you write much much shorter.

4\. Prop mutation: this one is extremely controversial. Imagine this.props.foo
= newFoo" in React (in Vue land it's "this.$emit('update:foo', newFoo)"). This
is useful in situation where you want to mutate a parent's state without going
to all the boilerplate of writing store/actions/dispatch. For example

    
    
      <div>
        {{ user.firstName + ' ' + user.lastName }}
        <popup-update-user user.sync="user>
        </popup-update-user>
      </div>
    

By looking at the above code, I can tell that <popup-update-user> will take an
object called "user" in, modify it (and probably calls an API), then update
the user object back to me. Of course I can do all that in the Vuex store (or
in your favourite Redux flavor, but imagine all the code that has to be
written)

5\. Watch expression: it's beneficial and concise if you know what you're
doing and not abusing it. This doesn't even exist in React. (edited: plain
React doesn't have this, Mobx does)

6\. Built-in Vuex support out of the box. Enough said.

7\. Nuxt's offerings are superior to what Next can offer. Nuxt allows layout,
param validation, node server middlewares, sass and Vuex integration, sensible
configuration, and a system of plugins.

8\. Filters: coming from functional languages that support pipeline operator,
this has been dope to my eyes. Instead of writing:

    
    
      { formatDateTime(toDate(myDate), "DD-MM-YYYY") }
    

you can write it in a better way:

    
    
      {{ myDate | toDate | formatDateTime("DD-MM-YYYY") }}
    

Of course, the difference is just syntactic. But I hope in the future, Vue's
filter can be cached just like computed properties.

9\. It doesn't need Babel. I dropped Vue into a legacy PHP Symphony project,
wrote the Vue's template in a <script type="x/template"> and wrote the
components in plain ES5 object, and it just works !!!

10\. The event emitter is a better pattern than calling prop as a function.

    
    
      <MyImageGallery onImageSelected={doStuff} />
    

vs

    
    
      <my-image-gallery @imageSelected="doStuff" />
    

Again, you may argue that this is syntactic sugar, but for me it's clear just
at a glance which props are "in-ward", and which props are "out-ward"

11\. Vue doesn't intefere with SVG attributes. in React, I have to convert
"xlink:href" to "xLinkHref", which is annoying

~~~
crubier
Many of those are shortcuts that look appealing on a simple project in the
beginning, but have the potential to massively backfire later on when your
project grows.

It is like shooting your future self in the foot.

On the other hand react make some things difficult because they are
antipatterns, independently of react itself. (I'm looking at you number 4:
Prop mutation...)

------
wraithdroplets
I realize front end frameworks can be in the language of the trophy awards for
solving a real consumer's "temporary endeavor undertaken to produce a unique
product, service or result: actually a helplessly complicated system of
activating the end result, which also from Fundamental of Project Management
book, is "a headless chicken project" before the developers take enough
"aftercare" to realize all has been ended and the honey room is next (human
resources).

This is of course for CM0 type of whatever development though that may be in
carriage of more advanced software life cycle systems. I tried some Vue dot
js, I got some Angular dot js, I saw Angular dot whatever is difference
positive. I read JS survey reports and of course always am super diligent
about understanding Stack Overflow surveys of developers.

I think any particular perspective on the end results tends to be from the
myopia of the skillist's perspective (to use confederal type of language
instead of under-squiggley-tells-me federal non-adverbial BE that IBE can
understand, without massive disassembly efforts on the part of the
communication triangle (most direct, least direct, something else).

This is sort of like unpunctuated scriptures being upgrade to punctuated
before being universalized after failed attempts to understand the Hegelian
master/slave "golden" pretend morality (not to be hypercritical about "geeks"
jargon file meaning as someone who knows chickens can be engineering to be
pretty amazing and basically do a 50 yard dash in amazing pirouettes like
dolphins released from old Navy, Pavlov sacristen-blasphemer, padawan of
Orloff, yards that aren't still supposed to be around).

I mean it is Bacchanalia day and all, so Festivus!

React is great, Vue is great, conditional reflexology is trump over
nonreflexive thinking attempts, it is all good to Pathology Excellent Rubbish
Lister (PERL, red squiggle word kill count = 0). Ok front door 89 hz beep went
off. I'm over my trolling limit. Be well, program in popular script-y.

~~~
code_duck
I mean, I kind of miss TempleOS... if you could step it up a notch

------
aviv
I see no compelling reason to move from AngularJS 1.x for both new and
existing projects to either React, Vue, or whatever else is hot in certain
circles. We generate many millions in business, and I can tell with certainty
that the framework has nothing to do with how well we perform. If anything,
staff's confidence that our stack is extremely stable and not prone to team
leaders deciding to jump into a new framework only contributes positively to
their productivity.

