Why is Vue.js Considered the Best Framework for Front-End Development for 2017?

Why is Vue.js considered the best framework for front-end development for 2017?

The web industry took more than half a decade to come from monster frameworks to a simple and elegant design. In IT, simplicity is not only saved hours of work, but also a transparent architecture, resulting in clear code, fewer bugs, faster changes and many other pleasant things.

In this article, We going to compare Vue.js with the two most popular frameworks at the moment:

Vue.js is much younger, so the conversation will be primarily about him, the competent developers know about Angular and React. I would not have started this conversation if Vue had not offered something really worthwhile. Fortunately, this is so, and I argue that in most cases Vue.js can seriously reduce the complexity of your programs, make the code more concise and expressive, and debugging is shorter and easier.

If very briefly, then Vue.js is an unbelievably unobtrusive framework. If Angular and React force you to install a whole zoo of dependencies, then Vue in the minimal configuration does not ask for anything from you except your own js-file. For this, he gives

  • Custom controls
  • Data binding
  • Custom directives
  • In fact, all the claimed chips of the main frameworks.

What does the simplest program on Vue look like?

Simply connect the library, create a container and invoke the constructor, all as in the good old Angular 1:

[sourcecode language=”js”]
<div id="app">{{ message }}</div>

<script src="https://unpkg.com/vue"></script>
<script>
new Vue({
el: ‘#app’,
data: {
message: ‘Hello Vue!’
}
})
</script>
[/sourcecode]

It’s all the code you need, it’s not a joke. You can right now copy it to the editor, save it as something.html and it will work. Without dances with a tambourine, dependency hell and other modern artifacts. We are not going to tell you how the same thing is done in React or Angular 2+. About how to pull JSX out of React or how to write without TypeScript on Angular 2+, you can write an entire article.

  1. Why not leave it at that?
  2. What’s wrong with TypeScript?

From 2005, we fought for every kilobyte of the weight of the page, and now the sites weigh 15 megabytes each and, as it were, it’s necessary, but this is disrespect to the user. I’m not saying that TypeScript, or JSX, or thousand other side technologies are to blame, but I want to choose what to use and what not. And so you do not have to pay for this choice for hours on StackOverflow.

Concerning concatenation and code minification, for Vue, there are many solutions with ready assemblers on the same yeomen (for example Github), as well as for React or Angular. The difference is that you have the right to choose, use them, do not use them, or create the collector yourself for the particular project.

Custom Controls

A common scenario for the development of most web applications is to increase the density of functionality:

  • You had a normal button, but a button with a status indicator
  • Was a normal table, and became a table with sorting and filters
  • Was the usual menu, and became a menu with multiple nesting

If such components are found in the application once – nothing terrible, but more often it happens that they are scattered across different pages and in large numbers. Without custom control, such tasks are solved through pain, torment and a lot of time, with custom controls this is done faster several times. If you did not encounter such a problem, then you did not have any more or less serious projects.

Custom controls are absolute must have in modern front end programming. In Angular 1, there were no customs controls (except for directives, which were originally intended for other things). In Angular 2+ and React they are, but they get quite expensive. The syntax of Vue.js is very similar to Angular 2+ but without its limitations. Modify the code slightly above:

[sourcecode language=”html”]
<div id="app">
<ol>
<todo-item v-for="item in list" :todo="item"></todo-item>
</ol>
</div>

<script src="https://unpkg.com/vue"></script>
<script>
Vue.component(‘todo-item’, {
props: [‘todo’],
template: ‘<li>{{ todo.text }}</li>’
});

new Vue({
el: ‘#app’,
data: {
list: [‘first item’, ‘second item’]
}
});
</script>
[/sourcecode]

It turned out slightly more authentic, but we have custom controls here. Custom controls in 20 lines of code. In this case, the component itself took only 4 lines. What this means in practice: that you can divide your code into components as small as you want, with minimal costs.

If in React the creation of a separate component is a whole story, in the outset, the culmination and the denouement, then in Vue it’s just a few seconds. And it’s not in these seconds, but that with more components you will have weaker dependencies and fewer bugs.

This is a synthetic example of a component, but in real Vue.js reveals itself even better. We can, for example:

  • Render all the component code in a separate * .vue file, including HTML, CSS, and javascript
  • Use CSS pre processors right in the code of the component file, simply specifying lang = “scss” or other
  • Use any global objects or get objects via import (in React, it seems, there are limitations)
  • Use components only within other defined components, without declaring it in the global scope. Use the component under a different name, without changing the component itself (it is convenient in case of collision of names of third-party components)

For most of these functions, you need to connect the collector (the documentation describes the web pack), but you are given the choice to use Vue for 10%, 50% or 100%. Plus, in my opinion, they have chosen the most stable and transparent assembler of the existing, but you can change it. In general, Vue impresses with its modularity and looseness, the architecture is simply very well thought out, which turns out to be a great pleasure when working with any of its components. For example:

Creating your own plugins

Before opening the spoiler with the code, stop for a minute and think about how you would patch an unfamiliar library if you wanted to add a new custom method there.

Have you thought about it?

Now open the answer:

[sourcecode language=”js”]
Vue.prototype.$myMethod = function (methodOptions) {
// something logic …
}
[/sourcecode]

How to do this in Vue.js

Vue.prototype, You do not even need to know the documentation, you already know most of it at the sub cortex level. No more strange configs, magic properties that need to be specified to make everything work. Just Vue.prototype and the name of your method, why do not all frameworks use it? If you want to install the plug-in via Vue.use (MyPlugin), you need to define the MyPlugin.install method, but this, like much in Vue, is at your request.

The general situation

  • We have big claims to the Angular team. I’m not afraid to say that they actually killed Angular, creating two completely different products and calling them by the same name. Even Vue has more in common with Angular and 1 and 2 than with these versions of themselves. There was a huge confusion in the documentation, which will not stop soon. But it’s not even that, as one of the canonical principles for creating good software says: make the programs open for the add-on and closed for modification. Such radical changes in the API Angular indicate that the product was originally created as a problem, ideal programs do not need any changes (for example/bin/true in Linux did not correspond with 1984. Of course Angular is not/bin/true, but the reforms are always a sign of problems.

What is the reason?

  • We think that both React is a project for internal Facebook needs, and Angular 2+ is a project for Google’s internal needs.
  • A particular company does not need to maintain versatility.
  1. Why support ES6, if the company itself is written to TypeScript?
  2. Why separate React from dependencies if it is not used internally without dependencies?

Of course, users ask, and sometimes they go to a meeting, so they do not turn away at all, but the main task of these projects is not our happiness, but easier hiring in these companies when a newcomer comes and already knows the main stack of technologies. But the stock of a particular company, even if very steep, can not be a standard for the entire industry. Hence all the problems with Agular and React. Vue, as far as I know, on the contrary, was created specifically for the community, so it turned out to be modular, universal, easily adaptable to the required tasks.