Large search vehicle front-end development mode: Passive compilation and active compilation

Recently, combed the company's front-end development system, ready to work for more than a year the original system to introduce some new development model, in fact, is not new, but for the model we have been using, is two completely different direction, before, I advocate simple, has been based on the concept of simple and easy to build the company's existing front-end development system, now with the increase in the number of people and business complexity, it feels time to introduce a number of differentiated development system.

It is a bit of a lie around, the above section of the traditional development model, within the team we call the passive compilation, and the new development method, within the team is called Active compilation.

Passive compilation

Many people may not be very familiar with the passive compilation, because this kind of development method is not popular now, but it seems to have never been popular.

The so-called passive compilation. The core idea is that all source code will be compiled when they are accessed.

Here "source" refers to Jade,less,js,coffee or even jsx, such as preprocessing language code, in our company's front-end project, agreed to use these pre-processing language to organize code, their common feature is simple and powerful, and for a team, It is very important that we tend to a language and a pattern, so here we don't discuss the syntax of these preprocessing, but only how we use them.

In the big search car, a front-end development of the development and release process is this: write Jade, write less, write js-> browser access jade corresponding path, browser display compiled html-> HTML CSS content is actually directly from less compiled- > JS and the like also after a service processing--but look at the source, inside only jade,less,jsx and so on.

In fact, the key to passive compilation is a small server, which we call ads internally, which is actually a static server with dynamic functionality. The front-end write Jade,less,js will be hosted in the static directory of this server, and then the browser request, each time will go through the ADS server, the internal logic of the server will determine the current request URL should correspond to the local source of what resources, and then read the source file, The compiler is called directly in the process to return the compiled results to the browser without intermediate files being generated.

Why do we always insist on passively compiling this development model?

• Unify the entire team's development environment, even the pre-processor selection, even the code style.

Seems to be a bit of deprivation of freedom to play the suspect, but for the programmer's problem, it is always difficult to meet the parties, in fact, the unification of a major problem is not flexible enough, but the problem of flexibility is not uniform enough, and then the problem caused by lack of unification will cause some other problems, such as the cost of communication between people, The pain of cross-project development, the code written by predecessors is difficult to maintain, and different projects configure different environments to take away time costs. This problem, we are from the team point of view, personal development has made a part of the sacrifice, through the ads, we have pre-processing language normalization, the project directory normalization, and even the use of pre-processing methods are standardized (not tender use advanced features).

• The developer does not care about the environment and does not need to be configured.

After five or six years of development experience, many of the problems encountered in development have given me profound influence, knowing that some things look good, but put into reality is another thing, in the development of such things, such as modularity, decoupling, refactoring, service these things, in some ways, is a good change, But to some extent, the effect began to backfire, a lot of problems began to magnify, and these problems are often a lot of development are selectively ignored or not considered at all. The concrete will not unfold.

In fact, one of the great benefits (and possibly the downside) of ads is that it doesn't have to be configured. A developer after the job, need to do things, download ads, launch, and then clone our front-end code base, find folders, start writing code, OK, local browser can be real-time access. You do not need to configure the path, you do not need to configure the files to be packaged and compiled, do not need to execute commands, do not need to listen for file changes.

Then, continue, after the development is completed, to publish the test, how to do it, very simple, the files are submitted to Git, and then wait a while, the test environment automatically takes effect. Why does this work? The most important point, the ADS project files do not need to compile, whether on the local or test or online, on your computer on my computer, he is the source file status lying on your hard drive, only browser access to compile files. So, the release test is actually a very simple operation, the file from your local copy to the static directory of the test environment, and the publishing line is actually the same, the file from the test copy to the online directory. As if they were static files, and in fact they are dynamic preprocessing code.

• Enable flexible, dynamic applications.

Give some examples

One is combo, very common needs, our code can be arbitrarily combo, in fact, support any file unlimited combo, when the combo is the CSS, in fact, all less source code merge compiled results, and for JS, is merged and then compressed.

