Front-End JS file merge three ways to recommend the basic knowledge

Recently thinking about how to merge the front-end JS file, of course, does not include the file can not be merged, but we can merge the file, think about should also have only three ways.

Three ways are as follows:

1. A large file, all JS merged into a large file, all pages are referenced to it.

2. Various pages of large files, their respective pages merged to generate their own required JS large files.

3. Merge a large number of common files, according to the practice of merging a number of common JS files, each page refers to a large number of common files.

In my opinion, the merger has two purposes:

1. In order to reduce the number of requests.

2. Code security Considerations (the more files are divided, the easier it is for people to see them).

PS: Note that I am not talking about compression confusion, but merging

1. A large document

This way is that no matter 3,721, all JS merged into a large file, all pages are referenced to it, even if some of the code may not be used.

Advantages:

(1). The combination is simple and easy to use.

(2). Other pages can be loaded with cache optimizations.

Disadvantages:

(1). Pages may be loaded into code that is not used on this page.

Scenario Not applicable:

(1). This approach certainly does not apply to large Web applications, and the complexity of the business does not allow us to do so, regardless of the amount of single file code (I've never seen that site do this).

Applicable scenario:

(1). Hybrid applications, whether mobile hybrid applications, or PC hybrid applications (desktop applications, similar to a team development framework Hex+chromium +nodejs), are very suitable, there will be no request speed problem, The code security of this application in client code is more important.

PS: Of course, the most important is the security of the back end, regardless of whether the front-end is cracked, the back end is to improve the input check, whether to prevent ultra vires, the back end is the key, that is often said a word "do not believe the user's any input."

2. Each page big file

Each page merged to generate their own required JS large file, generate a number of JS merge.

Advantages:

(1). Each page uses the most accurate JS, does not have the irrelevant code.

Disadvantages:

(1). How many pages, will generate a number of JS, resulting in a large number of common JS code redundancy.

(2). The shared part cannot be loaded with cache optimization.

(3). Consolidation and use can be relatively complex.

This way I always feel wrong, small application directly a large file to fix, and the big application will not do so, but also can not be used in hybrid applications, in such a meticulous installation package size situation, can not tolerate redundant code. When I think about all kinds of scenes, I find that they can be solved in the above or below, and it is better, so I think this way is a chicken.

3. Merging multiple shared large files

Merge multiple shared large files (such as dependent library classification) according to practice, and then merge the JS files required for this page (for example, by business classification), each page refers to one or more common large files and the JS file of this page.

Advantages:

(1). The shared parts are optimized for loading, and each page is referenced as much as possible without redundancy.

Disadvantages:

(1). More or less there will be some pages will be referenced to the unwanted code, sharing is not completely shared.

Applicable scenario:

(1). Large and small applications are more applicable, each page may have many shared parts, a reasonable combination of documents will be very critical.

Summarize

This paper is only a reflection, but also a general discussion. A lot of file merging methods, from the back-end dynamic generation or tools directly generated (GRUNT+REQUIREJS), the combination of more than three kinds of way, also depends on our practical needs.

Merging is important, but not advocating that all files are merged, that they cannot be merged, that some individual files are better, or that they need to be seen in a specific scenario.

The above front-end JS file combination of three ways to recommend is small to share all the content of everyone, hope to give you a reference, but also hope that we support the cloud habitat community.