Why we chose Vue.js over React

Qwintry team recently started active migration to Vue.js as a frontend framework in all our legacy and new projects:

  • in legacy Drupal system (qwintry.com)
  • in our new, completely rewritten qwintry.com branch
  • in Yii2-powered b2b system (logistics.qwintry.com)
  • in all our smaller internal and external projects (mostly with PHP and Node.js backends)

In terms of project size Qwintry is used by around half a million of customers around the world, we run two warehouses (in US and in Germany) on our own software, and we are one of the biggest mailforwarders in United States in terms of visitor and shipment traffic, focusing on Eastern Europe, and Middle East. Basically, we help people to purchase goods in US online stores and manage packages via our control panel when they were received by our warehouse (consolidate/measure/take pictures) and then ship them internationally while saving significantly on shipping costs. We leverage our own IT systems and logistics chains to get the best quality of delivery services for the best price.
Qwintry box
Our package at customer door - from our happy customer reviews

We have pretty big codebase, mostly PHP&JS.

We decided to use Vue.js after we’ve completed evaluation of modern frameworks: we’ve built our customer calculator on React, Vue.js and Angular2.

My thoughts on React.js

React skyrocketed the JS world and it is now probably the default choice for JS devs, when we talk about choosing frontend view framework.
I’ve built some SPAs and dynamic widgets on React, I’ve played around React Native (under iOS) and Redux as well. I think that React was a great step forward for JS world in terms of state-awareness, and it showed lots of people the real functional programming in a good, practical way. I think React Native is huge - it just changes the landscape of native development.

Cons of React for me are:

Purity, immutability and ideology over getting things done

Don’t get me wrong. I appreciate pure functions and simplistic render() approach - no doubt, that’s a great idea which is working great in real life. I am talking about other things.
I guess this level of strictness and purity is something that may be useful when you have 1000 devs in your company - just about the time when you decide to develop your own syntax to go for static types in all the PHP code you write. Or when you are a Haskell developer coming to JS world. But most of companies have far smaller dev teams and other goals than Facebook. I will elaborate more on this below.

JSX sucks

I know, I know! It is “just a plain javascript with special syntax”. Our design&html guys who need to focus on making this specific form beautiful by wrapping its elements in various quantities of divs - right now - they don’t give a sh*t about purity and plain ES6. Applying designs to React components still sucks big time because JSX lacks readability. Not being able to put plain old IF condition to some block of HTML code sucks, please don’t believe React fans that keep telling you that you don’t need it when you have ternary operators. Let me assure you - this is still a mess of HTML and JS when you edit it and read it, even though it gets compiled to pure JS.

       {items.map(item =>
         <li key={item.id}>{item.name}</li>

Lots of developers (including me - but I am not there anymore) are thinking that this specific restriction on syntax will make you stronger will help you write more modular code because you have to put your chunks of code to smaller helper functions and use them inside your render() function like this guy suggested:

JSX is also the reason when you have to keep splitting your 15-lines-of-html-code component to 3 components, 5-lines-of-code-in-each.

Don’t think that this is a great workaround which makes you a better developer because you now have to structure your code like this.

Here is the thing:
When you write a relatively complex component - which you are probably not going to put to public github repo tomorrow to showcase it on hackernews - this approach of splitting components into super-dumb components because of JSX restrictions will always put you out of flow when you are solving real business task. No, I am not saying that the idea of smaller components is bad or not working.
You should clearly realize that you need to split your code into components to keep you codebase manageable and reusable. But you should do it only when you think that this specific logical entity in your code should be a separate component with own props, - and not on every two-three IFs that you write via ternary operator! Every time you create a new component here and there it costs you and your flow a penny (probably more) because you need to switch from business-task thinking (when you already remember current component state model, and you just need to add some html here and there to make it running) to “manager thinking” - you go create separate file for your component, start thinking about props of this new component, and how they map to state, and how you are going to pass callbacks inside, etc, etc.
As a result you get reduced speed of writing code by being forced to leverage excessive and premature (potential) modularity of components in places where you don’t really need it. In my opinion, premature modularity is very similar to premature optimization.

For me and my team the readability of code is important, but it is still very important that writing code is fun. It is not funny to create 6 components when you are implementing really simple calculator widget. In a lot of cases, it is also bad in terms of maintenance, modifications, or applying visual overhaul to some widget, because you need to jump around multiple files/functions and check each small chunk of HTML separately. Again, I am not suggesting to write monoliths - I suggest to use components instead of microcomponents for day-to-day development. It is just about the common sense.

Working with forms and Redux in React will make you type all day long

React is about pureness and clean one way flow, remember? That’s why LinkedStateMixin became a persona non grata and now you have to create 10 functions to get input from 10 inputs. 80% of these functions will contain single line with this.setState() call, or redux action call (then you will probably have to create another 10 constants - one per each input). I guess that would be acceptable if you could generate all this code by thinking about it.. but I am not aware of any IDE that could significantly improve this.
Why do you have to type so much? Because two-way binding is considered dangerous by big guys in big-enterprise apps. I can confirm that two-way data flow code sometimes is not as clean to read, but most of these fears are mixed with overall pain about Angular 1 where two-way binding was bad, and still.. probably it was not the biggest fail even there.

Let me show you the quick-editor set of components I’ve built recently with Vue.js for our Drupal website (I beg your pardon for the design - it is a backend UI for our operators, and our designers are busy creating frontend interfaces for our customers so this piece is waiting to get design overhaul):

I can’t share the code for obvious reasons but writing it in Vue was real fun, and the code is very readable.

And I know for sure that creating a separate function for each input to handle a widget like this in React would certainly not make me happy.

Redux sounds like a synonym of verbosity, as well. And it’s easy to find developers that blame that Mobx is turning React into Angular just because because it leverages two-way binding - see my point #1 about purity. It looks like a lot of smart people value purity of their codebase more than getting job done (which is fine if you don’t have deadlines, I guess).

Excessive tooling

React was created with Babel in mind. You can’t do a step in real-world React app without a bunch of npm packages here, compiler to ES5 going first. Simple app based on official react starting package code has around 75MB of JS code in node_modules.
It is not a critical thing, it’s more related to JS world in overall than to React, but it adds up to overall frustration when using React as well.

Angular 1: too much freedom is sometimes bad

Angular 1 was a great frontend framework that is located in the opposite corner (from React) of the imaginary JS map of purity and readability of codebases - it allows you to start quickly, it gives you some real fun for your first 1k lines of code, and then it practically forces you to write shitty code. You will probably get lost in directives, scopes, and two way data flows across all the layers of your app will just be a cherry on the pie of the code that your freshly hired devs won’t even want to touch because it won’t be manageable.

Why so?
Angular.js was created in 2009 when frontend world looked pretty simple and nobody was even thinking about state hygiene. You can’t blame these guys - they were just creating competitor of Backbone with some new concepts and they wanted to do less typing.


Just build hello world app and look at the amount of files you got in your repo. You will have to use Typescript (and I am not 100% sure it is something I am going to enjoy doing every day - great writeup from Eric Eliott on this topic) and compilers to start working. It was enough for me.. For me is still too much typing before I start real work. To my mind, Angular 2 guys are trying to build perfect framework which will beat React, instead of trying to build a framework which solves business tasks for average user. May be I am wrong and my mind might change - I don’t have a lot of experience building Angular2 apps yet, we’ve just built demo customer calculator app for our in-house evaluation. Wonderful comparison page on Vue.js website states that Angular2 is a good framework which share a lot of concepts with Vue.


In short, Vue.js is a thing that I’ve been waiting for a long time ( I will be talking about Vue.js 2 which got quite a few improvements over first version of Vue and this is the current stable framework version). For me, in terms of elegance and conciseness, and focus on getting things done, Vue.js is the biggest change to JS after the day when I was blown out by jQuery in 2007.
If you look to Vue.js popularity graphs you will notice it is not just me: https://www.google.ru/trends/explore?q=vue.js,react.js,angular.js
Vue.js is one of the most rapidly growing JS frameworks in 2016, and I think it’s not just another hype based on fans that switch to newer JS framework every 3 months, or authority (and money) of one big company.

Laravel added Vue.js to core, which is a big thing.

Pros of Vue.js

Vue.js hits a sweet spot between readability&maintainability and fun. A spot between React and Angular 1, and if you look at Vue guideline, you will instantly notice how many nice things it got from these frameworks.
From React, it got component-based approach, props, one-way data flow for components hierarchy, performance, virtual rendering ability, and understanding of importance of proper state management of apps.
From Angular, it got similar templates with good syntax, and two-way binding when you need it (inside single component).

Vue.js is very easy to start - I’ve seen this in our team. It does not enforce any compilers by default, so it’s really easy to drop in Vue to your legacy codebase and start improving your jQuery mess with good JS code.

Right amount of Magic

Vue.js is very easy to work with, both in HTML and JS - you can do pretty complex templates without losing your focus on business task and the template usually maintains great readability even when it gets really big - at this moment you’ve usually made a good progress in terms of business task solved, and you might want to refactor templates and split them into smaller components - at this moment you see the whole “picture” of your app a lot better than at the moment when you’ve started.

From my experience, this differs vastly from approach that I used to have in React: I saved myself a lot of hours here. In React, you have to split components into micro-components and micro-functions at the time of writing the initial version of your code - or you will literally get buried in the mess of your code. In React you will spend a lot of time polishing the props and refactoring your super-small components (that will never be re-used later) again and again since you don’t see clearly if you have to change the flow of your app logic somewhere in the middle of the code writing process.

Working with html forms is a breeze in Vue. This is where two-way binding shines. It does not bring any issues to me even in complex cases, though watchers may remind of Angular 1 at first glance. One-way flow with callback passing is always at your service when you do your components splitting.

If you want some compiler magic, linting, PostCSS and ES6 - you got it. Vue extension seems to become a default way of writing public components in Vue.js 2. By the way, idea of scoped CSS of component, working out of the box, is something that looks really nice and can reduce need in proper css hierarchy naming and technologies like BEM.

Vue.js has pretty simple and useful state and props management in core, via data() and props() methods - they work great in real world. Better separation of concerns available via Vuex (which is to my understanding similar to Mobx in React - with some mutation of state involved).

I think a good percent of Vue.js use cases won’t ever require such a state management as Vuex provides, but it is always good to have an option.

Cons of VueJS

  1. The biggest one: not descriptive runtime errors in templates. This is pretty similar to Angular 1. Vue.js manages to give a lot of useful warnings for your JS code, for example there are warnings when you try to mutate props, or using data() method incorrectly - the good influence of React can be very well seen here. But runtime errors in templates are still a weak point of Vue - exception stacktraces in a lot of times are not useful and are leading into Vue.js internal methods.
  2. The framework is young. No stable community components - a lot of them were built for Vue.js 1, and it is sometimes not easy for newcomers to see from github repo which version of Vue the library is built for. This issue is leveled by the fact that you can do huge things in Vue without any additional libraries - you will probably just need some ajax library (vue-resource will be a good choice if you don’t care about isomorphic apps, axios otherwise), and probably vue-router which is considered as core library with good support.
  3. Chinese comments in code across most of community libraries - this is not surprising, Vue.js is getting very popular in China (the author speaks Chinese).
  4. Single-guy project? Not exactly a real issue, but something to consider. Evan You is the guy who built Vue, after working at Google and Meteor. Laravel also used to be a single-guy project, it is still a huge success, but you never know..

Vue.js in Drupal

Disclaimer: we do not plan to use Drupal 8 any time soon at Qwintry, since we are switching to faster and simpler PHP&Node.js frameworks, and our legacy codebase is Drupal 7.
Since our legacy system qwintry.com is powered by Drupal, it was very important for us to test this new framework here, in the wild. I am not proud by a lot of code in our legacy codebase, but it works and generates our revenue, so we respect it, improve it, and build a lot of new features here. Here are the list of things I’ve built in Vue&Drupal already:
In-place node editing for complex order entities. This includes generating invoices for customers, and quick edit of product items. It required building basic JSON api for loading and saving of nodes - nothing too fancy, just a few menu callbacks.
Two REST-powered dashboards for proprietary Saas software we are using so our customer support does not have to login to separate websites to quickly check information related to specific customer - everything is built right inside customer profile in our website now.

I know a lot of backend developers are still stuck in 2010 and Drupal 7 core Ajax system.
I know how complex Drupal might be when you try to build some fancy multi-step ajax interaction form using core features - it’s just crazy hard to maintain this code later. Yes, I am looking at you, ctools_wizard_multistep_form() and you, ajax_render!
At the same time, these Drupal developers are pushed forward by modern world UI requirements, but they might be scared by increased complexity of modern JS frameworks. Yep, it’s me a year ago. Let me tell you - you won’t find a better time and way to improve your interfaces than get Vue.js now, put it in your /sites/all/libraries, add it via drupal_add_js to your template, and start hacking around. You will be shocked how easier it is to maintain a number of pure JSON callbacks sitting in your hook_menu when the client side, including forms, is completely powered by Vue.

Vue.js in Yii2

Fun fact: Yii was created by a Chinese speaking guy - Qiang Xue. So, you might call Yii+Vue stack not just very difficult to pronounce, but also a Chinese stack :)
For our new version of Qwintry.com (not yet public) we chose Yii2 which I believe is one of the best and fastest PHP frameworks available. It is definitely not as popular as Laravel which is rocking the PHP world now, but we are pretty happy with our Yii2 stack now (though we are looking at Laravel from time to time, the guys are doing a great job).
We are gradually reducing amount of html generated by Yii2 and PHP, and concentrating more on REST backend which generates JSON for our client-side which is powered by VueJS. It is mostly API-first approach for all our Active Record models.
Here, we are taking API seriously and that’s why we are spending a lot of time building good API documentation even though it is only used in-house.
With PHP7&latest MySQL the response times of our Yii2 JSON backend does not differ much from Node.js backends (15-20ms are the numbers I am talking about), so it’s more than enough for our needs, and 10-20 times faster than we could imagine to achieve using Drupal. At the same time, it’s good&old PHP with all the power of composer libraries and stable codebase at our hands.
So, Yii2&Vue.js responsiveness is huge, and in terms of code it’s a pleasure to work with.

We are also using Vue.js in a number of internal projects.


We’ve been writing Vue.js code every day for around 3 months in various projects, with impressive results. 3 months is nothing in backend world, but it is something in JS world :) We’ll see how it goes further.