The second is the ability to dynamically generate CSS, which is useful in multi-theme projects. Because our CSS is less written, when you define a variable in less, you can pass in the URL the initial value of the variable, and then the entire theme becomes another color. In the same vein, many things can be passed on, which allows for a lot of flexibility.

Some questions may be asked, but we have raised some questions ourselves:

• Isn't there a problem with performance?

This problem is actually very simple, all of our online static resources are through the CDN, so this problem is not a problem, a file only the first time to be accessed by the dynamic compilation, and then the results of the slow existence of CDN service providers there, the next request will not go to our ads online server. So our on-line service actually carries a few accesses, and there is no performance problem. A set of timestamp refreshes is also required for CDN updates.

• How do I handle timestamp issues?

In our online server, maintenance of a timestamp file, each file in the release system, will go to the file to update their timestamp for the current file hash value. Then in ads memory we will periodically update this timestamp file to memory, each time you render jade, will be brought into a method, this method is set up by the resource file in the rendering of Jade will automatically take his corresponding timestamp, so that the resources in jade can automatically update the timestamp, In fact, developers do not need to care about this matter, everything is automatic. For other services that reference static resources, you need to implement a similar maintenance timestamp key-value pair in their service, and then render the timestamp automatically when the template is rendered. However, this service is very small, we are now the majority of systems are separated from front and back, front-end pages are placed in ads hosted projects, written by Jade.

In fact, the passive compilation and the development environment to support the large search car environment has been 1 years long, also can withstand the test, the current project code is still very clear, there is no big problem, we use a long time, basically forget to compile that set, even the jade, Less as a natural terminal language use, has come to the state of not uncomfortable.

However, with the development of the front-end technology, the project must introduce more advanced compilation features, this time the passive compilation began to seem a little overwhelmed.

For example, our large-scale use of angularjs,react packaging compiled, using ES6 projects, need to introduce webpack,browserify tools such as projects. With the passive compilation There are many restrictions, for these models have been unable to hold, so we think, it is time to introduce the active compilation mode.

Active compilation

The so-called active compilation, in fact, is in the local packaging, and then the results of the file upload to the development mode of the server.

Active compilation generally need to introduce process control tools, such as GRUNT,GULP, the current use of gulp more, and we finally studied the use of gulp, a gulp is said to be relatively simple performance and configuration, the second is the company has a project with grunt, The rear configuration becomes more and more chaotic and eats a lesson.

In fact, before preparing to use the FIS, because it has been blowing relatively strong, I have always thought that FIS is a so-called "engineering" level of the tool, so with the team said to study, and then carefully looked at his own some of the features, found are very basic ah, in fact, ads have these features, and probably better. However, FIS can be implemented through plug-ins to achieve a number of extension functions, but for some commonly used packaging tools are not able to find packaged plug-ins, but also the quality of the plug-in is not suitable for use as a production tool. Finally can only give up.

In my opinion, FIS are relatively basic, suitable for those who do not have their own ready-made development process management tools of the team, for our team, the function and ads overlap, and is not a single. In fact, we want to introduce active compilation, not to subvert ads, but mainly to deal with relatively heavy front-end projects. These heavier front-end projects are extracted from previous static projects, giving them independent project building tools. While the normal page, the static resources inside, still use the original development method.

Finally, we chose Gulp, as for the tools such as gulp, here actually do not want to expand in detail, the article a lot.

However, when choosing the active compilation mode, we are still very concerned about some risks, because in my opinion, can introduce a lot of plug-ins, so that development becomes more flexible, but more uncontrolled.

So we made some preliminary arrangements:

• There is a unified sample project, all of which are derived from this project.

• Only the use of common plug-ins, prohibit the use of some strange (such as JS first merge and then into the HTML plug-in)

• Example project, for different scenarios, encapsulated into a small sub-configuration, if you want to use a function, direct introduction, it is best not to write their own configuration, do not need to write their own configuration.

• Directory specifications, configuration specifications, are documented, according to the specification.

In fact, these things are not too much technical content, did not feel iffy, did feel that those things. The most important thing is to be able to solve the actual problem and then assess the risks that may be involved. Each team may be a little different, so let's see.

Large search vehicle front-end development mode: Passive compilation and active compilation