Why we chose Vue.js (and not React)
Recently, the Qwintry team began an active migration to Vue.js in all of our old and new projects:
Why our programmers chose Vue.js, says the head of the development department of Qwintry LLC . Anton Sidashin âž”
Briefly about us: the Qwintry project is used by half a million customers around the world, we have two warehouses (in the US and in Germany) on our own cloud software, and we are one of the largest mail forwarding services in the US in terms of visitor traffic and shipments. We help people buy goods in US online stores and manage their packages in our personal account, and also allow us to save a lot on international delivery. We use our own IT platform and logistics chains to make high-quality international delivery at a good price.
Our package in the doors of the client - from customer reviews
')
Qwintry has a rather large code base, mainly consisting of PHP and JS (+ Swift and Java for mobile applications).
We decided to use Vue.js after we built a test application with identical functionality - our calculator - on React, Vue.js and Angular2.
The popularity of React has skyrocketed over the past year or two, and now, perhaps, this is the default choice for the JS developer who wants to write something more complicated on the front end of a three-line paragraph of code.
We ran several SPA and dynamic widgets on React, we tested React Native (for iOS) and Redux. I think React was a big step for the JS world in terms of state awareness , and it showed many people what real functional programming is in a good, pragmatic way. I also think that React Native is great - it literally changes the entire landscape of mobile development.
Disadvantages of React for me:
Do not misunderstand me. I appreciate the purity and simplicity of the render () approach — without a doubt, this is a great idea that works in actual development. I'm talking about other things.
I think that this level of rigor and purity can be useful when you have 1000 developers working in your company - at about the same time when you decide to develop your own syntax to translate all your PHP code into static types . Or when you are a Haskell developer who decided to comprehend JS. But most companies have far fewer developers, small budgets and goals that differ from those of Facebook. I will focus on this in more detail later.
Wait a second! I know! This is “just pure javascript with special syntax” . For our guys who paint design in sketch and photoshop and then convert it to HTML, which have tight deadlines and who are putting on this form right now, wrapping it in a number of divs - right now - perfectly clean and “clean” ES6. Applying a certain design to React components is not a fountain job, because JSX lacks readability. The inability to put the good old IF in some block of HTML code is bad, and please don’t believe React fans who say that “if () is the last century, and now all normal programmers use ternary operators.” Let me assure you: JSX is still a jumble of HTML and JS at the moment you read and edit it, even if it is then compiled into pure JS.
Many developers think (and for some time I agreed with them) that such syntax restrictionswill make them stronger will help them write more modular code, because the limited JSX (out of the box) forces you to put pieces of code into small auxiliary functions and use them inside The render () functions, as suggested by this and many other guys:
stackoverflow.com/a/38231866/1132016
JSX also forces breaking components-into-15-lines-HTML into 3 components, 5-lines-HTML-into-each. Do not think that this approach makes you a better developer.
Here's the thing:
When you write a relatively complex component - which you are probably not going to post tomorrow's public rep on GitHub to demonstrate it on HackerNews - this approach of breaking components into super dumb components due to limitations JSX always pulls you out of the stream, which you solve a real business problem. No, I'm not saying that the idea of ​​fractional components is bad or does not work. You must be clearly aware that you need to divide the functionality into its parts in order to keep your code in a manageable state. But you should do this only when you think that this particular logical entity in your code is better to be a separate component with its own props - and not for every two or three conditions that were written using the ternary operator! Every time you create a new component here and there, it costs you a very specific effort and disrupts your flow , because you need to switch from the architect’s thinking (when you already remember the current state of the component model and you just need to add HTML here and there, for the functionality to work) on the manager's thinking: you need to create a separate file for the component, think about the props of this new component, how they map to the state, how you are going to forward callbacks, etc. As a result, the speed of writing code is reduced, because you have to spend effort on premature modularity of components where you probably would not need it, if the JSX syntax is more flexible. In my opinion, premature modularity is very similar to premature optimization. For me and our team, the readability of the code is important, but still enjoying the pleasure of writing code is also very important. This is not cool when the simple form of a calculator requires you to create 6 components, each with its own props.
Often, such hyper-modularity is bad from the point of view of maintenance, modification or application of a new design, because to update the html in the widget, you need to jump over several files / functions and check each small piece of HTML separately.
Again, I do not propose to write monoliths. I suggest using components instead of microcomponents for daily programming. Speech about balance and common sense.
React - it's about cleanliness and one-way flow, remember? That's why LinkedStateMixin has become persona non grata , and now you have to write 10 functions to get input from 10 form fields. No, you can, of course, write one function that will check e.target, but ultimately there will be such a tree of conditions with normalization of the data arriving from the form that you want to cry; so no one does. 80% of these functions will contain a single line with this.setState () or the Redux action call. (Then you will probably have to create 10 more constants - one for each action). I think this approach would be acceptable if you could generate all this code just by thinking about it ... But I don’t know of any IDE editor who could greatly simplify writing such an interface. Why do you have to print so much? Because the big guys decided that two-way binding is dangerous in large enterprise applications. I can confirm that two-way binding is sometimes not so simple and not so readable, but most of these fears are associated with the general suffering of people from the first version of Angular, where the two-way binding was perhaps not the best. And yet ... this was probably not the biggest miscalculation even in Angular. Look at my fast editor, which I recently nestled with Vue.js for our platform on Drupal (I apologize in advance for the design, this is the UI backend for our operators, and the designers are busy creating interfaces for our clients, so this piece of functionality is waiting for its hours to become beautiful):
I can't show the code for obvious reasons, but writing it in Vue was very nice, and the code was very readable. And I know for sure that if I wrote a separate function for each field of the form, as in React, I would, of course, not jump from happiness.
Redux is also verbose and requires a lot of writing . And on the Internet, it is easy to find statements by developers who accuse Mobx of turning React into Angular only because Mobx uses two-way data binding (see clause 1 on “cleanliness”). It seems that many smart people appreciate the “purity” of their code, rather than a fast and well-solved business problem (which, in principle, is normal if you do not have deadlines).
At the same time, I think the very concept of Flux / Redux is very cool. Redux is simple and gives an incredible level of control over the state of the application, and separating the state from the purely interface pieces - this immediately simplifies the writing of tests. But, unfortunately, this is all given by a very large amount of writings. Yes, time-travel debugging as a side effect is awesome. But personally, I am ready to sacrifice them for speed writing code, and think about whether you need time-travel, if you need to come up with a constant for each field in the form.
React works with the original Babel aim. You will not make a real React application without a decent heap of npm packages, starting with the ES5 compiler. A simple application based on the official starter build gets about 75 MB of JS code in node_modules. This is not a critical thing and relates more to the JS world as a whole than to React, but it still adds frustration and irritation.
My verdict on React - allows you to write excellent, readable code, but to write it a lot and sadly. Well, the problems for the designers who do not own, and who do not want to own ES6 inside HTML, do not disappear anywhere.
Angular 1 is a good framework for its time, located in the opposite corner (from React) of an imaginary JS card of purity and readability of the code. Angular allows you to start quickly, allows you to enjoy writing the first 1 lines of code, and then it practically forces you to write code that does not work out very well . You are likely to get lost in the directives, scopes, and two-way data streams running through all layers of your application will be the final chord of the swan song of your code, which fresh developers do not even want to touch, because something will break. Why is this happening? Angular.js was created in 2009, when the world of front-end development looked quite simple and no one even thought about good state control over the application. Do not blame the authors - they just made a competitor Backbone with some new chips and wanted to print less (and they managed to do it all, another question is what price).
Just build a hello-world application and look at the number of files that end up in a turnip. You'll have to use Typescript (and I'm not 100% sure that I want to do every day - no, guys, static typing in JS is not a panacea, but you have to print again, good thoughts from Eric Eliott on this topic ) and compilers to get going. This was enough for us to postpone Angular2 until better times. I'm lazy, and for me it's too much a boilerplate before you start writing real code. In my opinion, the authors of Angular 2 are trying to build an ideal system for an enterprise that will defeat React, rather than trying to build a framework that solves business problems for the average user. Maybe I'm wrong, and my opinion may change - I do not have much experience in Angular2, we just built a test calculator application, after all. The wonderful comparison page on Vue.js website calls Angular2 a good system, which with Vue.js combines a lot of ideas.
Vue.js is a thing I have been waiting for a long time (hereinafter I will talk about Vue.js 2, which received a lot of improvements compared to the first version of Vue, and this is the current stable version of the system). For me, in terms of elegance and conciseness, as well as focusing on solving real problems, Vue.js is the biggest breakthrough in JS since the day when Jquery hit me in 2007. If you look at the graphs of Vue.js popularity, notice that he pleased not only me this year:
On Github Vue - Top 1 JS project of 2016 (among repov with source codes).
The popularity in Google Trends Vue.js in 2016 sharply bypassed React (of course, this is the average temperature at a very large hospital, and depends heavily on the formulation of the request - a very indirect sign of popularity).
https://www.google.com/trends/explore?q=vue.js,react.js,angular.js
Vue.js is one of the fastest growing (in terms of community or at least the number of likes in githubs and Vue Dev Tools users in the chrome store) JS solutions in 2016, and I’m sure that this is not just another fashionable a library for hipsters who switch to a new JS framework every 3 months, or the work of a large company’s PR department.
Laravel added Vue.js to the core, and this is a serious claim.
Vue.js maintains an excellent balance between readability, maintainability of the code and pleasure from its, this code, writing. This balance is at a roughly equidistant distance between React and Angular 1, and if you look at the vue.js guideline, you will immediately notice how many useful ideas he borrowed from these systems.
From React, Vue.js took a component approach, props, one-way data flow for the component hierarchy, performance, the ability to render on the backend, and an understanding of the importance of proper state management. From Angular1, Vue.js took similar templates with good syntax and two-way binding, but only where you really need it and will not allow you to shoot yourself a leg right away (inside one component). Starting to write code under Vue.js is very easy - I saw it in our team. Vue.js does not require any default compilers, so it is very easy to add Vue.js to your legacy codebase and start rewriting jQuery hash to readable code.
Vue.js is very simple in work, both in terms of the HTML-centric approach and in terms of JS developers: you can make quite complex templates without losing focus on a business problem, and the resulting HTML template is usually well read even when he is already big. By this time, as a rule, you have made good progress in solving a business problem and you may want to reorganize the templates and divide them into smaller components - at this moment you see the whole “picture” of your application much better than at the very beginning. My experience shows that this is significantly different from the approach that programmers typically use in React, and this difference saves a lot of time and effort for programmers using Vue.js. In React, you are forced to break components into microcomponents and microfunctions right at the time of writing the initial, “draft” version of the code, otherwise you will be literally buried in a jumble of curly braces and html between them. In React, I spend a lot of time polishing props and refactoring super small components (which, of course, will never be reused) over and over again, because I don’t see so clearly when I suddenly need to change the code logic in the middle of the process.
Working with HTML forms in Vue.js is a pleasure. This is where biparting actually helps out. Even in difficult cases, there are no problems, although at first glance watchers may remind Angular 1. One-way data flow is always at your service when you split up components.
If you want to compile, linting, PostCSS and ES6 is not a problem . Single-file components seem to be becoming the main way of writing public components in Vue.js 2. By the way, the idea of ​​Scoped CSS working in single-file components out of the box is something that looks really nice and can reduce the need for strict CSS naming rules classes and technologies like BEM .
Vue.js has quite simple and useful state management through data () and props () methods - they work fine in real development. If the soul asks for something more for state management, there is Vuex (which, in my opinion, is similar to Mobx in React - the state is mutable). I think a good percentage of Vue.js applications will not require state management via Vuex, but it is nice to have an alternative.
The holivar theme, in general, and react, and vue.js - work quickly. But nevertheless, apparently, vue.js is on average noticeably faster.
A wonderful link from the comments on the TodoMVC run with measurements:
eigenmethod.imtqy.com/mol/app/bench/#bench=%2Ftodomvc%2Fbenchmark%2F#sample=angular2~angularjs~mol~react~vue~vanillajs#sort=fill#
And here are more detailed layouts (from the interested party, really) .
Another, detailed and intelligible benchmark comparison:
stefankrause.net/js-frameworks-benchmark4/webdriver-ts/table.html
The biggest: unpleasant execution time errors in templates. Sacrifice for the sake of convenience of writing code. This is very similar to Angular 1. Vue.js manages to issue many useful warnings for JS code: for example, there are warnings when you try to mutate props or incorrectly use the data () method, the positive effect of React is very noticeable here. But runtime errors in templates are still a weak point. Vue.js. Exception stack sets are often useless and lead to the internal methods of Vue.js. In this case, in this class of errors and debugging, JSX is often more pleasant: due to compiling “from JS to JS”, ​​clicking on an error in the browser console usually leads exactly to where this error occurred in the code.
The infrastructure of Vue.js is still quite young. In fact, the stable components of the community can be counted on the fingers, many of which were built for Vue.js 1, and it is often not so easy for beginners to figure out which version of Vue.js the specific library is built for. This problem is leveled by the fact that you can do cool things in Vue.js without experiencing great need in third-party libraries. You will probably only need a library for Ajax requests ( vue-resource would be a good choice if you do not care about isomorphic applications, otherwise Axios ) and, probably, Vue-router, which is considered a library with good support from the authors of Vue.js.
Chinese comments are in the code of most public repositories, which is not surprising: Vue.js is becoming a very popular solution in China (by Vue.js speaks Chinese)
Rather, a potential problem than a real one, but sometimes you want to be safe. Evan You is the guy who built Vue after working at Google and Meteor. Laravel, of course, is also a single-guy project, but, nevertheless, he is still very successful, right?
Disclaimer: we do not plan to use Drupal 8 in Qwintry anytime soon, since we are switching to more modern, faster and simpler PHP and Node.js frameworks, but our legacy code is Drupal. Since qwintry.com’s main site is powered by Drupal, it was very important for us to check Vue.js in a fight right here. Honestly, I am not proud of many parts of our code in this repository, we try not to fit into some outstanding places at all, as long as it works at least somehow, but this old project with a history works reasonably and generates our income, so we respect it, We improve it, and many new features are released here. Here is a list of things that I built on Vue in Drupal: a form of quick entity editor, which includes the formation of invoices for customers, as well as the quick editing of product lists. It took you to build a simple JSON API to load and save entities - nothing special, just a few callbacks. Two cheap boards, through Saas REST API from products that we use for our support service, so that operators do not have to run through the admin areas of individual websites to verify information related to a specific customer. Now all this is built right into the client profile on our website. I know many backend developers are still stuck in 2010 and the Ajax kernel system is Drupal. I know well how complicated Drupal code can be when you try to build any complex multi-step form using the Ajax functional from the core - such code is almost impossible to maintain. Yes, I'm talking about you, ctools_wizard_multistep_form (), and you, ajax_render !
At the same time, these developers are pushing forward the demands on modern interfaces, but the complexity of the modern JS infrastructure drives them into depression. Yes, I recognize myself a year ago. In general, guys, listen to me! You will not find a better moment or way to improve your interfaces than to take Vue.js right now, put it in the sites / all / libraries, add it using drupal_add_js () to the template and start writing code. , , Drupal JSON, , , Vue.js.
: Yii Qiang Xue. , Yii + Vue.js , , ( ). Qwintry.com ( ) Yii2, , , PHP . , , , Laravel, PHP, Yii2 ( Laravel , , , , ). HTML, Yii2 PHP, REST API, JSON , Vue.js / Swift / Java. API-first Active Record . API API , API . , HTML PHP, webpack Yii2 , , , Vue single-file . PHP7 & MySQL Yii2 JSON Node.js ( 15-20ms), , , , , , 10-20 , , Drupal . ( , ) PHP . , Yii2 & Vue.js, , , , .
We also use Vue.js in a number of internal and external projects, where the backend works on Node.js - here I will not add anything new to the above, everything is working fine.
Vue.js 4 , . 4 – , JS , :) , . , Vue.js JS 16-24 , Evan You , , . React 2017 , React Native , .
UPD: HackerNews, (250+ ): news.ycombinator.com/item?id=13151317
Reddit WebDev , 60+ . Funny commentary opinion about Angular2 from there:
JSX , — ! — If, !
, , , , .
, If « » , . : github.com/AlexGilleran/jsx-control-statements
, , React Vue.js?
No! React – , , ( JSX, «» — , ), JS . JSX , , Vue.js, . JS . , , - , .
React - , jQuery Backbone, Vue.js , , .
, - , , ,
( , ) JS . , , Immutable.js , , , Lodash , , (, immutable lodash, ), – , , . , , Immutable.js, , SPA . ,
If you want to simplify your life, just stop mulling the state, go to props, and these simple things right now will improve your life.
- in legacy system running on Drupal (qwintry.com)
- in our new, completely rewritten qwintry.com branch (backend on Yii2 / Node.js)
- in our B2B systems (working on Yii2) (logistics.qwintry.com)
- in all our small internal and public projects (mainly using PHP and Node.js on the backend)
Why our programmers chose Vue.js, says the head of the development department of Qwintry LLC . Anton Sidashin âž”
Briefly about us: the Qwintry project is used by half a million customers around the world, we have two warehouses (in the US and in Germany) on our own cloud software, and we are one of the largest mail forwarding services in the US in terms of visitor traffic and shipments. We help people buy goods in US online stores and manage their packages in our personal account, and also allow us to save a lot on international delivery. We use our own IT platform and logistics chains to make high-quality international delivery at a good price.
Our package in the doors of the client - from customer reviews
')
Qwintry has a rather large code base, mainly consisting of PHP and JS (+ Swift and Java for mobile applications).
We decided to use Vue.js after we built a test application with identical functionality - our calculator - on React, Vue.js and Angular2.
React.js
The popularity of React has skyrocketed over the past year or two, and now, perhaps, this is the default choice for the JS developer who wants to write something more complicated on the front end of a three-line paragraph of code.
We ran several SPA and dynamic widgets on React, we tested React Native (for iOS) and Redux. I think React was a big step for the JS world in terms of state awareness , and it showed many people what real functional programming is in a good, pragmatic way. I also think that React Native is great - it literally changes the entire landscape of mobile development.
Disadvantages of React for me:
Often, purity, immobility and ideology dominate the pragmatic approach.
Do not misunderstand me. I appreciate the purity and simplicity of the render () approach — without a doubt, this is a great idea that works in actual development. I'm talking about other things.
I think that this level of rigor and purity can be useful when you have 1000 developers working in your company - at about the same time when you decide to develop your own syntax to translate all your PHP code into static types . Or when you are a Haskell developer who decided to comprehend JS. But most companies have far fewer developers, small budgets and goals that differ from those of Facebook. I will focus on this in more detail later.
Jsx sucks
Wait a second! I know! This is “just pure javascript with special syntax” . For our guys who paint design in sketch and photoshop and then convert it to HTML, which have tight deadlines and who are putting on this form right now, wrapping it in a number of divs - right now - perfectly clean and “clean” ES6. Applying a certain design to React components is not a fountain job, because JSX lacks readability. The inability to put the good old IF in some block of HTML code is bad, and please don’t believe React fans who say that “if () is the last century, and now all normal programmers use ternary operators.” Let me assure you: JSX is still a jumble of HTML and JS at the moment you read and edit it, even if it is then compiled into pure JS.
<ul> {items.map(item => <li key={item.id}>{item.name}</li> )} </ul> Many developers think (and for some time I agreed with them) that such syntax restrictions
stackoverflow.com/a/38231866/1132016
JSX also forces breaking components-into-15-lines-HTML into 3 components, 5-lines-HTML-into-each. Do not think that this approach makes you a better developer.
Here's the thing:
When you write a relatively complex component - which you are probably not going to post tomorrow's public rep on GitHub to demonstrate it on HackerNews - this approach of breaking components into super dumb components due to limitations JSX always pulls you out of the stream, which you solve a real business problem. No, I'm not saying that the idea of ​​fractional components is bad or does not work. You must be clearly aware that you need to divide the functionality into its parts in order to keep your code in a manageable state. But you should do this only when you think that this particular logical entity in your code is better to be a separate component with its own props - and not for every two or three conditions that were written using the ternary operator! Every time you create a new component here and there, it costs you a very specific effort and disrupts your flow , because you need to switch from the architect’s thinking (when you already remember the current state of the component model and you just need to add HTML here and there, for the functionality to work) on the manager's thinking: you need to create a separate file for the component, think about the props of this new component, how they map to the state, how you are going to forward callbacks, etc. As a result, the speed of writing code is reduced, because you have to spend effort on premature modularity of components where you probably would not need it, if the JSX syntax is more flexible. In my opinion, premature modularity is very similar to premature optimization. For me and our team, the readability of the code is important, but still enjoying the pleasure of writing code is also very important. This is not cool when the simple form of a calculator requires you to create 6 components, each with its own props.
Often, such hyper-modularity is bad from the point of view of maintenance, modification or application of a new design, because to update the html in the widget, you need to jump over several files / functions and check each small piece of HTML separately.
Again, I do not propose to write monoliths. I suggest using components instead of microcomponents for daily programming. Speech about balance and common sense.
Working with forms and Redux will make you type all day long
React - it's about cleanliness and one-way flow, remember? That's why LinkedStateMixin has become persona non grata , and now you have to write 10 functions to get input from 10 form fields. No, you can, of course, write one function that will check e.target, but ultimately there will be such a tree of conditions with normalization of the data arriving from the form that you want to cry; so no one does. 80% of these functions will contain a single line with this.setState () or the Redux action call. (Then you will probably have to create 10 more constants - one for each action). I think this approach would be acceptable if you could generate all this code just by thinking about it ... But I don’t know of any IDE editor who could greatly simplify writing such an interface. Why do you have to print so much? Because the big guys decided that two-way binding is dangerous in large enterprise applications. I can confirm that two-way binding is sometimes not so simple and not so readable, but most of these fears are associated with the general suffering of people from the first version of Angular, where the two-way binding was perhaps not the best. And yet ... this was probably not the biggest miscalculation even in Angular. Look at my fast editor, which I recently nestled with Vue.js for our platform on Drupal (I apologize in advance for the design, this is the UI backend for our operators, and the designers are busy creating interfaces for our clients, so this piece of functionality is waiting for its hours to become beautiful):
I can't show the code for obvious reasons, but writing it in Vue was very nice, and the code was very readable. And I know for sure that if I wrote a separate function for each field of the form, as in React, I would, of course, not jump from happiness.
Redux is also verbose and requires a lot of writing . And on the Internet, it is easy to find statements by developers who accuse Mobx of turning React into Angular only because Mobx uses two-way data binding (see clause 1 on “cleanliness”). It seems that many smart people appreciate the “purity” of their code, rather than a fast and well-solved business problem (which, in principle, is normal if you do not have deadlines).
At the same time, I think the very concept of Flux / Redux is very cool. Redux is simple and gives an incredible level of control over the state of the application, and separating the state from the purely interface pieces - this immediately simplifies the writing of tests. But, unfortunately, this is all given by a very large amount of writings. Yes, time-travel debugging as a side effect is awesome. But personally, I am ready to sacrifice them for speed writing code, and think about whether you need time-travel, if you need to come up with a constant for each field in the form.
Excessive toolkit
React works with the original Babel aim. You will not make a real React application without a decent heap of npm packages, starting with the ES5 compiler. A simple application based on the official starter build gets about 75 MB of JS code in node_modules. This is not a critical thing and relates more to the JS world as a whole than to React, but it still adds frustration and irritation.
My verdict on React - allows you to write excellent, readable code, but to write it a lot and sadly. Well, the problems for the designers who do not own, and who do not want to own ES6 inside HTML, do not disappear anywhere.
Angular 1: Too much freedom is bad too
Angular 1 is a good framework for its time, located in the opposite corner (from React) of an imaginary JS card of purity and readability of the code. Angular allows you to start quickly, allows you to enjoy writing the first 1 lines of code, and then it practically forces you to write code that does not work out very well . You are likely to get lost in the directives, scopes, and two-way data streams running through all layers of your application will be the final chord of the swan song of your code, which fresh developers do not even want to touch, because something will break. Why is this happening? Angular.js was created in 2009, when the world of front-end development looked quite simple and no one even thought about good state control over the application. Do not blame the authors - they just made a competitor Backbone with some new chips and wanted to print less (and they managed to do it all, another question is what price).
Angular2
Just build a hello-world application and look at the number of files that end up in a turnip. You'll have to use Typescript (and I'm not 100% sure that I want to do every day - no, guys, static typing in JS is not a panacea, but you have to print again, good thoughts from Eric Eliott on this topic ) and compilers to get going. This was enough for us to postpone Angular2 until better times. I'm lazy, and for me it's too much a boilerplate before you start writing real code. In my opinion, the authors of Angular 2 are trying to build an ideal system for an enterprise that will defeat React, rather than trying to build a framework that solves business problems for the average user. Maybe I'm wrong, and my opinion may change - I do not have much experience in Angular2, we just built a test calculator application, after all. The wonderful comparison page on Vue.js website calls Angular2 a good system, which with Vue.js combines a lot of ideas.
Vue.js
Vue.js is a thing I have been waiting for a long time (hereinafter I will talk about Vue.js 2, which received a lot of improvements compared to the first version of Vue, and this is the current stable version of the system). For me, in terms of elegance and conciseness, as well as focusing on solving real problems, Vue.js is the biggest breakthrough in JS since the day when Jquery hit me in 2007. If you look at the graphs of Vue.js popularity, notice that he pleased not only me this year:
On Github Vue - Top 1 JS project of 2016 (among repov with source codes).
The popularity in Google Trends Vue.js in 2016 sharply bypassed React (of course, this is the average temperature at a very large hospital, and depends heavily on the formulation of the request - a very indirect sign of popularity).
https://www.google.com/trends/explore?q=vue.js,react.js,angular.js
Vue.js is one of the fastest growing (in terms of community or at least the number of likes in githubs and Vue Dev Tools users in the chrome store) JS solutions in 2016, and I’m sure that this is not just another fashionable a library for hipsters who switch to a new JS framework every 3 months, or the work of a large company’s PR department.
Laravel added Vue.js to the core, and this is a serious claim.
Pros Vue.js
Vue.js maintains an excellent balance between readability, maintainability of the code and pleasure from its, this code, writing. This balance is at a roughly equidistant distance between React and Angular 1, and if you look at the vue.js guideline, you will immediately notice how many useful ideas he borrowed from these systems.
From React, Vue.js took a component approach, props, one-way data flow for the component hierarchy, performance, the ability to render on the backend, and an understanding of the importance of proper state management. From Angular1, Vue.js took similar templates with good syntax and two-way binding, but only where you really need it and will not allow you to shoot yourself a leg right away (inside one component). Starting to write code under Vue.js is very easy - I saw it in our team. Vue.js does not require any default compilers, so it is very easy to add Vue.js to your legacy codebase and start rewriting jQuery hash to readable code.
Correct amount of magic
Vue.js is very simple in work, both in terms of the HTML-centric approach and in terms of JS developers: you can make quite complex templates without losing focus on a business problem, and the resulting HTML template is usually well read even when he is already big. By this time, as a rule, you have made good progress in solving a business problem and you may want to reorganize the templates and divide them into smaller components - at this moment you see the whole “picture” of your application much better than at the very beginning. My experience shows that this is significantly different from the approach that programmers typically use in React, and this difference saves a lot of time and effort for programmers using Vue.js. In React, you are forced to break components into microcomponents and microfunctions right at the time of writing the initial, “draft” version of the code, otherwise you will be literally buried in a jumble of curly braces and html between them. In React, I spend a lot of time polishing props and refactoring super small components (which, of course, will never be reused) over and over again, because I don’t see so clearly when I suddenly need to change the code logic in the middle of the process.
Forms
Working with HTML forms in Vue.js is a pleasure. This is where biparting actually helps out. Even in difficult cases, there are no problems, although at first glance watchers may remind Angular 1. One-way data flow is always at your service when you split up components.
Technology
If you want to compile, linting, PostCSS and ES6 is not a problem . Single-file components seem to be becoming the main way of writing public components in Vue.js 2. By the way, the idea of ​​Scoped CSS working in single-file components out of the box is something that looks really nice and can reduce the need for strict CSS naming rules classes and technologies like BEM .
State management
Vue.js has quite simple and useful state management through data () and props () methods - they work fine in real development. If the soul asks for something more for state management, there is Vuex (which, in my opinion, is similar to Mobx in React - the state is mutable). I think a good percentage of Vue.js applications will not require state management via Vuex, but it is nice to have an alternative.
Performance
The holivar theme, in general, and react, and vue.js - work quickly. But nevertheless, apparently, vue.js is on average noticeably faster.
A wonderful link from the comments on the TodoMVC run with measurements:
eigenmethod.imtqy.com/mol/app/bench/#bench=%2Ftodomvc%2Fbenchmark%2F#sample=angular2~angularjs~mol~react~vue~vanillajs#sort=fill#
And here are more detailed layouts (from the interested party, really) .
Another, detailed and intelligible benchmark comparison:
stefankrause.net/js-frameworks-benchmark4/webdriver-ts/table.html
Cons VueJS
Runtime errors in templates
The biggest: unpleasant execution time errors in templates. Sacrifice for the sake of convenience of writing code. This is very similar to Angular 1. Vue.js manages to issue many useful warnings for JS code: for example, there are warnings when you try to mutate props or incorrectly use the data () method, the positive effect of React is very noticeable here. But runtime errors in templates are still a weak point. Vue.js. Exception stack sets are often useless and lead to the internal methods of Vue.js. In this case, in this class of errors and debugging, JSX is often more pleasant: due to compiling “from JS to JS”, ​​clicking on an error in the browser console usually leads exactly to where this error occurred in the code.
Libraries
The infrastructure of Vue.js is still quite young. In fact, the stable components of the community can be counted on the fingers, many of which were built for Vue.js 1, and it is often not so easy for beginners to figure out which version of Vue.js the specific library is built for. This problem is leveled by the fact that you can do cool things in Vue.js without experiencing great need in third-party libraries. You will probably only need a library for Ajax requests ( vue-resource would be a good choice if you do not care about isomorphic applications, otherwise Axios ) and, probably, Vue-router, which is considered a library with good support from the authors of Vue.js.
Non-english speaking community
Chinese comments are in the code of most public repositories, which is not surprising: Vue.js is becoming a very popular solution in China (by Vue.js speaks Chinese)
The project is one person.
Rather, a potential problem than a real one, but sometimes you want to be safe. Evan You is the guy who built Vue after working at Google and Meteor. Laravel, of course, is also a single-guy project, but, nevertheless, he is still very successful, right?
Vue.js in Drupal
Disclaimer: we do not plan to use Drupal 8 in Qwintry anytime soon, since we are switching to more modern, faster and simpler PHP and Node.js frameworks, but our legacy code is Drupal. Since qwintry.com’s main site is powered by Drupal, it was very important for us to check Vue.js in a fight right here. Honestly, I am not proud of many parts of our code in this repository, we try not to fit into some outstanding places at all, as long as it works at least somehow, but this old project with a history works reasonably and generates our income, so we respect it, We improve it, and many new features are released here. Here is a list of things that I built on Vue in Drupal: a form of quick entity editor, which includes the formation of invoices for customers, as well as the quick editing of product lists. It took you to build a simple JSON API to load and save entities - nothing special, just a few callbacks. Two cheap boards, through Saas REST API from products that we use for our support service, so that operators do not have to run through the admin areas of individual websites to verify information related to a specific customer. Now all this is built right into the client profile on our website. I know many backend developers are still stuck in 2010 and the Ajax kernel system is Drupal. I know well how complicated Drupal code can be when you try to build any complex multi-step form using the Ajax functional from the core - such code is almost impossible to maintain. Yes, I'm talking about you, ctools_wizard_multistep_form (), and you, ajax_render !
At the same time, these developers are pushing forward the demands on modern interfaces, but the complexity of the modern JS infrastructure drives them into depression. Yes, I recognize myself a year ago. In general, guys, listen to me! You will not find a better moment or way to improve your interfaces than to take Vue.js right now, put it in the sites / all / libraries, add it using drupal_add_js () to the template and start writing code. , , Drupal JSON, , , Vue.js.
Vue.js Yii2
: Yii Qiang Xue. , Yii + Vue.js , , ( ). Qwintry.com ( ) Yii2, , , PHP . , , , Laravel, PHP, Yii2 ( Laravel , , , , ). HTML, Yii2 PHP, REST API, JSON , Vue.js / Swift / Java. API-first Active Record . API API , API . , HTML PHP, webpack Yii2 , , , Vue single-file . PHP7 & MySQL Yii2 JSON Node.js ( 15-20ms), , , , , , 10-20 , , Drupal . ( , ) PHP . , Yii2 & Vue.js, , , , .
We also use Vue.js in a number of internal and external projects, where the backend works on Node.js - here I will not add anything new to the above, everything is working fine.
Conclusion
Vue.js 4 , . 4 – , JS , :) , . , Vue.js JS 16-24 , Evan You , , . React 2017 , React Native , .
UPD: HackerNews, (250+ ): news.ycombinator.com/item?id=13151317
Reddit WebDev , 60+ . Funny commentary opinion about Angular2 from there:
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 you get a stateless reference prototype of the type of service provider. You will then be ready to compile your Angular kernel, be careful to use the Webpack 2.3.9 (note: not 2.3.8 as supplied with the repository). It is a great Angular project. Angular: making development and fun again! ”
Questions from readers:
JSX , — ! — If, !
, , , , .
, If « » , . : github.com/AlexGilleran/jsx-control-statements
, , React Vue.js?
No! React – , , ( JSX, «» — , ), JS . JSX , , Vue.js, . JS . , , - , .
React - , jQuery Backbone, Vue.js , , .
, - , , ,
( , ) JS . , , Immutable.js , , , Lodash , , (, immutable lodash, ), – , , . , , Immutable.js, , SPA . ,
If you want to simplify your life, just stop mulling the state, go to props, and these simple things right now will improve your life.
Source: https://habr.com/ru/post/400227/
All Articles