DEV Community

Why I Converted from Vue to React

Brett Fisher on July 17, 2020

EDIT: After receiving a lot of comments on this post, I realized that not all of the information I presented is accurate. I just released an update...

Read full post

neoan • Jul 18 '20 • Edited

Uff, a nice write-up, but I so disagree. Professionally I have to work with React way more frequently than Vue, but I highly prefer the latter.

While ultimately it's a question of taste in most scenarios, here are a few rebuttals:

There is no magic in React, you simply return JSX?

Ignoring the fact that JSX itself is "magic", the fact that React's function to pass JSX on is called return doesn't mean it is return. You pass JSX into a function which I believe I don't have to argue is confusing as you seem to have confused it.

Edit: as one if the commentators (Birtles) has made me aware of that paragraph being misleading, let's clarify that you DO use a simple return. The point should have been to point out where you return to.

The same is true for your hooks explanation: saying that you declare callback functions is the same as hooks only being functions is like saying a vue-component is only an object: it's not wrong from a declarative standpoint but of course there is so much more to it.

The complete section about your IDE not being able to be smart enough is not really an argument for the framework itself. I use jetbrain's PHPStorm and it's so helpful that the usefulness of typescript in general is limited to preventing other developers to break code. However, you explain it with a huge community for React which is a solid argument for choosing technologies.

About vuetify

It's indeed a bit tricky to test. What bothers me about this comparison is that you compare it directly with React. If you wanted to compare on that level, you might want to explore something like next.js so can compare apples with apples (or at least fruit to fruit)

Brett Fisher • Jul 18 '20

Hey neoan, I appreciate the feedback! I probably ought to be clearer about what I mean by "magic". I could see why someone may think of JSX as magic - what's all this HTML doing in my JS code? One of the most "magical" things I found about Vue but didn't touch on in this article was the properties that plugins attach to this. For example, Vuetify creates the $vuetify property. There have been multiple times when I've been looking at my company's code and had to do a double take when I see global properties like that, unsure if it was native to Vue or coming from some third party or in-house plugin.

I actually am a big fan of Vuetify and think it's a lot more intuitive to get started with than Material UI. But for React in general, I like its lack of "magic" variables. Everything used in a React file is imported. Going back to Vuetify, the $vuetify object has some pretty great methods on it, especially for breakpoints, but I will have to say I prefer Material UI's method of handling breakpoints. It just feels more declarative. That's only one example, of course, but overall I like how I almost never have to guess where any piece of code is coming from in React. This has been a huge plus for me when working with large code bases at the companies I've worked for.

neoan • Jul 19 '20

To be clear, I am not making the argument that there isn't a lot of magic in Vue. However, at the end of the day a vue-component is valid markup and JSX simply isn't. That is why you will never be able to run a React component using JSX without compiling. It's the opposite of pure JavaScript.

As for vuetify:
Again, I think you shouldn't compare a wrapper like that (shall we call it a framework-framework?) with pure React. React has similar wrappers to simplify (and therefore magicify) loading.

And again, I am not claiming that Vue doesn't dip into the magic cookbook a lot. It is not intuitive to assume that something you declare in data() to be magically available directly in "this". It's something you need to learn/read.

Anurag Hazra • Jul 20 '20

Hi Neoan, can you please explain why do you think JSX is magic? (comparing to Vue's magic, i think vue is more magical than jsx) I'm actually planning to write an article about JSX so i wanted to know your thoughts :D

neoan • Jul 20 '20

I will try:
Vue's markup is valid HTML. In the most primitive form, what Vue does is to create observers for props and data and bind it to HTML. The result is relatively straight forward:

<element :my-prop="bound-value" another-prop="hard-coded-value"> ...

This setup makes the use of .vue-files optional and doesn't even require a development server. One could import Vue via CDN and write components directly in "hard" declaration:

const template = `<h1>{{headline}}</h1>`;
Vue.component('my-element',{
   data: function (){
      return {headline:"test"}
   },
   template
});

So while there is a lot of magic in Vue, the markup and bindings are pretty straight forward.

React uses JSX (you don't have to use it, BTW, but then React makes little sense). JSX is NOT valid HTML. It cannot render without being compiled. It isn't JavaScript either. The following code snippet is therefore neither valid JS nor HTML markup:

...
return <h1>{headline}</h1>
...

Is that bad? No, but it's pure magic, of course. I mean, it has it's own name (JSX) because of that (otherwise it would just be a template)!?

Now, as every React-dev knows, this means that some interpretational oddities arise. For example, we have to use "className" instead of "class" and "onClick" isn't "onclick". But all of that is relatively easy to get used to and not an issue compared to what is offered. What bothered me about React was how state was handled and bound (this got sooo much better with hooks) and that JSX has a very ugly solution to the two most common things in a dynamic template: conditionals and iteration.

Given the following data:

items = [{item: "one"}, {item: "two"}]

Let's look at Vue:

...
<li v-for="item in item" v-if="item.item != 'one'">{{item.item}}</li>

And JSX:

...
{items.map(item => 
   if(item.item != 'one'){
      return (
         <li>{item.item}</li>
      )
   }
)}

Looking at the above example: it there more magic in Vue? Yes. But you tell me which is more straight forward and approachable.

Anurag Hazra • Jul 20 '20

Hmm i see, good points, thanks!

one thing, why react makes lesser sense when not using JSX? It's just pretty straightforward createElement calls.

"you don't have to use it, BTW, but then React makes little sense"

neoan • Jul 20 '20 • Edited

Really? Please try writing the following JSX with createElement-calls and surprise me:

<form onSubmit={parentCallBack}>
   <input value={someUsestateValue} onChange={ev => setSomeUsestateValue(ev.target.value)} />
   <button type="submit">send</button>
</form>

And BTW, since we have a template here. Compare the following valid markups:

VueJS

<form @submit.prevent="parentCallback">
   <input v-model="someDataValue" />
   <button type="submit">send</button>
</form>

Or even more native and including the complete logic in declarative form:
AlpineJS

<form x-data="{data:{inputValue:''}}" onsubmit="parentCallback(data)">
   <input x-model="data.inputValue" />
   <button type="submit">send</button>
</form>

Anurag Hazra • Jul 20 '20 • Edited

here: (you said "React makes little sense", that's what i'm referring to, JSX is not binded to React elements you can build up any Tree like structures)

React.createElement(
    'form', 
    { onSubmit: parentCallback }, 
    React.createElement('input', { 
       value: someUsestateValue, onChange: ev => setSomeUsestateValue(ev.target.value)
    }),
    React.createElement('button', { type: 'submit' })
)

neoan • Jul 20 '20

So, how does it feel? Does it still make sense to use React? Do you think you could actually efficiently read a React app when built like that? What is the remaining advantage over vanilla JS?

const domEl = document.createElement;
const form = domEl('form');
form.innerHTML = `
<input name="some-name">
<button type="submit">send</button>
`;
form.addEventListener('submit', parentCallback)

My point is: JavaScript is moving to a declarative style. We want a clear separation of view/template and controller/component-logic, even if there is a move towards having these concepts in one file (component based architecture).

So my question was not if it is possible, but if it makes sense. You would certainly use a different solution than React if you couldn't use JSX.

James Birtles • Jul 18 '20

You seem to think that you are calling some magical return function. You're not. You are simply returning the JSX, the brackets there are not a function call, they're there for formatting the JSX over multiple lines as a return can't have a newline after it.

neoan • Jul 19 '20 • Edited

Yes, good point. At first I didn't know what you meant, but reading my comment again, I see what you mean. I make it sound like there is a function named "return". While there is no function "return" in the React framework, you are effectively passing it on to the render function. I should have been more specific/less ambiguous. My point was that declaration shouldn't be confused with how things work. I felt like many of the arguments were comparable with saying "webpack is just a json".

Edit: and reading my comment once more, you actually can't read it any other way than you have. I will have to change that.

Michael Z • Jul 18 '20 • Edited

Having used both extensively as well, here are my thoughts:

Vue requires a little bit of upfront learning (though most things like $emit can be learned progressively very easily). But the more you learn inside the framework, the less you have to learn outside of it.

React is a lot more low level in that regard. You even need to decide between several CSS solutions, forcing you to make impactful long-lasting decisions early on.

From the rails doctrine (rubyonrails.org/doctrine/):

How do you know what to order in a restaurant when you don’t know what’s good? Well, if you let the chef choose, you can probably assume a good meal, even before you know what “good” is. That is omakase. A way to eat well that requires you neither be an expert in the cuisine nor blessed with blind luck at picking in the dark.
...
You’ve surely heard, and probably nodded to, “use the best tool for the job”. It sounds so elementary as to be beyond debate, but being able to pick the “best tool” depends on a foundation that allows “best” to be determined with confidence. This is much harder than it seems.

This of course becomes less of a problem after a while...

Another example:

Sure, you can just pass in a callback for onFollowUser and don't get me wrong, I love the simplicity of this. But unless you wrap that callback in a useCallback, its child components will rerender unnecessarily leading to noticeably slow performance and lag in a fairly complex UI. Until you understand how React Hooks actually works, these are very surprising side effects, i.e. not "the pit of success". There are also a few quirks with useEffect:

Reference: blog.logrocket.com/frustrations-wi...

I seem to have spent an excessive amount of time twiddling various dependency arrays and wrapping functions in useCallback to avoid the stale state or infinite re-rendering. I understand why it is necessary, but it feels annoying, and there is no substitute for just going through a real-world problem to earn your stripes.

Vue takes care of these things for you. Not even once had I have to deal with rerendering/performance issues in Vue. The reactivity system just works and lets me focus on building the product. For me, it's okay to give up "JavaScript purity" for those reasons.

I do enjoy the simplicity of writing React components nowadays. But I don't think the Hooks paradigm is "just JavaScript" that everyone just grasps immediately, it requires a lot of exposure to get to know its various edge cases. I completely understand why React renders the way it renders. But I hope they find some solution making the process more obvious. Some of it is already solved by linters, but definitely not everything gets caught and some things likely won't be possible to get caught.

Like React Hooks simplified react components, Vue 3's <script setup> (github.com/vuejs/rfcs/blob/sfc-imp...) will also reduce the boilerplate to write components. Looking forward to that.

Brett Fisher • Jul 18 '20 • Edited

These are all great points. I agree wholeheartedly that Vue is very easy to learn. It was the first FE framework I learned, and as I mentioned, it took me a while to finally decide to move to React because I do appreciate its simplicity.

To someone just starting out with JS/web dev, I'd most likely recommend Vue because it fairly easy to learn. I probably ought to make it clearer in this post that I chose React not for ease of learning the framework. Rather, as I've come to understand JavaScript better over the years, I've actually come to really appreciate and even rely on the "lower level" features of React to write the kind of software I want. Plus, at this point I just feel like I can't live without TypeScript, and overall I've found it a lot easier to setup with React.

Yes, hooks definitely take some getting used to! When I first learned about useEffect, I remember thinking "seriously, I have to declare its dependencies? Vue's computed and watch do that for me!". However, I came to appreciate the simplicity that useEffect offered - I didn't have to worry about the difference between things like mounted, created, beforeCreate, etc. Granted, Vue 3's composition API will remove a lot of these nuances.

There's no perfect framework, and I'm not here to say that one is right and another is wrong. At the end of the day, I personally feel a lot safer making bigger applications with React.

Brett Fisher • Jul 20 '20 • Edited

Hey guys, this post got a lot more attention than I was expecting and I've received a lot of great feedback and comments. I've read all the comments and am currently working on rewriting this article to clarify the points I made and removing parts that I now know to be false information. I'm pretty new to blogging / writing about techy things so I appreciate the patience!

Anurag Hazra • Jul 19 '20

Surprisingly enough few weeks ago I wrote a similar post, which I think can explain the word "magic" more clearly.

Using a tool vs. knowing how a tool works internally.

Anurag Hazra ・ May 26 '20

#react #vue #tools

Brett Fisher • Jul 20 '20 • Edited

Your article is golden. I'm working on rewriting this article right now and found your points to be very helpful. Thank you.

Paulo Souza • Jul 19 '20 • Edited

Your struggles with Typescript in Vue really surprise me. I have been using Vue with the class API and Typescript for over a year and I personally find them a joy to work with. I use Vuetify too.

I also cannot complain about the lack of type check in the templates since Jetbrains IDEs offer the same intelisense in template as it does in script (the typo example you demonstrated would appear as an error in my IDE). Not only that, I get the full power of refactoring offered by Typescript - renaming, extracting, referencing, etc - and that includes Javascript code in template as well.

Obviously, your experience is likely to be different if you use VS Code with Vetur which I personally believe to be a poor plugin (with all respect to the Vetur developers).

I also dont see any black "magic" with the way Vue handles things. Using the class API, the 'this' basically gives you access to functions defined in the base class, which is a very common approach in OOP in general. Also, $emit() is just a function that happens to be prefixed with the $ symbol for identification purposes. The $ symbol itself doesnt do anything special.

I also worked with the Vue Composition API plugin for Vue 2 and I had exactly the same pleasant experience using Jetbrains IDEs.

I personally find JSX the only real black magic in the entire javascript ecosystem. I have come to believe that JSX is the best thing to use if you intend to scare away new developers.

Anurag Hazra • Jul 20 '20

Hi Paulo, can you clarify why do you think JSX is the only read black magic in the entire js ecosystem? i'm planning to write a article about JSX so i wanted to know your opinions. why JSX is black magic to you?

Paulo Souza • Jul 20 '20

Black magic is not the right wording. What I mean is that JSX is not standard. If you look at Vue, it is essentially standard Javascript and HTML (with custom attributes) that can be understood by any web developer. JSX on the other hand is this weird and unfriendly mix of HTML and Javascript in the same code block.

There is nothing wrong with having custom syntax that requires a compilation step. Typescript falls into the same category, and I love it. I just don't like JSX cause it looks terribly ugly.

Anurag Hazra • Jul 20 '20 • Edited

Okay let me go line by line and give my opinions :)

"What I mean is that JSX is not standard" ?? facebook.github.io/jsx/

"If you look at Vue, it is essentially standard Javascript and HTML (with custom attributes)" - i don't think vue, sevlte, or angular's templates are in any ways valid html markup

"that can be understood by any web developer" - JSX is way simpler to understand than vue's template, if i ask you "how does Vue's v-for directive work" can you answer it in simple words? but if i ask you "How does jsx loops works" i can tell you the answer "JSX is javascript so we can just use Array.map to map out the childrens directly in the template"

"JSX on the other hand is this weird and unfriendly mix of HTML and Javascript in the same code block." - JSX isn't a mix of HTML or js its Just javascript. it represents Tree like structures and we use it to build up the virtual dom.

"I just don't like JSX cause it looks terribly ugly." - well, personal preference :D

That's all. :)

Paulo Souza • Jul 20 '20 • Edited

Needless to say it all comes down to preference since you could use any of these frameworks to build most web apps.

JSX is not just Javascript since it has markup in it and there is special syntax to separate markup from the actual js code. If it were just Javascript, it wouldn't need a special compiler in the first place. This is more than obvious.

Anyway, tools are just tools. Languages are just languages. Pick whatever gets the job done.

Javascript will die some die, just like Vue and React will die too, just like the almighty Jquery is dying just now.

As a developer, what matters to me is to spend my time getting the job done rather than advocating in favor of a particular framework.

Btw, I develop frontends using Angular, React, Vue, XAML, Blazor and vanilla javascript/html. As I said, they are nothing more than tools.

Chad Smith • Jul 18 '20

First off, I believe anyone should be able to use any JS framework they want. You can get the job done with just about any of them, and their are successful big applications written in all of them.

Though I will say I disagree with the point that Vue is doing magic, but React is just JavaScript. If we wanted to do that I'd say that Vue is just an object. I disagree because React isn't just JavaScript. It returns JSX. That is not valid JavaScript. It's an extension of it, but it has to be compiled to regular JavaScript still. There is still a lot of magic happening for your "regular JavaScript function" to actually be able to be ran in a browser.

Again, you can definitely use which ever framework you prefer and don't even need to apologise for moving away from one framework. Just thought that with that point you ignored the "magic" that React is also doing.

Jesse Phillips • Jul 18 '20

Thank you for this writeup. I definitely understand the drive for a DSL to provide defined structures, which driving with free structure of the underlying language may not provide enough guidance to doing it right.

As you mentioned in both cases you have to learn how things fit together. With a lot of "magic" going under the hood is harder and usually necessary at some point. So personally I'd have the same leaning you do.

Jesse Phillips • Jul 18 '20

Thinking about this more, I think that you need to learn from the Java developers and add a layer of abstraction. This way you can switch out the framework without changing your code. All would need to do was implement a new backend to hook up vue or react. This would mean you would be ready for the next new framework as well.

Actually create your own language and compile it to JS so that when JS is replaced in browsers you don't need a complete rewrite of the code.

Rosdi Kasim • Jul 20 '20

I dabbled with React for 1-2 months, then gave up due to complexities involving webpack and redux.

Then I found VueJS, got hooked on it and never looked back.

Fast forward 2 years, your post got me intrigued with React again. Your point about TypeScript and Vue is spot on... I think I might revisit React and see how it goes.

Jesse Phillips • Jul 18 '20

Well I didn't say you wouldn't be tied down to a framework, it would just be a framework a level above the other frameworks. And we could create competing frameworks at this level so programmers can choose the best one for their needs.

Brett Fisher • Jul 18 '20

Good catch, thanks for pointing those out! I'll be sure to update those.

Alin Climente • Jul 18 '20

Imo Mithirl.js it's closer native js than React.