Talk about my understanding of modern front-end frameworks

There are three major frameworks in the front-end world right now, Vue, React and Angular, which are almost all necessary skills to be a front-end engineer.

But I don’t know how many of you have thought about why that is?

At present, some fresh graduates and newcomers will be faced with the choice of learning Vue or React or Angular as soon as they step into the front-end industry.

In fact, in the early years, we didn’t have this problem, we didn’t have to choose, back then we wrote the front end of jQuery as a shuttle, just do it, do it.

So why do people need to choose frameworks these days?

The reason we need to choose frameworks now is essentially because the requirements we face have changed. I’m sure you all know that if we just wrote a purely informational page with no interaction, even now we don’t need to choose a framework, we just need to write a few lines of CSS and HTML to get things done.

So as the requirements we face become more complex, our applications often need to do some interaction at run time.

There are three very important words in there that I’ve put in bold, and they’re called Runtime. In modern front-end development, we often develop applications that need to do some interactions at runtime. In the early days, these interactions were just slides or tab-switching dropdown menus, and these interactions are perfectly fine with jQuery. But the modern front end, our goal is to use the Web to PK Native applications, to PK with Native.

When we use jQuery to develop applications, our code becomes difficult to maintain. Why is it so easy to maintain using modern frameworks like Vue, React, etc?

Here please let me tell a story, a small episode, a few days ago I was in a wechat group, someone discussed, what is the difference between Vue and jQuery, someone very strongly said that the difference is that Vue has components, what has some features of this and that.

At that time, I expressed my opinion in the wechat group, and I said that the difference between Vue and jQuery is only one, declarative and imperative.

What is the purpose of using jQuery to manipulate the DOM? Is to update the view locally, in other words, to rerender it locally.

JQuery is an imperative manipulation of the DOM and an imperative partial update view, while Vue, React, Angular, etc., are all declarative, declarative partial update views.

Why does declarative manipulation of the DOM make an application maintainable?

So let’s first talk a little bit about what is imperative and what is declarative.

imperative

Imperative, like jQuery, where we want to do something and then do it, as in the following code:

$('.box')
  .append('<p>Test</p>')
  .xxx()
  .yyy()
  .jjj()
  ...

Imperative is to do whatever you want to do and just call the method and just do it, simple and crude.

Imagine a very simple scenario, like a Toggle effect where you click a button and switch colors.

I’ll write it imperative, and we’ll definitely write it this way, if it’s in any color let’s change it to another color.

If you think about it, there are actually two behaviors, one of which is state judgment, and the other is DOM manipulation.

What is declarative?

declarative

Declarative manipulation of the DOM is done by describing a mapping between the state and the view, or specifically by using such a mapping to generate a DOM node to insert into the page. Such as templates in Vue. Templates are used to describe the mapping between states and the DOM.

The same scene is realized by using the template in Vue. When we describe the mapping relationship with the template, when we click the button, we only need to modify the variable color to complete the requirements.

See the difference?

If you think about it, using Vue to implement the same requirement, if you break it down, logically we only have one behavior, only one state. JQuery has two actions, state +DOM manipulation.

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

Because it allows us to focus only on the maintenance of the state. This way, when the application is complex, in fact, our thinking, our way of managing the code is only in the state, all DOM manipulation is not concerned with, so it can be said to greatly reduce the complexity of code maintenance.

We don’t have to worry about how to manipulate the DOM anymore, because the framework does that for us automatically, and we just focus on the state.

But if the application is really, really complex, we find that even if we just focus on maintaining the state, it’s still very difficult, even if only maintaining the state, which is why Vuex, Redux and other technical solutions have emerged.

What is rendering?

After the introduction, you will find that the most fundamental problem that modern mainstream frameworks have to solve is still rendering, but different frameworks have different solutions. So what is rendering?

Now developing the front end, our application needs to constantly interact with each other at run time. Modern mainstream frameworks let us focus on the maintenance of state, that is, when the application is running, the internal state of the application will constantly change.

The process of inserting the state-generating DOM into the page for display in the user interface is called rendering.

Modern front-end frameworks handle rendering

While the application is running, the internal state is constantly changing, and parts of the user’s page need to be constantly re-rendered.

How to rerender?

The simplest and most crude solution, and one that I often use to write simple features in projects that don’t use frameworks, is to create a new DOM with state, and then replace the old DOM with innerHTML.

I can write a small function block this way, because there are few DOM tags involved in the function, and when the state changes, almost all of the tags in my function block need to change, so there’s no performance waste even with innerHTML.

But you can’t do that with a frame, because if you replace a frame with innerHTML like this, you’re not just rerendering it locally, you’re refreshing the page as a whole, and that changes, so how does a frame do that locally?

This can be VirtualDOM, but it doesn’t have to be VirtualDOM, it can be an Angular dirt-detection process, or it can be a fine-grained binding, like the fine-grained binding used for Vue1.0.

What is fine-grained binding?

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

React and Angular are coarse-grained, and their change detection does not know which state variables are involved, so a violent comparison is required to know which parts of the view need to be updated.

Vue such a fine-grained binding actually change in the status of that a moment, immediately know which state has changed, but also know what the exact label use this state, so it becomes more simple and direct to the status of these specific binding update label can achieve the goal of partial updates.

But there is a cost to doing this because of the granularity and the overhead of relying on tracing. So Vue2.0 began to take a middle ground, adjusting the binding to medium granularity.

A state that corresponds to a component, rather than a specific tag, has the advantage of greatly reducing the number of dependencies, since the number of components is much smaller than the number of specific tags in the DOM. However, this requires one more operation. When the state changes, only the component is notified, so how does the component know which DOM tag to update?

The answer is VirtualDOM.

That is, when the granularity is medium, one more operation is to use VirtualDOM inside the component to re-render.

Vue cleverly improves the performance of the framework by using two technical solutions: change detection +VirtualDOM.

So Vue2.0 introduced VirtualDOM not because VirtualDOM is so good, but just because VirtualDOM combined with change detection can adjust bindings to medium granularity to solve the overhead of relying on tracking.

I’ve written about change detection specifically to explain how Vue implements change detection. Portal.

So the way changes are detected determines to some extent how the frame is rendered.

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

Templates are used to describe the mapping between states and the DOM. A template can be used to compile a rendering function, which can be executed to obtain the VNode provided in VirtualDOM. In fact, as you can see from my previous slides on how VirtualDOM works, VirtualDOM diff nodes is actually diff vNodes. I wrote an article about how template compilation works, portal.

The last

The last thing I want to say is that I personally feel that the current front end is a bit impetuous. Many people are chasing new things, and they pay attention to some new features today and a new framework tomorrow. I am in favor of these things, but I prefer to see its essence while chasing new things.

The ultimate goal of all technical solutions is to solve problems. There are problems first and then solutions. The solutions may not be perfect, and there may be many kinds of solutions. What trade-offs and trade-offs did each make to solve the problem?

We must look beyond the appearance so as not to be deceived by the appearance.