I expect Vue to become a primary JS framework in 16-24 months if Evan You makes right steps, at least around backenders and smaller teams of frontenders. I still consider React stack to be the primary JS framework of 2017, especially if React Native manages to mature and improve itself with same pace it used to.

UPD: this post got to frontpage of HackerNews and there is useful discussion with 200+ comments there: https://news.ycombinator.com/item?id=13151317
It also got to top posts of Reddit webdev, 60+ comments here: https://www.reddit.com/r/webdev/comments/5ho71i/why_we_chose_vuejs_over_…


Great overview of pros&cons!
I also dislike jsx-mess and looking to vue.js

With all buzz around A2 it's not possible to learn team instead of solving real tasks, actually I see no reason for that.

11 December, 2016

lol you expect us to take your opinion seriously while you use Drupal

11 December, 2016

seriously! don't drag down vue with any association to the garbage drupal platform.

12 December, 2016

lol you expect us to take your opinion seriously while you comment anonymously

12 December, 2016

The core fundamentally doesn't make sense for a modern stack. Read over the architectural notes of the (1) consulting company that does all the core development work (owned by the creator of drupal). If you've worked in any modern stack reading his blog just sounds like a person trying really hard to justify the idea of a lamp cms in 2016. "here's how this buzzword could work here" "headless" "api first" yadda yadda. Since all of his followers never built anything outside of clicking an interface they eat it up and use the buzzwords to justify their technical decision. Nothing 8 does is anything that laravel / express / rails / django haven't already done since as early as 2010. Continuing to sell clients on this garbage stack is harmful to the advancement of the web, and given that we're web professionals, it's becoming more and more important to keep up with application development.

This isn't 2008. Stop using drupal.

12 December, 2016

You should also take a look at Cx.
Cx offers advanced data-binding, form validation, component library and much more.

11 December, 2016

Holy carp no. Adding even more dependencies on top of react. This is going in the opposite direction from what's being discussed.

12 December, 2016

The article is well-written and does have several valid aspects. Of course it can be taken seriously. Maybe the last commenter is such a Rockstar developer that he can make a company throw years of development over board, or he simply doesn't take any Job at a company that uses drupal. However, that's not the real world.

Btw, about many functions and constants in react Forms: there are practical approaches. I am working on a large App that started before redux, we use alt.js but that shouldn't matter. Usually for Forms i have a single "edit" action and all Inputs have the same onChange handler that calls something like `myAction({[e.target.name]: e.target.value})`, works fine. Of course it needs transpiling or more complexity Code but the concept is simple and powerful. In the store/reducer, you just merge the received data onto the state.

11 December, 2016

Thank you!
All in all, I was not going to present React as a bad solution, it is a great framework with huge community, it’s simple and scales great, and finally it boils down to personal preference of syntax, and approach to daily work - I just wanted to highlight the viable alternative for practical and lazy developers, like me. I agree, you definitely can add some components to enhance your React setup and work with forms.

12 December, 2016

