Writing in the front
When I wrote the Node Starter series, I predicted that there would be another WebPack series, because webPack construction is inseparable from Node.js support. If you only learn WebPack, you will definitely encounter node.js related knowledge. As of this writing, the node.js series is now in its fifth installment, and I’ve got all the links for you to post below. If you haven’t read node.js articles, it’s recommended to read the Node.js series first. The language is easy to read and the feedback is that even beginners can understand it. It also expands your knowledge in ways you wouldn’t normally expect. Articles of interest can also be viewed through my home page:
Click here to skip to the chapters to read: Node.js Introduction Series (1) Features, application scenarios, front-end pain points solved problems Node.js introduction series (2) modules, REPL Node.js introduction series (3) development and debugging, global built-in functions and variables Node.js introduction series (4) Event handling mechanism and event loop mechanism
By the way, this is the right time to launch the WebPack series because I’m about to publish node.js 6, which will cover NPM and how to manage split modules, so it’s the right time to launch the WebPack series.
The introduction
After several years of explosive development of the front end, it is not only required to be able to do simple cutting with the back end to complete the development, but also because of this, the front end development engineer can take off the hat of “cutting” and play the same important role in the development field as the back end. In the process of front-end development, the following phenomena appear: 1) Front-end projects are large-scale, with complex functions and high maintenance and iteration costs.
2) Low efficiency of team collaboration, mutual influence, high coupling and even code conflict in cooperative development.
3) The turnover of staff within the team makes it very painful for new staff to maintain the old project; The different abilities and habits of the developers within the team lead to different code quality and maintenance difficulties.
All of these problems can be solved by a concept called modularity.
Modularity itself is a concept that does not provide any specific solutions, and there are many excellent implementations of this concept, including rollup, Parcel, Webpack, etc.
The one to be introduced is Webpack. What is Webpack? What can it do? Why is it better than other modular tools? What are its disadvantages? These questions will be addressed in detail in this section.
1. What is Webpack?
Webpack is a concrete implementation scheme of front-end modularization development, which builds and packages projects through its internal loader mechanism and plug-in mechanism, and finally achieves the purpose of code modularization.
2. What is modularity? How did it develop?
Modularization refers to: a complete function, separate into a number of independent functional blocks, these blocks through combination, the ultimate realization of the overall function of the idea, known as modularization. The first stage: file splitting: The early modularization refers to putting each independent function in different files independently by splitting different files, and then introducing it into the page through script label. A Script label represents a module. Its disadvantages are: 1) the module works globally, which can easily cause global member naming conflicts; 2) Without a private workspace, exposed objects can be easily modified; 3) Unable to manage the relationship between modules. The second stage: namespace type: on the basis of file splitting type, it is stipulated that each module can only expose one object, and the exposed object should be mounted to the global Window object. It solves the problem of naming conflict, but other problems still exist. Stage 3: IIFE, execute function immediately: Members of each module are placed in an immediate execution function, in this way, the immediate execution function for module provides a private space, the need to be exposed to the global members, can be mounted to the global object means to achieve, and yet, this way can pass parameters indicate the module internal dependence, in the form of modules, This approach solves the problems of global scope contamination, scope conflicts, and module dependencies. A good example of this approach is the JQuery source code package. If you are interested, try reading the JQuery source code. In conclusion, the above three ways, although finally solved the problem of the module organization and management, but did not solve the problem of module is loaded, it will cause, module redundancy or module is missing, all modules are introduced through scripts to global, not to manage module loading mechanism, and the above three ways, there is no a unified standard, The implementation varies from person to person, so a unified module specification is needed to achieve a library that automatically loads modules on demand and to maintain a consistent development style.
3. What are the module specifications?
CommonJS: it is the module specification of Node.js, which states that a file is a module, and each module has its own scope. Modules export members through module.exports, and import members through require.
Scheme if placed in the browser to use this module, can appear some problems, the reason: node. Js, the module is synchronized loaded at startup, corresponding call only at run time, the browser if you use this way, there will be a large number of modules during the initial request, to reduce the execution efficiency, the loading waiting time is too long.
As a result, the early front-end module specification did not directly choose commonJS as the front-end module specification. Instead, it used something called the Asynchronous Module Definition Specification, or AMD.
2) requireJS is one of the implementation schemes of AMD module specification. In addition to implementing AMD specification itself, requireJS is also a powerful module loader. AMD rules, through the define function to define a module, the function receives two parameters, the first parameter is an array, according to the module need to rely on other modules of the path, the second parameter is a function that is equivalent to the immediate execution function, its role is to provide the modules of a private scope, from inside the function, If you want to expose a global object, just return it.
3) At the same time that require.js implements AMD specification, Taobao launched another way of front-end modularization, called CMD, which is realized by Sea-.js. Its use method is basically similar to require.js, which can be regarded as a duplicate wheel, but CMD is only popular in China. CMD is also require.js compatible.
4) With the development of the front end, the specification is becoming more and more perfect. At present, the recommended solution of the front end is to use the require.js module specification in Node.js, and use ESModules specification in the browser side. For the front end, ESModules is still the most important AMD implementation and should be mastered. ESModules is a module system defined by ES2015 (ES6). Due to the popularity of a series of packaging tools, such as WebPack, it has gradually become popular. At present, it has become the mainstream front-end modular standard.
summary
Front-end modular standards go through three stages: AMD –> CMD –> ESModules
4. What are the problems with modularity?
1) There is no guarantee that all browsers are compatible with modular standards; 2) Too many dependent modules and too fine division will lead to sending multiple requests to the server for module resources, resulting in low efficiency; 3) Front-end not only JS needs to be modular, other CSS, HTML, image resources need to be modular.
So how do you solve the problem of using modularity and achieving modularity for all resources? To solve the above problems, modular packaging tools were born. Modular packaging tools need to be able to solve the following problems:
1) Code compilation ability: able to convert the code written with new features in the development stage into the code compatible with most browsers, so as to solve the compatibility problem of browser environment; 2) It needs him to be able to package scattered modules back together again, so as to solve the problem of multiple requests for module resources (because modularization actually only requires us to manage the project structure in the development stage, and it doesn’t really have much effect online); 3) It needs him to be able to package different types of files modularized, including pictures, CSS, fonts, etc. If you only need to solve problems 1) and 2), you can use gulp to build the system and compile plug-ins accordingly. But for the third point, other tools are hard to solve, so a powerful packaging tool, WebPack, has emerged.
summary
Ok, so far you know: 1) Why is the front end modular? 2) The development history of front-end modularization? 3) Why do you choose Webpack as a modular tool?
In the next few articles, I’ll intersperse with updates to the Node.js series and the Webpack series, with the goal of combining server-side and front-end comparisons. Stay tuned.
At the end of the article
This article is the first in a series of webpack updates.
Good article, need your support, so please first like, and then orderly exit, comments section front sofa welcome communication.