Recently the Qwintry team has actively adopted vue.js as their front-end framework and is using it in all new and old projects, including:
Qwintry.com Drupal system in the past (qwintry.com)
Our new project completely rewrites the qwintry.com branch
A B2B system built with Yii2 (logistics.qwintry.com)
All of our small projects and external outreach projects (mostly PHP and Node behind the scenes)
Qwintry is used by about 50 million people worldwide. We run two warehouses (one in the US and one in Germany) with our software. We are one of the largest mail agents in the United States, and our users and shipping lanes are concentrated in Eastern Europe and the Middle East. In fact, our main purpose is to help people save some shipping costs and make it easier for them to buy American goods online. And we use our information and logistics systems to help people find the best value for money.
This is our package in front of the customer.
We have a huge code base, basically built in PHP and JS.
After building our “user calculator” with modern frameworks like React, Vue.js, and Angular 2, we decided to use vue.js.
My view on React
While we’re talking about choosing a front-end framework, React’s proliferation in the JS world is such that it’s now probably the default choice for JS developers.
I developed some SPA applications with React and some dynamic components. I also played RN + Redux on IOS. I think React has a great starting point for JS in the form of a state machine, which shows people the benefits of functional programming. I think RN’s ambition is huge, and it’s changing the world of native development.
Personal opinion on the downside of React
A pure, unchanging, stable mechanism to control the state
Don’t get me wrong, I’m a big fan of using pure functions and simple render to control the state, and there’s no doubt that this is a good form to take in the life cycle of a real environment. I’m going to talk about some other points.
I think when you have more than 1,000 developers on your team, this kind of clean, strict model is probably necessary. But this is only necessary if you want to add your own syntax to your static specification code, or if you are a Haskell developer who has moved to JS. But most development teams tend to be much smaller than Facebook’s.
Disgusting JSX
I know, I know, it’s just a special JS syntax. Our designers and front-end guys could have just focused on elements for each line of HTML, but now they’re writing code like they’re eating shi. It would be disgusting for designers to write React components using JSX because JSX is so poorly readable. You can’t write simple judgment statements in HTML blocks. Don’t believe the React fans who tell you that you don’t need to write this, you only need to write ternary. I guarantee you’ll still have to read and write a bunch of HTML and JS hybrids during actual development, even if they’re later compiled into pure JS.
{items.map(item =>
{item.name}
)}
Copy the codeA large number of developers (including me) once all thought it was a grammar by certain restrictions, this will help you write the code more modular, because you have to put you many auxiliary method in your render function, like this guy’s advice: stackoverflow.com/a/38231866/…
Because of the WAY JSX is written, you have to split 15 lines of HTML into three components (5 lines of HTML for each component).
Don’t think this is a good way to be a good developer, because you just have to code like this.
Here are some scenarios:
When you’re writing a complex component (one that you might not publish on Your Github), you might want to break it up and assemble it into a larger, more complete component to accomplish your actual business goals, because the JSX data specification might let your data flow out. But I don’t mean to say that widgets are bad or inefficient.
You should be aware that you are separating your code into components to keep it readable and reusable. But you should also know that componentizing your code is because each component has its own logical entity, and separated components have their own internal attributes (and triadic expressions are recommended if there are only two or three IFs). Every time you create a new component that consumes some memory and a bit of data flow (probably more), because you need to complete module from business idea (when you are sure that you have to remember the current state of the components, and you only need to add an HTML can run the current component) to switch to the thinking of management business components (management). Then you can detach components, start thinking about the properties of the new component, how the new component fits into state, how to design callback functions, and so on.
In fact, it can slow down your coding because you force components to be too modular or too small in an unnecessary place. In my opinion, deciding on modular solutions in advance is the equivalent of deciding on best practices in advance.
For me and my team, code readability is Paramount, but so is code fun. If you want your calculator plug-in to work with six components, it’s not fun to code that way. And in many cases, maintenance, extension, or visual testing of some plug-in code involves jumping around in several files or functions and checking that each separate HTML package works correctly. Again, I’m not in favor of writing a giant component, I’m in favor of replacing the day-to-day development of microcomponents with components. This is more common sense.
Coding with forms and Redux will keep you sorting all day long
React is based on a pure, one-way data flow framework, remember? This is why the LinkedStateMixin two-way binding has become popular. Now, you have to create 10 functions to get 10 input values. 80% of these functions will include a function call to this.setstate (), or if it’s an action callback to Redux (in which case you’ll have to create another 10 constants to match the 10 inputs). I guess you’d like to be able to automatically generate these associations by imagination, but I’m not aware of any IDE that offers such a plug-in.
Why do we have to categorize so much? Because two-way binding is considered dangerous by some big business bosses. I admit that coding with bidirectional bound streams can be less readable, but most of these concerns are due to the negative impact of Angular 1 bidirectional binding, and it’s probably not the biggest concern about bidirectional binding.
Now let me show you a quick editor component that I recently built for our Drupal site using vue.js.
It’s easy to see why I didn’t post my source code, but the process of coding in Vue is fun and the code is very readable.
Now, I’m pretty sure that if I had to use React to do what I did above, I’d have to create a separate function for each input to control a widget, and I wouldn’t be happy doing that.
Redux sounds like a synonym for redundancy, and it’s now easy to find developers whose job it is to transform React into Angular. This was done only because you wanted the data to be bidirectionally bound. My first point is “1 on purity”. It seems like a lot of smart people make their codebase more valuable than their work (which must be nice when you don’t have deadlines, I guess).
Too much dependence
React needs to be compiled by Babel, and your React project wouldn’t get anywhere without a bunch of NPM packages, so use ES5 first. The simplest application development will also require some official React dependencies, which are in node_modules and are about 75MB in size.
This is not a criticism, these dependencies are more due to JS than React. But all of these factors add up to make React development tiring.
Angular 1: Too much freedom is bad
Ng1 used to be a great framework as well. It was the opposite of React. Its code was much more readable and it allowed you to get started quickly. You’re likely to get lost in the mass of instructions, scopes, and two-way data streams that run through all of your applications and are difficult to maintain. It’s hard to maintain, so it’s a no-no for your new developers to maintain the old system.
Why is that?
When NG1 was created in 2009, the front-end applications were so simple that no one thought there would be so many state management issues. You shouldn’t blame them, they just want to get ahead of Backbone with new ideas and write less code.
Angular 2
To build a Hello World application and find the entry files for your project, you need to use Typescript and compile them to start working. It’s really just a few specifications that I do before I actually get to work. In my opinion, the developers of NG2 tried to build a more elegant framework to beat React, rather than trying to build a framework that would solve most user problems. Maybe I’m wrong, and I don’t have much experience with the NG2, because we just built a user calculator system for our warehouse to test its framework performance. There is a good article comparing other frameworks, ng2 is a great framework, and there are a lot of comparisons with Vue in this article.
Vue.js
In short, vue.js is the framework I’ve been waiting for (I’ll talk about Vue2, which is a much improved framework over the first version and has recently been released in a stable version). For me, the elegance and simplicity of Vue allows me to focus more on business code. Vue is another framework that has changed the JS world since jQuery in 2007.
If you look at the popularity of Vue, I’m not the only one who’s bullish on Vue: www.timqian.com/star-histor…
Vue.js can become one of the js architectures with rapid development in 2016. I think its development not only depends on the support of fans, but also due to the academic support and affirmation of some authoritative organizations.
Laravel has also added vue.js to its core ideas, which is something to note.
The characteristics of the Vue. Js
Vue.js is a knockout for code readability, maintainability, and fun. If you look at the documentation for Vue, you’ll immediately see that this framework provides a much better programming experience than React and Angular 1.
React, in contrast, is a component-based framework, with each component instance having its own methods, properties, one-way data flow down the component hierarchy, function calls, virtual DOM, and state management.
Angular 1 is more like a template with good syntax and two-way data binding (within a single component) that you will definitely need.
Vue.js is an easy framework to get started with, and this has been proven by our team. It doesn’t have to be forced to build in any environment, so it’s easy to combine with your legacy code, and you can immediately use Vue code to improve your legacy code in jQuery.
Get the right results quickly
Vue.js is an easy framework to use, whether in HTML or IN JS. It allows you to focus on your business while working on a complex template. And even if the template is very large, it can be very readable. At this point, you can more easily process your code logic according to your business logic. If you want to refactor templates and break them up into smaller components, you can also see more clearly the relationship between the entire application from the large template you started with.
In my experience, this development mode is very different from when I was developing with React: IT saves me a lot of time. With React, you had to split your components into smaller pieces the first time you coded them, or you could just delete your original code. In React, when you are halfway through programming and have to change your data flow due to application logic changes, you will probably spend a lot of time modifying your properties and states again and again because you can’t see the entire data flow clearly. And you’ll have to refactor your super small components over and over again (widgets that may never be used later).
Manipulating forms in vue.js is also a breeze. Two-way bound data flow is one of the highlights of Vue. Even in complex scenarios, watcher does not pose any problems, although it may be reminiscent of Angular 1 at first sight. When you split your component, you can always one-way transfer the data that needs to be changed through callbacks.
If you want to use some pre-processing tools such as PostCSS and ES6, you can click here. In Vue2, writing a common component has become the default way to extend Vue. Incidentally, writing CSS inside a component is a seemingly great experience that reduces the hierarchical naming problems of traditional CSS, as BEM does.
Vue.js has simple and efficient state management mechanisms, such as data() and props(), which can be used in real scenarios. Vuex is a state management tool similar to Mobx in React, which separates state operation from state management.
Some problems with VueJS
The biggest problem is that there is no warning about template errors in the runtime. This is much like Angular 1. Vue.js provides a lot of useful warnings during your development, such as when you incorrectly modified props or incorrectly defined data(). However, errors in template execution are a weakness of Vue, especially as multiple stack processing is not helpful, due to Vue’s internal methods.
Vue.js 2 is still very new, it does not have a stable component community, and many existing components are built on vue.js 1. And for starters, it can be hard to tell which version of Vue the library uses from github’s component repository. In fact, this problem is easy to solve, because you can complete a complex Vue project almost without using any additional libraries. You’ll probably just need a library for Ajax requests. Vue-resource is a good choice if you don’t care about homogeneous applications, otherwise opt for Axios. Vue-router is also a frequently used library, a great library for providing routing.
3. Chinese documents are also available in many communities, which is normal, as vue.js is also popular in China (the author can also speak Chinese).
4. Did one person write a project? This isn’t really a problem, but some people care. You Xiaoright, a man who worked at Google and Meteor, created Vue. Laravel used to be a one-man project, but now it’s a huge success, so you never know how powerful a one-man project is.
Develop Drupal with vue.js
Disclaimer: We have no plans to use Drupal 8 in Qwintry anytime soon, and our legacy code will still use Drupal 7 when we switch to the faster and more convenient PHP and NODE frameworks.
Since we were building our history system with Drupal 7 (qwintry.com), it was important for us to test the new framework. I’m not at all proud of our redundant historical code, but it’s working steadily and making money for us. So we maintain it, improve it, and add functionality to it. Here’s a list of some of the features I’ve already built with Vue + Drupal:
A system designed for complex order business. This includes generating orders for users and quick editing of purchase items. This includes loading some basic JSON data at load time and saving some data nodes. There’s nothing special about it, just some simple data callbacks.
Two sets of REST systems. Our users don’t have to re-log in to different sites, and we do quick identity checks for special users. These operations are based on our user management system.
I know that many backend developers are still stuck in 2010, and that the Ajax request system is at the heart of Drupal 7.
I can imagine the complexity of trying to refactor core functionality with multi-step Ajax requests. And then it’s even harder to maintain that code. Yes, this is the ctools_wizard_multistep_form() function in Drupal, and you can see how it works with Ajax.
Also, these Drupal developers are busy learning about popular UI frameworks, but they may be afraid to learn about popular JS frameworks. I did the same thing a year ago. Now let me tell you, you’d be hard pressed to find a better way to improve your interface, but with vue.js it’s a different story. You can add your request address to the template according to drupal_add_js and then go relax. You’d be surprised how easy it is for the client to get pure JSON in the callback of the hook you set up, and the same for the form, thanks to Vue.
Use vue.js with Yii2
An interesting thing, Yii is also made by a Chinese boy — Xue Qiang. So you might find it not too hard to pronounce a stack like Yii + Vue because it’s also a Chinese creation 🙂
For our new version of the site Qwintry.com (not yet available), we chose to use Yii2, which I believe is one of the best and fastest PHP frameworks out there. It’s not as popular as Laravel, which has taken the PHP world by storm right now, but we’re still having fun with Yii2 development (though we do check in on Laravel from time to time, as the framework is still pretty good).
We are gradually reducing the use of Yii2 to generate HTML templates and focusing on REST behind the scenes to generate JSON for our vUe-built clients to use. Our dynamic recording model almost always determines the API first and then constructs the data.
As a result, we have a well-regulated interface design, which is why we spend a lot of time building our interface documentation, even if it’s for internal use.
Our back end was developed using PHP7 and the latest MySQL, and the response time of returning data using Yii2 is no different from that of returning data using Node (I’m talking about 15-20ms). So Yii2 meets our requirements. We can imagine people using our Drupal project 10-20 times faster than they used to. It also supports all older VERSIONS of PHP libraries, making it easy for us to maintain our code base manually.
So, Yii2 + Vue.js can be very useful and make your job a lot more enjoyable.
We also use vue.js on many of our other projects.
conclusion
We’ve been writing vue.js in various projects every day for the past three months, and it’s helped us a lot. You don’t have to write back-end code for three months, but it’s all JS. Let’s see the world 🙂
I expect Vue to become an irreplaceable JS framework in the next 16-24 months. If Righty can get the framework moving in the right direction, Vue could become at least a core framework for some front – and back-end teams. I think React will continue to be the dominant framework in the JS world even in 2017, especially if RN manages itself better and continues to improve at its usual pace.
Original address:Why we chose Vue.js over React
Did this article help you? Welcome to join the front End learning Group wechat group:
