The javascript architecture of the most common websites may be as follows:
- An underlying framework file, such as jquery
- A website business framework file, including the whole site public business module class (such as pop-up box, Ajax encapsulation, etc)
- Multiple business files, including services related to each specific pageCode
To reduce an HTTP request, we may combine the underlying framework file and the website service framework file combo into a file and introduce it as a public file to every page that requires JavaScript, introduce the business JS files related to the current page on the specific page. To reduce page loading script blocking, we can also place the script file at the bottom of the html body for loading.
This seems to be a good JavaScript architecture solution. Each page can reference a maximum of two JS files. After you open the home page, you can use the cached combo JS on subsequent pages. If the underlying framework is not frequently modified, the combo framework files cached in the user's browser can be used for a long time.
After using the website for a while, you may find some problems.
- The framework file used by combo is too large. Although you can use a third-party compression tool such as Yui compressor or Google clousure to compress, enable gzip, and use CDN to optimize it. However, the underlying framework will upgrade with the open-source framework and increase the number of public modules. As a result, the Framework files after combo become larger and larger.
- The service framework changes frequently, which reduces the browser cache effect. As the business grows, more and more public business modules may cause frequent modifications to the business framework. After the code is modified, the browser needs to reload the new framework file.
- Team development issues. As the number of teams increases, each person may develop a public business module, resulting in many people who need to modify the same file. If TFs is used as an exclusive version management tool, it will affect the development efficiency of the team.
Let's take a look at the Javascript architecture of websites that use the module loader and modularize javascript:
- A module loader file. For example, loader. js
- Multiple underlying modules (such as selector and UA) and multiple business modules (such as dialog and suggest)
- Multiple page-related script call files
Advantages:
- Load as needed: only the modules and files required for the current page are loaded, without any additional files and code. Greatly reduced the amount of code
- Parallel loading: Many loaders provide the ability to load multiple files in parallel, which reduces the time for code loading and achieves separation of download and execution.
- Conducive to team development: each person in the team is responsible for developing their respective modules without affecting each other.
- Maximum use of cache: After the module is granular, each update may be only one small module, and other unupdated ones can use the cache in the browser.
Since Javascript is modularized and the use of the module loader has so many advantages, what efforts should we make:
- Select or implement Loader
- Modularization of the underlying framework: We need to divide the underlying framework into different modules according to their respective modules to clearly differentiate the dependencies between them.
- Implement business module: modify the original business module according to the code method agreed by loader, and write the new business module as loader.
