Various front-end modular specifications

Record some key points so that you can always remember them with evidence to follow!

Looking back on the road to modularization I briefly reviewed my own modularization road before. Because there was too much miscellaneous content, it was only comprehensible, and it was inconvenient to fully understand the modularization of the front-end. ; I have been interviewing some front-end people in the past few days, and I found that except for the experts who came to kill me, most people are relatively unfamiliar with modularity, and have not even heard of what modularity is, so it is a bit embarrassing; look at it now Three popular frameworks in the world: React, Angular(2), and Vue. Their biggest similarities are: modularity and componentization; there are also various front-end construction tools derived from Nodejs: Webpack, Gulp, Systemjs, The basis for using them is also modularity and componentization. If you insist on saying that you don't have modularization or componentization, and the project runs quite happily, and you can use these construction tools, then you can only do it, why bother? It can be seen that modularization is necessary. No matter the size of the project, it must be well understood and applied in practice. On the one hand, it can improve work efficiency and on the other hand, it can improve its front-end level;

As for the benefits of modularization, there are various online I won’t say much about the argument. In addition, what is more important is: forming a tacit understanding among team members on the basis of modularization, forming a private warehouse within the team, unified management, and achieving the goal of calling packages on the back end. The purpose of calling the front-end module is as natural as ever;

Everything comes from CommonJS:

Don’t be afraid of what kind of framework this is and spend time learning it. CommonJS is the modular specification of JS. Due to the historical reasons of JS, it was not modularized at first. After that, JS became the de facto standard on the browser side, and its status became more and more important. The CommonJS specification was proposed to solve this problem, and it was hoped that JS would not only run on the browser side, but everywhere; it feels very awesome Look! Then, Nodejs implemented the CommonJS specification on the server side, thereby pulling JS from the small environment of the browser to the large environment of front-end and back-end communication. The ugly duckling finally turned into a white swan!

According to CommonJS specifications, files are modules. Use require to reference and load modules, exports to define and export modules, and module to identify modules. When using require, you need to read and execute the file, and then return the content exported by exports. Due to the reading of the module Retrieval and execution are synchronous file operations, so CommonJS can only be carried forward by Nodejs on the server side. You can look at the modularization of Nodejs here: Browserify allows your Javascript to travel between the front and back ends; but on the browser side, this synchronous operation does not Not applicable, at least it will be time-consuming and block the running of subsequent code; thus CommonJS derives two major branches on the browser side: AMD (Asynchronous Module Definition) and CMD (Common Module Definition);

AMD (Asynchronous Module Definition) ：

AMD is represented by RequireJS, which defines modules through define(id?, dependencies?, factory), require([dependencies], function(){}) to call modules, and uses the method of asynchronously loading dependent modules in advance. After the loading is completed, the callback function is executed. Here you need to have a good understanding of the asynchronous mechanism of JS. You cannot understand it in terms of execution in a synchronous order. Multiple files are loaded asynchronously in parallel. Which one will be executed first is not something you can predict according to the loading order, but wait. All dependencies are executed, and the results are finally called back;

CMD (Common Module Definition):

CMD is represented by SeaJS, which is slightly different from RequireJS in the way of defining and loading modules. You can also use define(id?, dependencies? , factory) to define modules, but SeaJS uses the nearest dependency method to load modules. Generally, modules are not relied on in dependencies, but are written in a unified way: define(function(require, exports, module){}), which is loaded nearby in the factory. Dependent modules are used by seajs.use([dependencies], function(mod,[mod]){}); it is essentially asynchronous loading of modules, but the timing of loading and execution is different compared with RequireJS;

In comparison, Seajs and Requirejs are both very good front-end modular organization solutions, each with its own merits; Requirejs has to wait until all front-end dependencies are loaded and executed before calling back the main code logic. If you have to say that it is lacking, just It has to be optimized in the front-end dependencies, but it is generally very smooth; Seajs only pre-loads the dependent modules and does not execute them, and uses them nearby when needed. At this time, delays may occur;

About Seajs Simple understanding:

Good Seajs, don’t use it if you don’t need it

Use seajs well!

Tools are very important for productivity:

Although the popular modular specifications on the browser side are AMD and CMD, with the help of tools, we can still simulate CommonJS specifications on the browser side, such as Gulp, Webpack, etc. With the tool, we can still write front-end JS code in the development environment just like writing Nodejs, and the tool is packaged into browser-runnable JS. Similarly, asynchronous calling code blocks are also feasible;

UMD (Universal Module Specification):

Now that JS can be used on the front and back ends, to a large extent a JS module can run on the browser side and the server side at the same time. The UMD solution is the integration of AMD and CommonJS specifications. Cross-platform for JS modularization; like this:

(function(root, factory){
if(typeof define ==='function'&& define.amd){
// AMD
define(['jquery'], factory);
}elseif(typeof exports ==='object'){
// Node, CommonJS之类的
module.exports = factory(require('jquery'));
}else{
// 浏览器全局变量(root 即 window)
root.returnExports = factory(root.jQuery);
}
}(this,function($){
// 方法
function myFunc(){};
// 暴露公共方法
return myFunc;
}));

ES6 modularization:

ES6, as the new JavaScript standard, comes with modular buffs, importing and exporting modules through import and export. The basic idea is similar to CMD and AMD, but with more syntactic sugar. After all, it is native support, of course. It is easier to use and understand; due to the current browser environment, if you want to use it with peace of mind, you still have to use the power of tools to convert;

In short, front-end modularization is a must! We can't be content with the status quo, even if we do a few random things, it will still work; many times, being still is a step back, because there are too many great masters who work harder than us!