Thoughts on the front-end project of Baidu Zhang Yunlong Reading

Small title: I just write the front end of less than half a year, learning faster, can also be said to be more impetuous, recently in the study node, want to own the whole stack of work, accidentally saw an article called the front-end architecture Those things, so follow the article, I found Mr. Zhang Yunlong git, looked at his view of the front-end architecture, Think deeply of feeling, so write down to tell yourself how superficial.

Mr. Zhang Yunlong to transduction Aberdeen introduced, however I do not how can cut diagram, can say I am very amateur front-end designer, I will only knock the code, take the page, write animation, can say I cleverly avoided the man said people on the front view, think, "lucky"!

"Front end, is a GUI software", "essentially, all Web applications are software that runs in a Web browser, the graphical user interface (graphical user Interface, or GUI) is the front end," says Mr. Zhang Yunlong. I think we all would think so. Now the front-end, has been able to handle the data, to meet the needs of many customers (of course, no backstage is not possible), such as an independent application presented in front of the customer, the demand is growing, more and more, therefore, the development of the front-end logic and framework has become the front end can not just two people to build a platform So how does Mr Zhang Yunlong think the front-end project is divided?

The front-end project is divided into three stages: library/frame selection, simple construction optimization, JS/CSS Modular development, enhance multi-person cooperative development efficiency and performance optimization.

First stage: library/Frame Selection

The first task of front-end engineering construction is to select the technology according to the project characteristics.

Phase II: Simple build optimization

The front-end project to the second stage will choose a build tool, the code compression, validation, and then the page for a simple resource consolidation.

Phase III: Modular Development of JS/CSS (division)

Divide and conquer is an important idea in software engineering, and it is the cornerstone of the development and maintenance of complex systems, which is also applicable in front-end development. After solving the efficiency problem of basic development efficiency, the front-end team began to think about maintenance efficiency, modularization is the most popular method of division and treatment at the front end. JS Modular Scheme Many, AMD/COMMONJS/UMD/ES6 module, and so on, the corresponding framework and tools are a lot of, say it is annoying, we self-Baidu bar, CSS Modular development is basically in less, sass, stylus and other pre-processor import/ Implemented with the support of the Mixin feature.

Phase IV: Modular Development and resource management

Front end is a kind of software development field with less technical problems and more engineering problems.

When we want to develop a complete Web application, the front end will face more engineering problems, such as:

• Gross Volume: Multi-function, multi-page, multi-state, multi-system;
• Large-scale: multi-person or even multi-team cooperation development;
• High performance: CDN deployment, Cache control, file fingerprinting, cache reuse, request merging, on-demand loading, synchronous/asynchronous loading, mobile top-screen CSS inline, HTTP 2.0 server-side resource push.

What to do in phase four:

First thing: Modular development

Divide and conquer is indeed a very important method of engineering optimization. In my opinion, as a GUI software, the js/css of the light is not enough, and there is an equally pressing need for the division of the UI components:

For example, this is what I believe the front-end component development concept, simple interpretation:

1. Each independent visual/interactive area on the page is considered to be a component;
2. each component corresponds to a project directory , and the various resources required by the component are maintained near this directory;
3. Because the component is independent, the component can be freely combined with the component;
4. A page is simply a container of components, which is responsible for forming a fully functional interface;
5. You can delete/replace the entire directory when you do not need a component, or if you want to replace the component.

The second description of the nearest maintenance principle, I think the most engineering value of the place, it for the front-end development provides a good division strategy, each developer will know clearly, their own development and maintenance of the functional unit, its code must exist in the corresponding component directory, In that directory can find all the internal logic about this function unit, style, JS, or page structure, are there.

Component development has high versatility, whether it is a single page application for front-end rendering or a multi-page application for back-end template rendering, the concept of component development can be applied. The component HTML section can be a static HTML file, either a front-end template or a back-end template, depending on the business selection.

Based on this engineering concept, it is easy to divide the system into separate components as units:

Because the system functions are divided into separate modules or components, granularity is fine, the organization forms loosely, the developer will not have the dependence of development timing, greatly improve the parallel development efficiency, theoretically allow to join the new member claim component development or maintenance work at any time, it is easier to support multiple teams to jointly maintain a large site development.

In combination with the previously mentioned modular development, the entire front-end project can be divided into several development concepts:

name	Description	Example
JS Module	Independent Algorithms and data units	Browser environment detection (detect), network request (AJAX), application Configuration (config), Dom manipulation (DOM), tool function (Utils), and JS unit in the component
CSS Module	Independent Functional Style Unit	Grid system (GRID), font icons (icon-fonts), animated styles (animate), and CSS elements in components
UI components	Independent visual/Interactive function unit	Header (header), footer (footer), navigation bar (NAV), search box
Page	The interface state of this GUI software is the container of the UI component	Home (index), list page, user management
Application	The entire project or entire site is called an application, consisting of multiple pages

The above 5 development concepts form the basic engineering structure of front-end development with relatively few rules, and based on these concepts, the front-end development in my eyes looks like this:

Combined with the above description, for the general small and medium-sized projects, can roughly plan out such a source directory structure:

If your project is large and involves multiple team collaboration, you can also organize pages with related business functions to form a subsystem that further splits the entire site into multiple subsystems to be assigned to different team maintenance.

Second thing: "smart" static resource management

The modular/component development mentioned above only describes a development concept and can also be considered a development specification, and if you recognize the specification and resonate with its division strategy, then we can continue to talk about its implementation.

Obviously, after modularization/component development, the final solution is the technical problem of module/component loading. However, front-end and client GUI software is very different: the front-end application does not have the installation process, the required program resources are deployed on the remote server, the user uses the browser to access different pages to load different resources, with the increase of page access, the entire program is progressively downloaded to run locally, "incremental download" Is the fundamental reason that the front-end works differently from the client GUI software.

Show a wide range of features rich application, if the adoption of web implementation, believe that is not small volume, if the user first visit the page to force its loading of static resources to display the full station, I believe there will be many users lost because of the loss of patience. According to the "increment" principle, we should carefully plan the resource loading strategy of each page, so that users can load the required resources of the page on demand regardless of which page they access, no need to load, no access to the cache reuse, and finally bring a smooth application experience.

This is where the "no Install" charm of web apps is.

The front-end optimization technique, which is derived from the "increment" principle, is almost the core of performance optimization, such as load-related load-on-demand, deferred loading, preloading, request merging, and other schemes such as cache-related browser cache utilization, cache update, cache sharing, non-overlay publishing, and so on. Complex Bigrender, Bigpipe, Quickling, Pagecache and other technologies. These optimizations are all about how to maximize the incremental principle.

So I think:

Believe that this implementation will not change over time, in the foreseeable future, whether in the http1.x or HTTP2.0 era, whether in the ES5 or Es6/7 era, either AMD/COMMONJS/UMD or ES6 module era, regardless of the end of the technology changes , we all have a good enough reason to do the incremental loading of the front-end program resources.

As mentioned earlier, what is missing from the third-stage front-end project? I think it is the lack of such an "intelligent" resource-loading scheme in its infrastructure. Without such a solution, it is difficult to develop the front-end application to the stage IV, it is difficult to achieve the kind of component development program described above, it is difficult for multi-party cooperation to complete a large-scale application development, and ensure that its final performance is good. In the fourth phase, we need powerful engineering tools to manage the "toy-like" front-end development.

In my mind, Facebook was one of the great pioneers in this area, and as early as the Velocity China Conference in 2010, Dr. David Wei, from Facebook, showcased their stunning static web resource management and optimization techniques to the industry.

Dr. David Wei mentioned some of the product data about Facebook at the meeting of the Year:

• Facebook has 10000+ static resources throughout the site;
• Each static resource is likely to be translated into more than 100 language versions;
• Each resource will generate 3 different versions for the browser;
• To do 5 different packaging methods for users of different bandwidth;
• There are 3, 4 different user groups, for small batches to experience the new product features;
• Also consider different delivery methods, can be delivered directly, or through the way of the IFRAME to improve the speed of parallel loading of resources;
• Compressed and uncompressed state of static resources switchable for debugging and locating line problems

This is a state explosion problem, multiply all the states, the entire site of the resource mix will reach millions of (after the weight of the statistics about 3 million ways). The underlying architecture that supports the operation of such a large front-end project is the static Resource Management system, which Dr. Wei shared in that speech. To solve 3D problems with front-end engineering (development,deployment,debugging) on Facebook projects.

static resource Management system = Resource Table + Resource loading framework

Resource table is a data file (such as JSON), is the project of all static resources (mainly JS and CSS) building information records, through the building tools to scan the project source code generation, is a K-V structure of data, with each resource ID key, records the category of resources, deployment path, dependencies, Package Merge and other content, such as:

{ "a.js" : { "url" : "/static/js/a.5f100fa.js" , "dep" : [ "b.js" , "a.css" ]    }, "a.css" : { "url" : "/static/css/a.63cf374.css" , "dep" : [ "button.css" ]    }, "b.js" : { "url" : "/static/js/b.97193bf.js" }, "button.css" : { "url" : "/static/css/button.de33108.js" }}
The resource-loading framework provides some resource-referenced APIs that allow developers to reference resources based on their IDs, instead of static script/link tags to collect, de-reload, and load resources on demand. When these interfaces are called, the framework looks up the information of a resource by looking up a table and recursively finds information about its dependent resources, and then we can implement various performance optimization algorithms in this process to "intelligently" load resources.
Depending on the business scenario, the loading framework can be implemented in the browser with JS, or it can be implemented in the backend template engine using a service-side language, or even a combination of the two.

This design is quickly proven to be flexible enough to perfectly support performance optimization requirements under different technical specifications for different teams, as previously mentioned on-demand loading, deferred loading, preloading, request merging, file fingerprinting, CDN deployment, Bigpipe, quickling, Bigrender, The first-screen CSS embedded, HTTP 2.0 server-side push, and so on performance optimization can be easily implemented in this architecture, and even can be automatically optimized according to the Performance log (Facebook has implemented).

Because of the resource table, we can control the load of resources conveniently, calculate the resource usage of the page at runtime by various means, and get the best load performance. This is true for both single-page applications with front-end rendering and multi-page applications for back-end rendering.

In addition, it subtly constrains the responsibility of building tools-generating only resource tables. Resource table is a very common data structure, no matter what business scenario, its business code can eventually be scanned into the same structure of the table data, and tag the dependencies between the resources, after the table we only need to customize the different business scenarios according to different resource loading framework on the line, and then thoroughly farewell to a team to maintain a set of tools of the era!

Due to congenital defects, front-end compared to other software development, the infrastructure of the more urgent need for component development and resource management , and the solution of resource management is not really complex:

A common Resource table generation tool + table-based resource loading framework

In recent years, you've heard all kinds of resource loading optimization strategies can be implemented on such a basis, and this optimization is completely transparent to the business and does not require reconfiguration of performance optimization-is that what we have been expecting? As Dr. Wei says: "We can bring good people together to optimize loading."

How to choose the technology, how to customize the specification, how to divide the system, how to optimize performance, how to load the resources, when you start from transduction to think about these issues, I want to say:

Hello, engineer!

Thoughts on the front-end project of Baidu Zhang Yunlong Reading