Why I like Vue over React

Written by munawwar | Published 2017/01/16
Tech Story Tags: javascript | react | vuejs | front-end-development

TLDRvia the TL;DR App

As a person who have spent time writing his own JS framework, I am nitpicky, when it come to frameworks. When it comes to React, there are several things I don’t like, which Vue.js seems to have solved in nice ways (out of the box):

1. Templates vs JSX: My personal preference is templates over JSX. I find the lack of ‘if’ and ‘for’ control statements with JSX causing developers to define lot of temporary variables at the top of render functions, which in turn makes the code more difficult to follow. jsx-control-statements can mitigate that. However templates are certainly more readable.

[Besides, babel is a huge dependency that adds to the build system, which I try to avoid. Its 150MB when a full browser — Chrome debian extracted, is 178 MB. Ridiculous!]

2. Updating child components: With React, if one isn’t using Redux, there are two ways to trigger state change on a child component:

i. trigger state change through props + listen to componentWillReceiveProps(), which can then change the internal state of the child component

or

ii. keep a reference to child component(s) during the render() function and then call a method on the child component, which in turn changes the internal state of the child.

I personally find method (i) convoluted and rather prefer (ii). However React recommends (i). On the other hand, Vue.js gives an easy way to access child components using “ref” attribute on the component’s custom element. (Besides it looks more nicer/readable than keeping references to child components in JS with React). [1]

You might be thinking: “Why not just use Redux”? My question is why add the additional layer when the application/website is small?

3. Attaching events to component root element: When it comes to parent component listening to events on a child, I prefer to attach anonymous functions as event handlers to the root element of the child. This makes both the parent and the child easier to refactor if/when needed.

With React, one has to pass function(s) through props (which introduces a name) to attach an event handler to the root element of a component.

The name introduces an interface to be documented by the component maintainer, looked up the developer using the component and still limits the number of event types on which the parent can listen to. (Yes, when attaching events to non-root elements, the introduction of an interface may be unavoidable. However attaching event handlers to root element is very common, so..this should be easier right?)

Vue.js, gives ability to directly attach an event handler by defining a “v-on:eventname.native” attribute on the component’s custom element. It avoids any named property on the child and is much more declarative, nicer to read.

4. Abstract components: Let’s say I need to implement an abstract pop-up modal, that has two different body and footer shown at two different places in the website. The React way is to define props, and use them in the render function. But with Vue, one can define it with placeholders (Vue calls it “slots”)as:

<div class="popup-modal"><main><slot name="header"></slot></main>

<footer><slot name="footer"></slot></footer></div>

and declare a modal where ever needed:

<popup-modal><p slot="body"> Some message </p><div slot="footer"> <button>Ok</button> </div></popup-modal>

Vue.js gives a declarative way to define abstract components through slots, which I prefer over using props for this case.

5. setters vs setState(): Here is a small nitpick. Vue’s syntax for manipulating data/state is nicer than React’s setState() method. One can manipulate the data like usual and expect to see the view updated. Vue uses setters/getters to know when a property changes.

Side notes:

[1] — A gotcha here is that $refs isn’t available until the component renders. I solved this with the JS framework I wrote in the past, by rendering the component in-memory, on construction. This helps in resolving *most* of the references to child components, if not all. It also avoided a “not rendered” internal state, which avoided several checks in the library code, avoiding bugs, simplifying code for both the developer and the maintainer. <- Vue.js maintainers, if any of you reading this, take that as a potential idea/suggestion.

That’s all for now. I’ll add more here as I learn more about both frameworks. React and Vue devs: Please comment if I’ve got anything wrong or if I have missed some easier ways to manage code.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!


Published by HackerNoon on 2017/01/16