Some of the words written up front

It has been six years since I officially knew the front end position when I was in college, which is like watching a grand garden activity for me. Countless frameworks, patterns, and development ideas pass by like floats. It left a mess of embers and broken thoughts.

When I looked up, it was the age of residual MVVM. Vue and React are popular, and recent graduates seem to have accepted that they can’t find a job under either framework. They are also good at explaining questions in interviews and explaining principles in the source code.

However, the principle of source code is always a layer of superficial elaboration, you have not a little bit of careful tracking of every step, nor in the framework design time to infiltrate their own thinking and proposals, but never to understand the framework was designed and iterated requirements and background. This way, you’ll always know HOW, not WHY.

These days listening to ali P8 water stop bosses said that in most cases, will be more technical strength is not too big difference, technical strength on the code to peak few people, more code the climber will take the way of thinking to progress, so they went to broaden their horizons, to understand the history of the evolution of the code to predict the trend of the future. And this is more than just knowing HOW.

Now I’m just a small front end with two and a half years of experience. But work experience does not hinder technical love and thinking in the slightest. The computer is the real magic of modern social progress, and we, the magicians in charge of that magic, can crack the mysteries behind it, and leave our mark on the Babel of code, is what we want.

From DOM to virtual DOM, what questions should we ask?

In today’s interview learning environment, the most common questions we are asked about the virtual DOM are:

“What is the virtual DOM?”

“Why the virtual DOM?”

The first question is actually easier to answer. In my opinion, the better answer is: “Virtual DOM is essentially a set of JS-TO-DOM mappings, which are presented as a JS object containing all the information required by DOM.” In general, questions like what are easier to answer. Because you only need to describe him, and the why question is often difficult to say, because it often contains a lot of extended information.

So when I heard seen to answer the second question, the most is: “the reason for choosing to use virtual DOM directly operate DOM node price is too expensive, the cost of operating JS will be much smaller, direct manipulation will cause the browser’s DOM node reflow re-paint, JS can play the advantages of his freedom of choice of operation time and way.”

But is that really all there is?

Let’s take a look beyond just one word, virtual DOM, and look back over the years of rapid iteration at the front end and rethink some of these questions.

  • What happened before the virtual DOM?
  • What inspired programmers to use the virtual DOM?
  • What are the advantages of the virtual DOM, and what makes it the time of choice?
  • What is driving the rapid development of front-end functions and functions?

What have we experienced as the front end?

When I started to work, VUE and React had already become the mainstream. Although they were not as popular as they are now, they were no problem. The needs and functions of the page are already quite complex. Let’s go back in time and look at the development of the front man from the beginning.

Static pages and cut diagrams – Low requirements for low requirements

Once upon a time (heard), there was such an era, front-end students the most troublesome work is to cut the map, the most boring task is to rub DOM, so it was called cut map boy…

At that time, there were only a few basic versions of JS frameworks, including but not limited to Prototype, and developers relied on a lot of hand-wringing between DOM and native JS to achieve some simple interactions, while high-end operations might strip scripts and components to achieve their own functionality.

The front-end developers of this era were very pure, before the process of separating the front end from the back end had begun, and all developers had to do was present the page properly and implement few interaction requirements.

JQ Era — contradiction between increasing demand and low development efficiency

Once a thing appears, the tide of history will carry it forward continuously. Soon, people didn’t just want pages to work — they wanted more cool interactions, which created problems for front-end engineers because the native JSapi was scarce and hard to use at the time. As a result, A large number of JS frameworks such as JQ emerged.

Contemporary frameworks include, but are not limited to, JQ, Dojo, Prototype, etc., all of which are almost vintage to young front-end engineers. But back then, compatibility issues, a legacy of the post-browser wars era, were a major bane of the engineers of the time (they still are, of course, but they have been mitigated by an increasing number of plugins). With its excellent compatibility and performance, JQ has occupied the mainstream of a generation of JS frameworks.

From today’s point of view, JQ is still a very good framework, thanks to the development of the Sizzle selector engine, its performance has been a qualitative breakthrough. It takes writing front-end code out of the mind of manipulating classes at the back end, fetching a DOM node or set of DOM nodes in a portable way, and provides chain calls. Front-end developers don’t have to worry about how to manipulate the DOM properly, they just need to worry about implementing the business logic.

The JQ era was the product of the first major conflict between demand and efficiency, and since then, the liberation of productivity has become the eternal pursuit of front-end engineers.

Post-jq – Template syntax for further efficiency

JQ and its highly developed ecological environment gave rise to the rapid development of JQ plug-ins. At that time, front-end developers wanted to realize a function, and their first reaction was to search for plug-ins. Therefore, more than a dozen or even dozens of

Faced with the problem of global variable pollution caused by developers of varying quality (with varying levels of plug-in quality) and an increasingly large plug-in library, front-end developers are taking their inspiration from the code of their back-end brethren — they too want modularity.

In those days, javaScript didn’t have standardized support for import and export, so they created their own standard, CommonJs. Then, of course, there was the split into AMD, CMD and so on. This foreshadowed the rapid development of Node.js. Modularity related knowledge is not related to the main idea of this paper, so I will not expand into details.

JQ also failed to address the need for cyclic insertion of DOM nodes, and DOM strings composed of concatenated data were a source of frustration for developers. Thus template syntax was born. To summarize it in a classic formula, it is:

HTML = template(data)

As you can see, template is simply a rule for converting data into the DOM — and customizable! The principle of template is actually very simple, which can be roughly divided into the following steps:

  • Take the data, parse them

  • Fill in the template

  • innerHtml

After solving the need to insert DOM nodes in a loop, the front-end engineers discovered that the template syntax had a much bigger advantage — all you had to do was map data to DOM nodes, you didn’t have to manipulate the DOM point-to-point, you didn’t have to care how the data changed, you just had to control the rules. Perhaps from that moment forward, front-end developers found a new and correct direction of development — data-driven.

But template syntax has its drawbacks. To put it bluntly, he’s just a data parser, and you can’t expect him to solve complex and cool problems. And in the early days of template syntax, his update would unregister all the DOM nodes and then insert the entire new node into the page. Manipulating the DOM in such large quantities is bound to cause performance problems — it’s too expensive to manipulate the DOM, let alone an entire page of dom.

As a result, developers are caught in a dilemma between writing well and using well, but not using well (you know what I mean), and then some big guy suddenly gets up in the air one day and says, it costs so much to operate dom, I can just use JS!

Three framework eras – the whirlwind of virtual DOM

Dom manipulation is so expensive, why don’t I just use JS?

This crazy yet reasonable idea, once created, can never be extinguished because it suits JS too well. Js can operate DOM instinct at the beginning of its birth, and THE ability of JS itself is so powerful, template syntax shortcomings it can fully digest and contain, including but not limited to the difference update, batch update and a series of dream can improve the rendering performance of the means can finally be put on the agenda.

The door to a new world opened.

At this point, let’s be clear: the virtual DOM was born as a buffer between the data and the real DOM.

With the virtual DOM, the front-end world is more dynamic. Angular, React, and Vue, three virtual DOM-based frameworks, have survived the storm and become the mainstream in the new world.

What are the advantages of the virtual DOM, and what makes it the time of choice?

As mentioned earlier, the virtual DOM was born as a buffer layer between the data and the real DOM. The data is converted into a virtual DOM via some template/syntactic sugar/function for js level control. This conversion is

In the reactVirtual DOM < div > < / div >The virtual DOM form

This allows the crucial function of “differential update” to be applied, where the new virtual DOM tree is compared with the old virtual DOM tree using the diff algorithm to form a “patch”, and the batch method is used to batch the patch to the nodes that need to be updated. Differential updates provide developers with a comfortable development experience while maintaining excellent performance. It’s a win-win model for both writing and using.

In addition to the application of the crucial function of “differential update”, another important function is “batch update”, that is, users will take the last operation results of dom in a short period of time, so as to avoid a large number of costly performance consumption. This is where the Batch method comes in. It buffers each patch set generated, puts them in a queue, calculates a render result, and then feeds it to the render function for batch updates.

With all these advantages, it’s tempting to think that the virtual DOM is better than the template syntax, but is that really true?

For template syntax, the flow is data -> template -> real DOM. For virtual DOM, the flow is data -> template/algorithm/syntax sugar -> virtual DOM -> a series of JS operations -> real DOM.

You suddenly realize that the virtual DOM flow is so much longer, why do people say it is better performance?

The answer to this question depends on the environment: on a small amount of data, the performance of the two is about the same. In the case of large data volume, the template syntax performance is better if the data changes greatly, which is close to full page update. The virtual DOM performs better in an environment dominated by partial updates. And this happens to be the most frequent online situation.

In modern template syntax, template syntax also has the ability to convert data into a virtual DOM. So don’t automatically assume that virtual DOM is better than template syntax. It is a fallacy to say that applying the virtual DOM gives better performance in certain circumstances than applying the template syntax alone.

Further, the virtual DOM provides a unified entry to operate DOM objects, in today’s increasingly advocated multi-terminal code a set of common today, virtual DOM can be IOS interface, can be android interface, can be small programs, can be other…. All it requires is a different translation, which makes it truly multipurpose.

At this point, let’s summarize the advantages of the virtual DOM.

1. It makes users feel good because it addresses key pain points of page performance optimization.

2. It allows developers to develop very cool, cool means the efficiency of iteration, means the initiative of community maintenance.

3. He can solve the problem of multi-terminal reuse and uniformity, which can reduce costs, and reducing costs means occupying the market.

What is driving the rapid development of front-end functions and functions?

From the foregoing, it’s no surprise that the front-end stack is changing rapidly. From a static page to today’s big front end daquan stack micro front end, as if the front end of the building in a short decade of dust settled, shining.

So what is driving the rapid growth of front-end functions and functionality?

This question I think the students who seriously understand the history of front-end development will be thoughtful. Why don’t we move on to something more substantive.

What technologies/projects will become popular projects and even lead to environmental development?

From my point of view. All technologies/projects that can be called successful have one characteristic — a win-win in performance and capacity

JQ is a sign of The Times because it liberates developer productivity and offers performance unmatched by native apis.

Virtual DOM accurately solves the pain point of poor performance in the case of multiple interactions, and frees developers from DOM’s mystery lock, focusing only on data and data changes, and opens the door to more unity

Node.js, so that JS can also write back end, epoch-making concept

.

As a developer, the improvement of technology will slow down with the fading of energy. As I said at the beginning, most people above P7 may not have much difference in their technical strength, but the difference lies in their different opinions and understandings about the development direction of technology and the future prospect of the project. As we reach the end of our working life, we will inevitably assume certain leadership responsibilities. At this point, performance and productivity will be the project indicators we need to pay attention to and care about the most. At this point, forward-looking, systematic thinking is essential.

In fact, this article does not elaborate too much technical details, I want to convey to you an idea of understanding technology. This kind of technology, why did this project take off? Is there any motivation behind it? What is the path that its predecessors or predecessors have trodden? If you look into the future, what do you think? What pain point does its existence solve? When we look beyond technology to the technology itself, we may gain more than technology alone.

Finally, the career of the front end has developed from dust till now, and we have reason to believe that its future lies in the sea of stars.