With all due respect, this is yet another "look here's my opinion and y'all should listen" post written by an incompetent programmer.

12 December, 2016

I don't know, the author seems competent and well informed. I'll take this article as objective and factual reasons to stay away from both React and Angular.

12 December, 2016

Competent and well informed? Have you read these comments?
- https://www.reddit.com/r/webdev/comments/5ho71i/why_we_chose_vuejs_over_...
- https://news.ycombinator.com/item?id=13152368

"Or you can learn JavaScript."

12 December, 2016

Thank you for your opinion. I guess I’m already competent enough to not become angry or upset when I read such comments :) You can use one method in your component to handle 10 inputs, but in real world you will have to normalize values that go into your method and check targets, and your method will quickly become ugly, for example try to use this approach when you have an array property in state, and the form field representing this array is rendered as as set of checkboxes. That’s why most of the tutorials on React components which use internal state (including Facebook official guides) - tend to use separate methods for each input, it’s just cleaner in the long run. This is not something you can’t solve in React by some coding and adding more components, but my opinion is that it should to be solved on basic level of the view framework I am using. (And when using Redux - you will have to create all your constants anyways)

13 December, 2016

Really good point. I love react and using in production for over an year. But forms are the biggest pain in react. But i think considering it shines in every other aspect, you should conder switching to a templating engine is better than going with a powerful rendering engine like react

17 December, 2016

About forms, here's a great React component that generate customisable forms and handle all the validation for you : https://github.com/mozilla-services/react-jsonschema-form

12 December, 2016

Thank you! Looks like a nice solution when you need to generate significant amount of simple forms (like, admin sections), though from my experience such runtime generators tend to make your code difficult to read when you need some fancy improvements to this form, and that form, and that form - you end up with a lot of overrides here and there. This approach reminds me of Drupal Forms with it’s form_alter() and field/theme templates - great for typical websites, not so great for big, weird and custom projects.

12 December, 2016

Very well written Article. React is still an incredible piece of software but i share you opinion more or less. However we decided to use Aurelia instead of Vue.js - to me both frameworks are very good. Aurelia is just even less boilerplate code and feels a little more state-of-the-art JS like (although sometimes it's shoots over the top)

12 December, 2016

Thank you! Yes, I’ve heard a lot of good things about Aurelia, and it looks really similar to Vue.js, haven’t tried it yet though.

17 December, 2016

lol. I like vue, but please do not associate it to drupal. drupal is complete garbage.

12 December, 2016

Stop selling your clients on Drupal. Move on to express / rails / django / laravel. this isn't 2008.

12 December, 2016

Well, we do not start new projects on Drupal anymore (for last 3 years, I think), this website is pretty outdated and needs big update. I just post to my blog here from time to time. Drupal is not something we do every day now, but we still have legacy systems on it. You can read my thoughts on Drupal cons here: http://pixeljets.com/blog/building-scalable-it-system-delivery-us-russia…

12 December, 2016

JSX gives UI-as-a-value. Component trees are just objects and can be used like any other - manipulated, abstracted across, etc.

HTML templates are far too much magic for me.

12 December, 2016

You mention immutability as a point against React in a heading, and then never speak of it again. I'm not sure you fully embraced how immutability can help you reason about your programs.

I haven't worked directly with React much, but usually through thin wrappers around it from ClojureScript (Om.next, Rum, Reagent and Reframe). Paired with ClojureScript, those libraries built on top of the foundation of React have been a joy to work with. I won't deny there is an inherent learning curve when it comes to picking up ClojureScript (it is a Lisp after all), but I feel pain trying to go back to writing plain JavaScript now.

12 December, 2016

>> I'm not sure you fully embraced how immutability can help you reason about your programs.

If you don't get it then you're not embracing fully enough. QED

12 December, 2016

Immutability was just mentioned as a marketing buzzword here. I respect functional patterns and immutability is a great thing when used in a right place - finally in a lot of cases it results in better code! But real world development is about balance and timing, and my concerns are mostly related to current situation specifically with immutability support and necessity in JS. If Javascript does not support immutability in core and the developer adds Immutable.js and then spends a day trying to tie it to Lodash and existing legacy code of system, because he did not realize that Lodash is not going to work (yes I know about lodash wrappers for immutable structures, it is just an example), and Immutable.js core methods are not enough for him to complete the task - so as a result, the deadlines are not met - that is what I call bad developer who was sold by marketing of Facebook and buzzwords, not functional paradigms. Business in a lot of cases values the speed of development and medium-quality code a lot more then bullet-proof reliability and perfect code, tied with slower development - because at the end of day, dead business does not need repos full of perfect code, it needs features completed on time! I see this from time to time - people who value paradigms and new technologies more than effective business tasks solving, and that’s what I am talking about in the post. When Facebook enforces immutable structures inside their huge team - that is completely different story. They see how it benefits their business, because quicker development techniques with plain JS are already not reliable enough for them, they break things too often. I see no reason why you should not use Clojurescript or Elm in pet projects or in production if you manage to do everything on time and the code is maintainable (not just by you, but most of developers that might see this code later) - it’s a great thing to learn new technologies, it makes you happy and finally makes you a better developer. But I doubt that small and medium sized business typical tasks require functional patterns like full immutability being enforced in current stage of JS development - the class of tasks these companies usually solve by JS is usually pretty simple, at the same time medium-skilled developers from the market might get troubles with such functional code, and good developers are expensive. (This situation might change in a few years when functional patterns will be more common)

Another bad aspect of immutability being enforced by Facebook in JS as part of “default” stack (yep, the aspect not directly connected to immutability, but connected to situation with functional patterns in JS, and very important) is that it increases JS developers segmentation. When “oldschool” developers that have billions lines of legacy jQuery code inside their legacy systems are trying to jump from their mess to React + immutable.js it is just too much of new stuff for them in terms of mindset shift and code rewrite. When these guys look into webpack configs, Flux and Immutable.js docs, a lot of them think f*ck that, I will continue to write my jQuery code, it is just crazy, I just wanted this input to be saved to DB via ajax. Vue.js (and some REST apis on backend) can do miracles for these developers, because the most possible alternative is: just sit there in old jQuery code and suffer. When they master Vue.js - some of them will probably shift to React (and Immutable.js) if they see the need for it in their code, because going from Vue.js to React won’t be that hard already.

For some developers that already use React and Immutable.js in their production code and are happy with it - Vue.js probably won’t be so interesting. That’s why there is so much negativity from young and smart devs who are already using React, I guess.

13 December, 2016

Agreed re: the conditionals and loops, but you can add them to React pretty easily: https://github.com/AlexGilleran/jsx-control-statements

12 December, 2016

Looks interesting, thank you for the link!

12 December, 2016

I think this is a well written post based on real experience. I don't think it's fair to rate the compentence of a developer based on the frameworks he uses as other commenters here seem to be doing. I am a big fan of react. It has some strong idealologies however it still can be quite flexible. I use it for a very large SPA with a custom flux-ish implementation while using webpack and react-router. The npm requirements to build the app is 100mb which is a bit silly but the full JS code loaded by the app is less than 1mb and that is lazy loaded in chunks when needed. I have not used View.js but the greatest con for react for me is the jsx compile stage and the npm build requirements. I love the modularity and comment architecture though. I would consider moving g to View.js but I'm getting worn out by all the frontend chase in the JS community. The real world forces you to get things done. Sometimes we just don't have time to try all the new and shiny and need to just get really good at what is good enough.

12 December, 2016

Thank you for this supportive and thoughtful comment. I agree that JS world is jumping around new shiny technologies like crazy. I think React is great in many aspects, and it is definitely good enough not to jump to Vue.js if it gets the job done for you! At the same time, I hope this post will motivate people who are stuck in jQuery and Prototype but who are feeling pain about all these landscape changes in JS around them - Vue will be a great step forward for them and their interfaces.

12 December, 2016

I am your precise audience. My team works in legacy Drupal land as well and we haven't felt the need to move to any JS frameworks to manage our front-end. However, some of our stuff is about to get a little more complicated so we may need to. Since I manage our build process, I started looking into incorporating React and was a little discouraged by the amount of stuff we'd need. Your article has definitely prompted me to take a look at Vue.js. Thanks!

12 December, 2016

Thank you for your feedback! I’m glad it helped someone :)

13 December, 2016

Nice post, thank you for your opinion! I too prefer Vue over React, but it's just a personal preference, I can work with both.

12 December, 2016

Vue.js is not a framework.

12 December, 2016

While reading "Not being able to put plain old IF condition to some block of HTML code sucks" i must say .. IMHO if you need more than a simple ternary operator, you simply have an incompatible datastructure or -even- mindset.

Still reading on to learn about VUE.js vs React though..

12 December, 2016

Is the link formatting broken here?

Simple app based on official react starting package code has around 75MB

12 December, 2016

abstract the if condition out of the render method into something like `renderTitle` then in that method put all the ifs ands or buts...easy peasy

12 December, 2016

I'm using the Vue-based Quasar framework (http://quasar-framework.org/) and it is simply amazing.

14 December, 2016

Great write up with real-world, practical points. A very refreshing post on how web developers in the non-Fortune 500 world work.

I've created apps in Angular 1 and it was decent, Angular2 (thru the beta/rc process) was a nightmare.

At work, my catchphrase for Angular2 (beta/rc) was "everything made easy is hard again".

Been using Vue.js for about 2 months and absolutely love it. Doubt I will ever go back to Angular2.x

Thanks for posting this!

15 December, 2016


A very nice comment about Angular2 from here:

All Google documentation is like reading Microsoft docs from the early 2000s.
“Setting up an Angular project is a piece of cake! Just make sure the stateless reference prototype mutator inherits from the base memory loader legacy object implementing the MODOK service provider (not part of core: see here for equally unreadable details). You’ll then be ready to compile your Angular kernel, being careful to use Webpack 2.3.9 (note: not 2.3.8 as supplied with the repository). This is all you need to know to get started on a great Angular project. Angular: making development simple and fun again!”

16 December, 2016

Have you checked Aurelia yet? It's a great framework! I'm having great fun using it. Simple, productive and doesn't get in the way.

16 December, 2016

Reviews about Aurelia are pretty positive. I haven’t tried it yet though.
It looks really similar to Vue.js in terms of syntax and approach, which is nice.

17 December, 2016

Really? You really tell that you won't use Angular 2 because of Typescript and big amount of files? You really tell that Hello world project on React requires 75MB of npm libraries? Dude, if these are problems for you.. I don't even know what to say. You should understand that Vue is developed by a group of people and React is developed by a giant corporation and it will have appropriate quality of support. Imho.

19 December, 2016

I am not saying that TypeScript is bad, but I don’t think it will make my life dramatically better: https://medium.com/javascript-scene/angular-2-vs-react-the-ultimate-danc…

I am not saying that 75mb of npm libraries is a huge thing to consider. It’s just a sign of bloat.

I tend to respect and use “groups of people” work pretty much like I use projects from giant corporations. I’ve seen a lot of times how giant corporations fail to provide a great product that gets traction from community (this is not related to React, which is a great product).

23 December, 2016

you can use rml to replace jsx: https://github.com/yiminghe/rml

22 December, 2016

Are you honestly saying that a company that has thousands of developers can present a more clear vision and work-flow than one of a single developer or maybe a 10 person team?

23 December, 2016

Why is Chinese language part of the cons? Are you a racist? If not, then that should not be an issue. (I'm not Chinese)

26 December, 2016

I also rebult my project with vue2 and yii2 these days. But I got an issue that, I didn't know how to use the csrf method of yii2. Because I threat the front end project as a static file, no server side render. Any clues?

26 December, 2016

Interesting post! I needed to make the same decision between Vue, Angular and react. Angular is just too much overhead, and Vue looked lightweight and promising. However, React still won me over for the following reasons:
1. The sheer size of existing community
2. The sheer amount of existing libraries and components, which minimizes reinventing the wheel.
3. Actively maintained by a whole dedicated team in Facebook, and the fact that Facebook actually uses react in production.
4. And the most important factor would be React Native. If you also include react native in the google trends' page, you'll see that it far outgrows all of vue, angular or react combined. Thus, using react for web and react native for mobile apps, makes the greatest sense to us. This has several obvious benefits:
- We can write mobile apps with near native performances using a similar approach when writing our web app. "Learn once, write everywhere"
- Some extent of code-sharing between web and mobile app is made possible, which is awesome.

But of course, if web dev is all that a company concerns, Vue might be a better choice if developers don't mind reinventing the wheels.

28 December, 2016

Would not like to say much, just that Vue is better choice if you wanna reinvent the wheels.

29 December, 2016

I agree most of your points. Did you look at Riot.js?

29 December, 2016

Post new comment

Private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

Note for potential spammers: all links in your comment will not be indexed by search engines.

Anton Sidashin

Anton Sidashin senior developer, Pixeljets co-founder

I'm a web developer specializing in PHP and Javascript, and Drupal, of course. I'm building Drupal projects since 2005, and I was working as full-time senior engineer in CS-Cart for a while, building revolutionary e-commerce software. In my free time, I enjoy playing soccer, building my body in gym, and playing guitar.

Drupal.org ID: restyler
Drupal association member