Home  >  Article  >  Web Front-end  >  Let’s talk about our understanding of modern front-end frameworks

Let’s talk about our understanding of modern front-end frameworks

青灯夜游
青灯夜游Original
2018-09-10 16:14:151369browse

This chapter talks about the understanding of modern front-end frameworks. It has certain reference value. Friends in need can refer to it. I hope it will be helpful to you.

So why do people need to choose various frameworks now?

In fact, the reason why we need to choose a framework now is essentially because the needs we face have changed. Everyone must understand that if we only write a page that only displays information without any interactive functions, in fact, even now, we do not need to choose a framework. We only need to write a few lines of CSS and HTML to complete the task. So because the requirements we face have become more complex, our applications often need to do some interactions at runtime.

There are three very important words in bold, which are called Runtime. In modern front-end development, the applications we develop often require some interactions at runtime. In the early days, these interactions were just simple interactions such as slides or tab switching drop-down menus. There is no problem in implementing these interactions with jQuery. But our goal for the modern front-end is to use the Web to PK native applications and compete with Native.

At this time we will find that using jQuery to develop applications makes our code difficult to maintain. So why does it become easier to maintain using modern frameworks such as Vue, React, etc.?

The only difference between Vue and jQuery is declarative and imperative.

We can think about it, what is the purpose of using jQuery to operate DOM? It is to update the view locally, in other words to re-render locally.

jQuery is an imperative way to operate the DOM and an imperative partial update view, while modern mainstream frameworks such as Vue, React, Angular, etc. are all declarative and a declarative partial update view.

Why does declarative DOM manipulation make applications easier to maintain?

To understand this problem, first let’s briefly introduce what is an imperative and what is a declarative.

Imperative

Imperative style, like jQuery, we just do what we want to do, for example, the following code:

$('.box')
  .append(&#39;<p>Test</p>&#39;)
  .xxx()
  .yyy()
  .jjj()
  ...

Imperative style means we just do what we want to do. Just call the method directly and it's done. It's simple, direct and crude.

Imagine a very simple scene, such as a toggle effect, click a button to switch colors.

Write it in imperative style. We must write it like this. If the current color is, let it change to another color.

If you think about it carefully, it can actually be subdivided into two behaviors, one is to judge the status, and the other is to operate the DOM.

So what is declarative? ?

Declarative

Declarative is to describe the mapping relationship between state and view, and then operate the DOM through such a mapping relationship , or to be more specific, use such a mapping relationship to generate a DOM node and insert it into the page. For example, templates in Vue. The function of the template is to describe the mapping relationship between state and DOM.

We use the template in Vue to implement the same scenario. After we use the template to describe the mapping relationship, when we click the button, we only need to modify the color variable to complete the requirement.

See the difference?

Think carefully and use Vue to achieve the same requirement. If you break it down, we logically have only one behavior and only state. And jQuery has two behaviors, state and DOM operations.

So why can declarative style simplify the complexity of maintaining application code?

Because it allows us to focus only on state maintenance. In this way, when the application becomes complex, in fact, our thinking and the way we manage the code are only in terms of status, and we no longer need to care about all DOM operations. It can be said that the complexity of code maintenance is greatly reduced.

We no longer need to pay attention to how to operate the DOM, because the framework will do it automatically for us, we only need to pay attention to the status.

But if the application is particularly complex, we will find that even if we only focus on state maintenance, it is still difficult. Even if we only focus on state maintenance, it is still difficult, so technical solutions such as Vuex and Redux have emerged.

What is rendering?

After the previous introduction, you will find that the most essential problem to be solved by modern mainstream frameworks is still rendering. It’s just that the solutions between different frameworks are different. So what is rendering? ?

Now when developing the front-end, our application needs to continuously carry out various interactions while running. Modern mainstream frameworks allow us to focus on state maintenance, which means that when the application is running, inside the application The status will continue to change.

The process of inserting the state-generated DOM into the page and displaying it on the user interface is called rendering.

Modern front-end framework’s rendering processing

When the application is running, the internal state will continue to change. At this time, the user page A certain local area needs to be constantly re-rendered.

How to re-render?

The simplest and crudest solution, which is also the most commonly used way when I write some simple functions in projects that do not use any framework, is to use the state to generate a new DOM, and then use innerHTML to replace the old DOM. .

There is no problem using this method for the small function block I wrote, because the function involves few DOM tags. When the state changes, almost all the tags of my function block need to be changed, so even if I use innerHTML will not waste much performance and is within the acceptable range.

But the framework cannot. If the framework is replaced with innerHTML, it will not be partially re-rendered, but the entire page will be refreshed as a whole. This changes its nature. So how can the framework achieve partial re-rendering?

To solve this problem, some technical solutions are needed. It can be VirtualDOM, but it does not necessarily have to be VirtualDOM. It can also be the dirty detection process in Angular, or it can be fine-grained binding, like Vue1.0 is implemented using fine-grained binding.

What is fine-grained binding?

Fine-grained binding means that when a certain state is bound, it is bound to a specific label in the page. That is to say, if there are ten tags in the template that use a certain variable, then the variables are bound to 10 specific tags.

Compared with React and Angular, the granularity is relatively coarse. Their change detection actually does not know which state variable is specific, so a violent comparison is required. Only after the comparison can you know which part of the view needs to be modified. renew.

The fine-grained binding of Vue actually knows which state has changed at the moment the state changes, and also knows which specific tags use this state, then things will change. It is much simpler. You can achieve the purpose of local update by directly updating the specific tags bound to this state.

But this actually comes at a certain cost, because the granularity is too fine, and there will be a certain overhead of dependency tracking. Therefore, Vue2.0 began to adopt a compromise solution, which was to adjust the binding to medium granularity.

A state corresponds to a certain component rather than a specific label. One advantage of this is that it can greatly reduce the number of dependencies. After all, the number of components is much smaller than the number of specific labels in the DOM. . But this requires one more operation. When the status changes, only the component is notified. So how does the component know which DOM tag to update? ?

The answer is VirtualDOM.

In other words, when the granularity is adjusted to medium, one more operation is required to use VirtualDOM inside the component to re-render.

Vue cleverly improves the performance of the framework through the two technical solutions of change detection VirtualDOM.

So, Vue2.0 introduced VirtualDOM not because of how good VirtualDOM is, but because VirtualDOM combined with change detection can adjust binding to medium granularity to solve the overhead problem of dependency tracking.

Regarding change detection, I wrote a special article to introduce how Vue implements change detection. Portal.

So the method of change detection has, to a certain extent, determined how the framework renders.

I have written a PPT about the implementation principle of VirtualDOM. If you are interested, you can take a look at the portal.

Another one is template compilation. In fact, I didn’t say much about the issue of template compilation before. The function of the template is to describe the mapping relationship between the state and the DOM. Through the template, a rendering function can be compiled and executed. This rendering function can get the VNode provided in VirtualDOM. In fact, if you have seen the PPT I introduced the principle of VirtualDOM earlier, you will know that VirtualDOM diffing the node is actually diffing the VNode. I have written a special article to introduce the implementation principle of template compilation, portal.

Summary

I personally feel that the current front-end is a bit impetuous. Many people are chasing new things. They pay attention to some new features every day. Today, a new feature will be released tomorrow. I agree with frameworks and such, but I hope to see its essence while pursuing new things. The ultimate goal of all technical solutions is to solve problems. There is a problem first, and then there is a solution. The solution may not be perfect, and there may be many solutions. So what are the advantages and disadvantages between them? What trade-offs and trade-offs did each of them make while solving the problem? We have to see the essence through the phenomenon so as not to be confused by the surface.




The above is the detailed content of Let’s talk about our understanding of modern front-end frameworks. For more information, please follow other related articles on the PHP Chinese website!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn