The Unbreakable Bond Of all the articles I’ve read comparing and contrasting the differences between and , there is one crucial flaw that I have not seen discussed at length. Bear with me as I tip-toe through the details. VueJS React 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 or implement your code and the context in which you are to use each framework. can must able 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 file. For example: .js 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 be reused mostly as-is and in-place, with a bit of refactoring. could With React you would be unable to use 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. any 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: . One of the most well-known and significant differences between Vue and React is that in React is strictly JavaScript-based, however Vue is flexible enough for components to be based on real DOM elements, textual HTML markup, or (which I believe is supported to help entice timid React devs to switch over to the side). JSX everything even JSX bright 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 is concerned. But what that translates to in objective terms is that you 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 natural JavaScript. opinion must actual 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 template on the page, a string in the JS, data fetched via Ajax, etc.): <script> 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 be able to make even simple static text markup tweaks as they had commonly done in the past. never Generally, it is an obvious best practice to separate controller logic from the presentation view. This is possible on a lower level, internally 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. within 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 React to 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-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 from it later. from another next away 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… for the first time Vue is trending above React

Apache

Facebook

Google

Microsoft

Super

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

One Major Way VueJS > React

Too Long; Didn't Read

Companies Mentioned

Rommel Santor

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

One Major Way VueJS > React

Too Long; Didn't Read

Companies Mentioned

Rommel Santor

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES