There's a misconception about front-end and back-end separation, and that is that many people claim: we've been doing it for a long time, it's all AJAX, just use Angular or whatever.

This statement is inappropriate, let's say, others ask is "how to solve the problem of poultry eggs in the side of the water and grass? But in fact, they are raising ducks, but the answer is chicken farmers, so the answer is "just don't let them go to the water's edge", which is obviously not on point.

The industry in the past two years said that the front-end and back-end separation, is limited to the display of the system (replaced by A), rather than applications, control Web projects (replaced by B), in the B project, the front and back-end are naturally separated, in addition to

a small number of back-end developers, basically everyone's understanding is the same. The people who answered this way in the previous paragraph generally work only on B projects, where the separation of front-end and back-end is ****ing understood and not up for discussion.

Then, the question that remains is to discuss front-end and back-end separation in class A projects. The core of this problem in what place it lies in the template of the location of the combination with the data, as well as, the template control in the hands of whom. After two years of discussion, basically we can reach a *** knowledge is: templates should be controlled by the front-end staff, mainly for two reasons:

Performance optimization (especially the management and release of external resources, request consolidation, etc.)

Smoothness of the collaboration (has formed a template for the rework of the interface fragments of the problem)

So the templates in the end should be in the Where exactly should templates be combined with data?

This question is a bit of a toss-up, some people try to use js templates like the B class project, and then executed on the browser side, which is there are some problems, such as seo is not friendly, the first screen performance is not enough, especially for the home page DOM amount of e-commerce sites, the gap is very obvious.

So we still have to put the main template on the server side to execute. In this process, Ali made some attempts, that is, the introduction of the Node layer, in this layer of the template and data synthesis, and then the browser to get the

generated HTML, but not all HTML is so generated, there will still be some of the contents of the browser until after the browser, and then use js to load and generate.

So it's going to be a hybrid solution where there are two templates in the same system, one executed on the server side and one executed in the browser, complementing each other.

As for this program, whether the middle layer must be node, I think it does not matter, as long as it is something that can normally do web projects can be, this still depends on the direction of the accumulation of technology in the enterprise, of course, node

do this is some advantage, such as the front-end staff of the language friendly, front and back end of the templates of the universality of the etc., but these are details, the focus is still the overall program and process.

This time to look back at this sentence in your question:

The front-end and back-end separation means that the front-end and back-end only through the JSON to communicate, componentization, engineering do not need to rely on the back-end to achieve.

I believe you are qualifying the front-end and back-end here in terms of the browser, but the fact is that the demarcation of the front-end and back-end in a Class A project must extend to the server-side template layer, that is, the layer where the data from various sources is integrated into the template, which may not necessarily be in JSON format, and will exist in JSON, XML, a specific binary, and so on.

The topic of componentization is even more complex, and it's hard to say exactly what constitutes a component in the form in which it was just organized. Is it a template for a particular item? Is it data? Is it a combination of data and template? There's no way to answer that. Here, I say a word of my own opinion: like the front-end part of the project such as e-commerce, there is basically no concept of components, and there is even no value of componentization, because there are too few reusable things, it is not easy to extract, most of the things are not logical interface templates.

Recently, because of the popularity of ReactJS, it brings a concept of Isomorphic, which is a very meaningful exploration, but whether it can solve this kind of problem is not yet known, according to my understanding, it is a better complementary solution to the B class project, but lack of usability for the time being for the A class project, because in the A class project, there are not many DOM changes in the runtime, it's mostly the The whole piece of change, with this program to solve the case, some of the feeling of killing chickens with a bull's-eye.