What problem does the front end framework exist to solve? Among these frameworks, what makes Vue so attractive? Why is the core idea behind it progressive? How popular is Vue? What improvements have been made to the recently released Vue2.0? Vue and Weex is what kind of cooperation?

On October 20, 2016, Yuxi You, founder of Vue Technology LLC and author of vue.js, gave a speech titled “Vue 2.0 — Progressive Front-end Solution” at QCon Shanghai, in which he explained the above problems one by one.

First, why a framework

1. Frameworks exist to help us deal with complexity

There are a lot of front-end frameworks, so why have frameworks? My personal view is that frameworks exist to help us deal with complexity. When we need to solve front-end engineering problems, these problems have different complexity. If you tackle very complex requirements with tools that are too crude, it can have a huge impact on your productivity. So, the framework itself helps us abstract away some repetitive, proven patterns into an API package that you’ve designed to help you deal with these complex problems.

2. The framework itself has itThe complexity of the

However, frameworks introduce their own complexity. I’m sure you’ll encounter a learning curve when researching or learning frameworks — some of them can be hard to get started with.

So this is the abstraction of a problemThe complexity of the application being done versus the complexity of the framework being used.

Further, the inherent complexity of the problem being solved is compared to the complexity of the tools being used.

Review images

3. Tool complexity is an investment in dealing with inherent complexity

Tool complexity can be understood as an investment in dealing with the inherent complexity of the problem. Why is it called investment? That’s because if you invest too little, you don’t get scale, you don’t get a reasonable return. It’s like when a startup takes venture capital, how much is important. If the problem you’re trying to solve is complex, and you tackle it with a tool that’s too crude, you run into a problem where the tool is too weak to be productive.

Review images

Is on the contrary, if want to solve the problem is not complicated, but you use very complex framework, then it is equivalent to kill on the wheel, will encounter tool complexity caused by side effects, not only will lose the advantage brought by the tool itself, also increases the various problems, such as training costs, loop, and the actual development efficiency, etc.

Review images

4. Pick the right tool for the job

“Pick the right tool for the job” — this is a common phrase when discussing framework selection with developers abroad — it all depends on the scenario. Because front-end development is unique in its own way compared to native or desktop development, it’s not really that fixed. On the Web, applications can have many forms, and different forms of Web applications may have completely different levels of complexity. That’s why I’m talking about the complexity of the tools and the complexity of the applications you have to do.

5. What about the complexity of front-end frameworks

Front-end development has become more and more engineering, and the actual problems we need to solve are different. Let’s analyze the following figure.

Review images

We may need declarative rendering in any case and want to avoid manual, or variable imperative, manipulation as much as possible. We want to make updates to the DOM as automatic as possible, updating it to the correct state as the state changes; We need component systems that break up a large interface into smaller, controllable units; Client routing – this is for single-page applications, do not do not need, if you need to do single-page applications, then there needs to be a URL corresponding to the state of an application, there needs to be a routing solution; Large-scale state management – when the application is simple, may be a very basic state and interface mapping can solve the problem, but when the application becomes large, involving collaboration, will involve the Shared among multiple components, multiple components need to change the same state, and how to apply this scale can still run efficiently, There’s the issue of large-scale state management, and of course maintainability, and build tools. Now, if you look ahead to the future, when HTTP2 becomes ubiquitous, it could lead to a revolution in building tools. But for now, especially in China’s online environment, packaging and engineering remains a very important and inevitable part of the process.

Second, mainstream framework analysis

Let’s take a look at some of the problems that existing mainstream frameworks solve from less to more. This is not a measure of how good the framework is, but how much it covers from a design perspective.

Review images

  • Pure template engines: At the very least, pure template engines focus on state-to-interface mapping.

  • React and Vue: Both are very focused on state-to-interface mapping and components.

  • Backbone: It gives you architectural guidance, like layering.

  • Angular: It does more. It has its own routes, which are included.

  • Ember: Even more radical than Angular, Ember believes in convention over configuration. It designs everything for you and packs it up for you to use right out of the box.

  • Meteor: Meteor is just an extreme, it’s all front to back, from the front end to the data layer to the database, it’s all packaged for you.

Through simple analysis, we can feel that the framework that does less is not necessarily inferior to the framework that does more, which reflects a trade-off. That is, frameworks that do less can give you more flexibility, but you need to make more choices; Frameworks that do more are more intrusive, more costly to learn, and less flexible. Once you choose an intrusive framework, you don’t have a chance to switch to something else you’d rather use.

So, the React and Vue have a common characteristic, they all have their own form a complete set of tools, core while only a small problem, but they have the optional tool, form a complete set of ecosystem and when you add them one by one, can be combined into a very powerful stack, you can cover other issues covered by these more complete framework.

Review images

Such a configuration allows you to build a technology stack with flexible tool complexity: when the inherent complexity of the problem to be solved is low, you can only use these very simple functions at the core; When you need to do a more complex application, add tools. For example, when making a single page application, routing is needed; Large-scale state management solutions may be needed for a large application that involves multi-component state sharing and multiple developers working together.

There is a huge difference between a purely complex single-page application and the engineering stack you need to choose to embed interactive content on a static page rendered at the back end. This is why I feel that the core + ecological stack will be a more flexible stack in overall selection.

Review images

React and Vue both choose this mode. The Facebook team focused on React itself, but the React community was very active and contributed a number of third-party solutions. Undeniably, the React community is the most active community at present. Many excellent ideas and ideas, including state management schemes, were first sprouted from the React community. But the side effect of this active community is that times change so fast, a new version comes out in three days, and there are dozens of different solutions to the same problem. As a result, we have to spend a lot of time identifying the selected components when building our own stack. At the same time, because the libraries of the entire ecosystem are not planned and designed by a unified team, it is difficult to consider the collaboration between different libraries, which leads to running-in problems.

Review images

At the same time, many developers complain that there is “JavaScript Fatigue” in the JS ecosystem, saying that there is too much stuff in it, and that they feel tired of constantly learning the latest things to keep up. Of course, there are many people who think this is a manifestation of the prosperity of the ecosystem, but it does make everyone face the problem of choice disorder.

Review images

Dan Abramov, a very active developer in the React community, has joined the React team. He tweeted the other day that the extreme modularity made it very difficult for him to build a unified experience. This refers to the fact that each part of the Stack in the React ecosystem comes from a different developer, and there are a lot of loose ends when trying to integrate it all together. This is what he said when he first started the official CLI of React. He was trying to integrate all kinds of things in the community into one shelf, so he encountered many such problems. I don’t mean to deny that the React ecosystem is thriving at all, I just think there is an alternative, which is to do an incremental framework, which is where Vue is going. Review images

Third, the progressive framework vue.js
1. Vue. Js

The following data can reflect the current situation of vue.js.

Review images

  • A while ago it hit 30,000 stars (see below), with over a million downloads.

Review images

  • The number of users on the official website is 260,000 per month, which should not include the data in China. The official developer plugin has around 55,000 weekly active users. This is the number THAT I find most compelling. Vue users who install and use developer plug-ins should actually use Vue frequently in real production.

The data for Google search trends are shown below. In the figure, data of Backbone is in green, Ember is in yellow, React is in red, and Vue is in blue. It can be seen that React and Vue have developed rapidly in the past two years. It can be seen that the curve of Vue started early in 2013, but the growth was relatively low for a long period of time. Since I was still working at Google during that time, Vue was basically run as a personal project. In the last year or two, Vue has had a tremendous breakthrough. Angular is not included in this diagram, because Angular is still too large to be included in the chart.

Review images

These numbers are not an absolute representation of the current heat of the framework, but they are useful. You can see React has a lot of momentum. Vue’s curve also shows that its growth rate is still rising.

2. Positioning of Vue

I’ve been thinking a lot about its positioning as I’ve been working on Vue, and now I think what differentiates it from other frameworks is the idea of Progressive, or “Progressive” — the word is defined in English as Progressive, step by step, not that you have to use everything all at once.

3. Design of Vue

Let’s go back to the picture we looked at earlier:

Review images

Vue can cover everything on this map from a design perspective, but you don’t have to start with everything, because you don’t have to. This is optional, both in terms of learning and in practical situations. Declarative rendering and build systems are part of Vue’s core library, while client-side routing, state management, and build tools all have their own solutions. These solutions are independent of each other, and you can build on top of the core any number of other components you want, not necessarily all of them.

4. Realization of Vue

Let’s take a closer look at these specific concepts and how Vue implements them.

(1) Declarative rendering

Almost all frameworks now agree that the DOM should be a functional to state mapping as much as possible. State is the only truth, and DOM state is just a mapping of data state. As shown in the figure below, all logic should be done at the state level as much as possible. When the state changes, the View should be automatically updated to a reasonable state with the help of the framework, rather than manually selecting an element and dictating its properties when you observe the data change.

Review images

Below is an example of a template for Vue. If you haven’t used Vue, you can get a sense of what this concept is like.

Review images

In fact, Vue is similar to Angular in template syntax. In Vue1.0, templates are implemented in a similar way to Angular, as shown in the figure below. Templates are directly parsed into a DOM tree in the browser and then iterated through the tree to extract the various bindings.

Review images

In Vue2.0, a fundamental change was made to the rendering layer implementation, which introduced the virtual DOM.

Review images

In terms of architecture, Vue2.0 is still written in the same template (Vue2.0 was released some time ago, specifically: lighter and faster Vue.js 2.0). On the far left, the template syntax for Vue2.0 and 1.0 is mostly compatible. After compiling the templates, Vue’s compiler compiles them into a rendering function. When called, the function renders and returns a tree of the virtual DOM. The tree is very lightweight, and its job is to describe the state the interface should be in. Once we have the virtual tree, we hand over the patch function to actually apply the virtual DOM to the real DOM. In this process, Vue has its own responsive system to detect the data sources it relies on during rendering. After the data source is detected during rendering, changes in the data source can then be accurately sensed. You can then re-render as needed. When the rendering is done again, a new tree is generated and compared to the old tree, and the changes that should be applied to the real DOM can be determined. Finally, the patch function is used to make changes.

The main reason for this is that in a browser, JavaScript is very fast in modern engines, but DOM itself is a very slow thing. When you call the native DOM API, the browser needs to be exposed to the native DOM implementation in the context of the JavaScript engine, which has a considerable performance cost. Therefore, the essential consideration is to keep the time-consuming operations as pure as possible in order to ensure that the resulting operations require minimal actual contact with the real DOM.

Let’s look at the render function. React doesn’t have a template, as developers who have used React know. It’s just a rendering function that returns a virtual DOM tree. JSX is really just a set of syntactic sugar that makes it easier to describe tree structures.

As shown below, in Vue2.0, you can see that when the template on the left, for example, is compiled by Vue, it becomes the one on the right.

Review images

This function is similar to creating a virtual element. We can give it a name, give it a description of the attributes it should have, and possibly other data. And then this last argument is an array that contains the children of that virtual element. In general, this is what the 2.0 compiler does.

Meanwhile, in Vue2.0, users can choose to skip the template layer and write rendering functions by hand, as well as optional JSX support. Templates and JSX have their pros and cons from the perspective of developer preferences and developer benefits. Templates are closer to our HTML, allowing us to think more intuitively about semantic structures and better integrate CSS writing. JSX and direct render functions, because they are real JavaScript, have all the power of the language itself, can make complex logical judgments, selectively return the DOM structure that is ultimately returned, and can do things that are difficult to do within the syntax constraints of templates.

Review images

So in Vue2.0, both are optional. Use templates for the most part, but use rendering functions when complex logic is required. In Vue2.0 routing and some internal practices, a large number of rendering functions are used to make complex abstract components, such as transition animation components and link components in routing, which are realized by rendering functions, while retaining its own dependency tracking system.

As shown in the figure below, Vue’s dependency tracing is implemented through ES5’s Object.defineProperty method. For example, if we give it a native object, Vue will iterate over the attributes of the data object and then convert them. Each property is converted to a getter and a setter. Each component also has a watcher object that records which properties of the data are used when the current component is rendered.

For example, when A.B is used in a rendering function, this fires the corresponding getter. The main points of the whole rendering process are as follows:

  • When a data property is used, the getter is triggered, and the property is logged as a dependency by Watcher.

  • When the entire function is rendered, every data attribute used is recorded.

  • When the corresponding data changes, such as giving it a new value, the setter is triggered to inform the data object that the corresponding data has changed.

  • The corresponding component is notified that its data dependency has changed and needs to be rerendered.

  • The corresponding components mobilize the rendering function again to generate Virtual DOM and realize DOM update.

Such a process is quite different from mainstream frameworks such as React. In React, shouldComponentUpdate should be used when components are complex. However, it has its own pitfalls, such as ensuring that the component below it does not depend on external state. While this is sufficient in most cases, optimizing this process can be a complex topic for applications of great complexity and performance bottlenecks.

As shown in the figure below, in Vue, due to the existence of tracking system, when any data changes, every component of Vue knows exactly whether it needs to be redrawn, so manual optimization is not required. When rendering these components with Vue, the data changes and the corresponding components are basically removed from the need for manual optimization.

Review images

(2) Component system

It is believed that almost all modern frameworks have gone down the componentized path, and Web Components practice this at the specification level. The main frameworks have different packages, but the core idea is the same, mapping the UI structure to the appropriate component tree, as shown in the figure below.

Review images

In Vue, communication between parent and child components is passed through props. Unidirectional transmission from parent to child; If a child component wants to cause side effects in its parent, it needs to send events. This results in a basic parent-child communication pattern, with additional scenarios when large-scale state management is involved, which will be discussed later.

Review images

After the introduction of the build tool, there is the concept of a single-file component, as shown below, which is the Vue file. In the same Vue file, you can write template, script, and style all in one. Meanwhile, Vue’s single-file component is fundamentally different from Web Components in that it is implemented based on build tools. The benefit is that there is a building opportunity to do more analysis of these single-file components, and to use separate processors within each language block, as we’ll see later.

Review images

(3) Client routing

When you make an application with a very complex interface, it has a lot of states, and such an application obviously cannot refresh a page after every operation as user feedback. This requires the application to have multiple complex states that correspond to urls. There is an important feature called deep-linking, which means that when a user browsed to a URL and then sent it to someone else or copied it and opened it again, the app needs to render the state of the URL directly. This means that there is a mapping between the application URL and the state of the component tree, and it is the job of client routing to make this mapping declaratively correspond.

Review images

If you want to implement such a route yourself, it seems very simple, using hash simulation, you can quickly make a very simple route yourself. In fact, client routing involves many more complex issues, as shown in the figure below.

There may be multiple exits for the same layer of routes, complex URL matching rules, and so on. If these problems are implemented by themselves, then the complexity is very high. Vue has a corresponding solution (Router.vuejs.org). Webpack can also be used to implement lazy load based on routing. Components corresponding to a path will be separated into another piece when packaging, and will only be loaded when the path is accessed. There are solutions, and there are examples.

(4) State management

When it comes to state management, you are essentially abstracting the entire application into the loop shown in the figure below. When Facebook first came up with Flux, it was a loose concept, and the official implementation itself was hard to use. So, the community did all sorts of explorations. The three things in the figure are a one-way data flow. State drives the rendering of the View, and when the user manipulates the View to generate Action, the State changes, causing the View to re-render.

Review images

A single Vue component is already structured like this. But there is a problem when multiple such components come together. Each component has its own state, but there is not necessarily a one-to-one correspondence between the application state and the component. This state may be a global state. So where does the state go? Most solutions are to pull this state out of the component tree and put it in a global Store. Vuex does the same, but it is specialized for Vue. We see the Vue components on the far left. These components, for the most part, no longer have private state, but instead get state from the global Store. Actions and Mutations are difficult to explain in a word or two. Roughly speaking, Mutations need to be explicitly triggered when an application state changes, while Actions is responsible for asynchronism and other side effects. Because Mutations will be recorded, we can send those records to the tool for analysis, or even rollback. This allows us to better understand state changes in large applications when bugs are found. For more details, see the official documentation (vuex.vuejs.org).

Review images

(5) Build tools

In terms of build tools, Vue has an official, globally installed VUE-CLI. There is a clerical error here. After the global installation, you can create a new project using the Vue command. The Vue CLI differs from other CLI commands in that there are multiple optional templates, some simple and some complex. Minimal configuration, faster installation, you can get started faster. It also has a more complete template that covers everything from unit tests, but it is also more complex, which in turn involves choosing the right complexity based on the use case. After all the templates are created, the build scripts are executed by NPM scripts. When installing NPM dependencies in China, there are some cards. You can use YARN or taobao’S NPM mirror source, which can greatly improve the installation speed.

Review images

Single-file components mentioned earlier, as shown in the figure below, support any processor, hot reload out of the box, so components are hot-reload supported. When you make a change, it doesn’t refresh the page, it just reloads the component itself immediately and doesn’t affect the current state of the entire application. CSS also supports hot overloading. Looking at the bottom left, while using the preprocessor, we just need to add a scoped feature, where Vue simulates CSS by parsing and rewriting templates and CSS code. Single-file components also support lazy loading. A lazy component and its dependencies are packaged into an extra package that is loaded only when needed, which also helps with the loading speed of the first screen.

Review images

As you can see in the figure below, the developer tool itself is written in Vue.

Review images

Using it, you can see the component tree structure of our current application.

Review images

Click on the component to see the current state of the component. You can also send this component to the console. The developer tool also has a Vuex panel, so if you are using Vuex, every action is recorded and you can jump between recorded states. In addition, you can send a snapshot of your current app status to another person, who can import the status you sent to their console and immediately jump back to your previous status. This is useful for recreating bugs or describing current state.

Review images

Four, Vue2.0

Vue2.0 was released a short time ago, and some of the technical details have been covered before.

Vue2.0 has the following improvements over 1.0.

1. The lighter

Review images

For Vue1.0 size compression, Vue2.0 has a run-time only version where all templates are completed at compile time. Based on this version, Vue, VUE-Router, and Vuex (all version 2.0) in the figure below are the same size as the core library of Vue1.0.

2. The faster

Vue2.0 is arguably one of the fastest frameworks available. This is based on the results of independent third-party testing. Are interested, you can move to link (http://stefankrause.net/js-frameworks-benchmark4/webdriver-ts/table.html) to view. This test is a comprehensive test with fairly complete coverage of various operations, updates and removals in a large list, etc. As you can see, Vue2.0 is not only a big improvement over Vue1.0, but also has significant performance advantages over other frameworks.

Review images

3. Vue2.0 architecture

The following is an architecture diagram of Vue2.0. We will not go into the implementation of the entire architecture here.

Review images

Vue2.0 also supports server, and server rendering supports streaming rendering. Since HTTP requests are also streaming, Vue’s server rendering results can be piped directly into the returned request. This way, the content can be rendered to the user in the browser earlier, and with proper caching strategies, the performance of server-side rendering can be significantly improved. The picture below shows the content of Vue2.0 and server rendering, which basically integrates all the functions together. If you are interested, you can search for 2.0 here, which can be used as a reference application.

Review images

In addition to server rendering and native rendering, native rendering here refers to Alibaba’s project Weex.

Review images

At the architectural level, compile a Weex source file (similar to Vue’s single-file build format) and run it. The interface node operations are abstract, and these abstract operations are sent to different target engines for actual rendering, supporting iOS, Android and Web.

Review images

Vue and Weex now have a collaboration and Vue 2.0 will officially become Weex’s JavaScript runtime. This collaboration enables Vue components that match the functional intersection to be used across platforms.

Review images
Long press the QR code to follow