The Unbreakable Bond
Of all the articles I’ve read comparing and contrasting the differences between VueJS and React, there is one crucial flaw that I have not seen discussed at length. Bear with me as I tip-toe through the details.
If you are unfamiliar with the typical differences most often cited between Vue and React, they include things such as:
- rendering speed (advantage: Vue [until React Fiber])
- learning curve / ease of use (advantage: Vue)
- new app setup time (advantage: Vue)
- major feature set (equal [ReactNative? Weex.])
- custom directives (advantage: Vue)
- conditional elements/rendering (advantage: Vue)
- flexibility (advantage: Vue)
- strictly JavaScript (advantage: React)
(As you can plainly see, this author is heavily unbiased.)
The key differences not noted above deal with the manner in which you can or must implement your code and the context in which you are able to use each framework.
Legacy Systems
Imagine, for example, if you were faced with a large, clunky data-entry form with lots of fields and logic in a legacy system, and you were assigned the task of modernizing it with a fancy new front-end framework. That form might be structured along these lines:
If you were to approach this project with VueJS as your front-end framework of choice, you could complete the job with some tweaks to the markup and a new .js file. For example:
Keep in mind this is a basic, crude example for illustration purposes only. The salient point here, regardless of the Vue implementation details, is that the existing markup could be reused mostly as-is and in-place, with a bit of refactoring.
With React you would be unable to use any of the legacy implementation as-is and in-place. You would instead have to paste all the markup into new React components and refactor accordingly.
Furthermore, even if you did rewrite with all-new React components, you would not be able to just load your new code onto the page. Instead, you would have to augment your entire development process to include in your workflow the additional steps involved with babelifying/transpiling and deploying your new React code. This leads me to crux of this article, which is a related, but broader issue.
Tight Coupling
One difficulty that lives at the core of React that I have not mentioned by name until now is how its markup is written: JSX. One of the most well-known and significant differences between Vue and React is that everything in React is strictly JavaScript-based, however Vue is flexible enough for components to be based on real DOM elements, textual HTML markup, or even JSX (which I believe is supported to help entice timid React devs to switch over to the bright side).
There are well-seasoned veteran developers out there who favor React because they like that it is entirely JS-based. I have heard from such developers:
“It feels more natural to do everything in React because it’s completely JavaScript, but Vue uses HTML attributes to manipulate the DOM which is unnatural.”
Well, alright, to each his own… at least as far as opinion is concerned. But what that translates to in objective terms is that you must create all of your DOM markup using a custom grammar invented by Facebook (which, as an aside, happens to feel very _un_natural to this author). And because it is written in this non-standard, custom way, your React code cannot be directly executed on a page; it must first be translated into actual natural JavaScript.
To illustrate a bit further, consider the following markup:
<div id="some-block"><h1>arbitrary content</h1></div>
<script type="text/x-template" id="my-template"><p>Lorem ipsum dolor sit foobar</p></script>
You can instantiate Vue components by attaching to an actual element in the DOM:
new Vue({ el: '#some-block' })
Or by using a string of markup (whether in a <script> template on the page, a string in the JS, data fetched via Ajax, etc.):
Vue.component('my-component', { template: '#my-template' })
This is great if you are using Vue, though since you are neither able to write plain HTML in React nor hook a React component up to existing DOM elements, your hands are tied. By this I mean that you cannot in lieu of JSX point React at an existing ID in the DOM and have React implicitly parse that subtree as JSX.
To execute the equivalent in React, you could not just reference the existing DOM or external HTML. You would instead have to define new JSX inside your component. For example, (assuming we intend to build a stateful component):
class MyComponent extends Component {constructor(props) {super(props)
// ... set state ...
}
render() {// don't let its appearance fool you - this isn't HTMLreturn (<p>Lorem ipsum dolor sit foobar</p>)}}
// ...define props and their defaults...
Because React is so rigid and inflexible in that way, it means:
In React components, you can not modify your markup without a recompile.
For many teams or projects this may not be of significant concern, but it became an important matter at my day job recently when it was realized that Product Managers, Marketing, and any other non-technical stakeholders would never be able to make even simple static text markup tweaks as they had commonly done in the past.
Generally, it is an obvious best practice to separate controller logic from the presentation view. This is possible on a lower level, internally within React using the container/view (a.k.a. smart/dumb) component pattern, but on the common browser level, the logic and view are inextricably, tightly coupled in a block of cement behind bulletproof glass.
With simple view-layer markup entangled inside the low-level programming, what it means is that not only will moving from legacy code to React require a rewrite instead of a refactor, but moving in the future from React to another framework will likely require rewriting again from scratch instead of just refactoring. This is not necessarily a problem today, but at some point Future You & I will likely be faced with this conundrum with the emergence of next next-generation frameworks. I think a good principle is to prefer an implementation that is not only easy to implement initially, but that will also allow you to easily pivot away from it later.
Conclusion
The intent of this article is not to bash React in order to praise Vue, nor to dissuade everyone from using React in favor of Vue. As the mantra goes: you should always use the right tool for the job, whatever that tool is. I only hope to shed light on what I feel may be a potentially major consideration for a company or dev team when making a decision about which front-end framework they could be locked into for the foreseeable future. (Who knows? Maybe that’s part of the plan, for everyone to be forced to rely on React and, by proxy, Facebook. It worked for Microsoft.)
Meanwhile…
Vue is trending above React for the first time