The so-called front-end development is the front desk, which commonly includes several ends: PC, pad, mobile phone, and other smart devices. The place where you can run the browser is the paradise of our front end. With the advent of Node, it’s now possible to expand beyond just browsing to the server side, the background. This brings JavaScript to the next level with the ability to do everything from the front to the back, but of course you need traditional background languages like Java to do things that are too low-level. With the improvement of the performance configuration, network bandwidth and technology of smart devices such as computers and mobile phones, we can make web pages more cool, more complex, more humanized and will not be stuck. But go down like this, a large number of JS script code slightly show its bad management maintenance and team development, some miscellaneous army feeling. So modular development came into being.

How did ES5 and its predecessors achieve modularity

With RequireJS:

When it comes to modularity, CommonJS and AMD are often mentioned. What are these two main things, remember is modular standard specification. RequireJS is the best implementation of the AMD specification. The relationship between ECMAScript and JavaScript is that the former is a specification of the latter and the latter is an implementation of the former. The only thing we need to know is that the API implementing the CommonJS specification loads modules synchronously, while the API implementing the AMD specification loads modules asynchronously. Asynchronous loading means non-blocking loading, which is more suitable for the browser side. The official documentation describes RequireJS as follows:

RequireJS is a JavaScript module loader. It is ideal for use in browsers, but it can also be used in other scripting environments, such as Rhino and Node. Using RequireJS to load modular scripts improves the speed and quality of your code.

RequireJS advantages:

  1. Asynchronous “load”. As we know, websites often put script scripts at the end of their HTML to avoid blocking the page when browsers execute JS. With RequireJS, the callback function is executed asynchronously after the relevant JS is loaded, so it does not block the page.

  2. Load on demand. With RequireJS, you can load the js module when you need to load the JS logic. This way, you can avoid a lot of requests and data transfers during the initialization of the web page. Some modules may not be necessary for some people.

  3. More convenient module dependency management. You’ve probably encountered dependency errors due to script tag order, this function undefined, that variable undefine, etc. With RequireJS, you can ensure that all dependencies are loaded before executing them, so dependency management works.

  4. More efficient version management. Think about it, if you import a Jquery 2.x file using script import, and you have 200 pages that reference it, then when you want to switch to Jquery 3.x, you have to change those 200 pages. However, if your requireJS does jQuery path mapping in config, you only need to change one place.

Use RequireJS

With RequireJS, all you need to do is import require.js. All you need to do on your page is introduce this single JS with the \
\>

The whole RequireJS2000 to line of source code, exposed for our use of just a few, mainly import modules, define modules. (requirejs,require,define), where: requirejs and require are the same as jQuery and $. Said here: the front end of the people must understand.

How is ES6 modular

With a built-in implementation:

Es6 supports modularity natively, using import to import modules and export to export modules. These two words have been as a reserved word, now give it due identity appeared, rich JS language functions. The traditional module model is based on closures that return a “public API.” This “public API” comes with methods that have closures for internal variables and functions. It is often expressed as follows:

The greetingFN module defines a layer of parent functions

function myName(name) {

// Parent function myName

function greetingfn() {

// The subfunction greetingfn

console.log( “myName ” + name + “!” );

}

// Public API– returns a pointer to the method wrapped in the parent function.

return {

greetingfn: greeting

};

}

Use:

var me = myName( “macrolam” );

The use of the export

The export keyword is either placed in front of a variable or function declaration, or exported as an object, as follows:

export function fn() {

// Export the function

}

export var num = 42;

// Export variables

Var arr = [1, 2, 3];

export { arr };

Use the import

To import a module, you will, unsurprisingly, use import statements. Just as export has several subtle variations, so does import, so you’ll have to spend a fair amount of time thinking about the following and experimenting with your options.

If you want to import a specific named member of a module’s API into your top-level scope, use this syntax:

import { foo, bar, baz } from “foo”;

The listed identifiers foo, bar, and baz must match the named export on the module’s API (where static analysis and error assertions will occur). They are bound as top-level identifiers in your current scope.

import { foo } from “foo”;

foo();

You can rename the imported binding identifier as follows:

import { foo as theFooFunc } from “foo”;

theFooFunc();