Introduction to Webpack (i)--webpack

Today's web sites are evolving into Web applications:
1. More and more JavaScript is used.
2. Modern browsers offer a wider range of interfaces.
3. Full page refreshes are getting smaller and even more code on the same page. (SPA)

So there's a lot of code on the client!
A large code base needs to be well organized. The module system provides the option of dividing the code base into modules.

Modular system Style

There are currently several standard definition dependencies and outputs:
1. Script tag (no module system)
2. CommonJS
3. AMD and some of its variants
4. ES 6
5. Other

Style of the script tag

The following is how you would manage your code without a module system.

<script src= "Module1.js" ></script><script src= "module2.js" ></script><script src= " Librarya.js "></script><script src=" Module3.js "></script>

The module interface is exported to the global object, which is the window object. The interface of the module can access the global object's dependencies
Problems

Global Conflict
heavily dependent on the order of loading
developers must manually resolve module/library dependencies
Large projects, script a slip down can be very long, difficult to manage

CommonJs: Synchronous loading

This style uses a synchronous require method to load a dependency and expose an interface. A module can specify an export export by adding properties to an object or module.exports setting values.

Require ("module"); require (".. /file.js "function= somevalue;

This is the standard used by node. js on the server side.
Advantages :
1. Server-side modules can be reused
2. There are already many modules in this style (NPM). Good Ecological Circle
3. Very simple and easy to use.
Disadvantage
1. Blocking calls do not apply to the network. The network request is asynchronous.
2. There is no parallel loading mechanism.
What's in use?
1. Service-side-node.js
2. browserify
3. Modules-webmake-Compile to a package
4. Wreq-Client

AMD: Asynchronous loading

An asynchronous version (and a method for defining the module and output values) introduced by other module systems (such as browsers) that have difficulty (CommonJS) loading synchronously.

function /*  *  /});d Efine (function(d1, D2)  {return  Someexportedvalue;});

Advantages :
1. The style of an asynchronous request that fits the network
2. Load multiple modules in parallel.
Disadvantage
1. Coding laborious, more difficult to read and write
2. It seems to be just a stopgap.
What's in use?
1. Require.js
2. Curl

ES6 mode

ES6 has added some grammatical structures to JavaScript for reference in other languages, with import syntax.

1 import "jquery"; 2 function Dostuff () {} 3 Module "Localmodule" {}

Advantages :
1. Static analysis is easy.
2. The ES standard will not be obsolete.
Disadvantage
1. Browser support takes time. (a matter of sooner or later)
2. Few modules are used in this style. Eco-Circle
There is no public plan at this time.

Developers should choose the right style for themselves. Allowing existing code and packages to work properly, you can easily add custom module styles.

Transmission

Modules should be executed on the client, so they must be transferred from the server to the browser.
There are two extremes of the transmission module:
1. Preach one by one.
2. Pack all in one pass.

Both uses are rampant, but both are too low.

one by one to preach
Pros: Only the modules that are really needed will be transmitted in the past.
Cons: Many requests mean a lot of overhead.
Disadvantage: The application starts slowly because the request is delayed
all in one pass
Pros: Less overhead and less latency for requests
Cons: Many of the modules that are not needed for the time being are transmitted.

chunked transfer

More flexible transmissions may be better. In most cases the tradeoff between these two extremes is better.
= = When compiling all modules: Cut the module into small pieces (chunks).
This allows for multiple smaller, faster requests. Some modules are not required at the outset, and the blocks containing these modules can be loaded when needed. This speeds up initialization, but still allows you to catch more code when you need to use those modules.

How developers do "segmentation points" can be free to choose according to the situation.
= "A code base is possible yo."

Note: These ideas come from Google GWT.

How could it be just javascript?

Why does a modular system only help program apes solve JavaScript problems? There are many other resources that need to be addressed:
Style sheet
Image
Web Fonts
HTML templates
Wait a minute

Or some pre-compiled and post-compiled languages
Coffeescript→javascript
Elm→javascript
Less style →css style
Jade Template →javascript Generate HTML
i18n files→something
Wait a minute

These things should also be as easy as the following:

Require ("./style.css");

1 require ("./style.less"); 2 require ("./template.jade"); 3 require ("./image.png");

Static analysis

When compiling all of these modules, a static analysis tries to find its own dependencies.
Traditionally this can only find simple things that are not expressed. But
require("./template/" + templateName + ".jade")This is a common structure.
Some libraries are written in a different style. Some of them are strange (magical).

Strategy

Clever parsing allows the existing code to run, and if the program ape uses something weird, it can try to find a compatible solution.

What is Webpack

Webpack is a module wrapper. Webpack Packages the module (s) together with its dependencies to generate static resources that contain these modules.

Why use a different packager?

The existing Module packager is not suitable for large project (large single page application) programs. The urgent need for code segmentation and the seamless modularity of static resources has spawned a new module packager.
I tried to extend the existing Module packager, but it failed to achieve all the goals.
The objectives are as follows:
1. Split the dependency tree into chunks to enable on-demand loading.
2. Keep the initial load time low
3. Each static resource can be a module
4. Ability to set third-party libraries as modules
5. Features that each part of the packager can be customized almost.
6. Suitable for large projects.

What's the difference between webpack? Code segmentation

There are two dependency types in the Webpack dependency tree: Synchronous and asynchronous. The asynchronous module is cut into a new block. After the chunk tree is optimized, files are sent for each chunk.

Loader

Webpack can handle JavaScript itself, but loader is used to convert other resources into JavaScript. Since then, all resources have been formatted as modules.

Intelligent parsing

Webpack has an intelligent parser that can handle almost any third-party library. It even allows you to add expressions like this in your dependencies require("./templates/" + name + ".jade") . It can handle the most common modular standard styles: Commonjs and AMD.

Install node. js

Install node. js
The Package management tool NPM will be installed together.

Webapck

Webpack can be installed with NPM commands.

$ NPM Install Webpack-g

The Webpack has been installed globally and the command is now webpack available.

Using Webpack in Projects

Your project should also have webpack dependencies. This allows you to freely decide which version of Webpack you want to use in your project and which one you will use globally. Webpack.
npmAdd a Package.json file with a command

$ NPM Init

If you do not publish NPM packages, the problems in the INIT process are not important and can be ignored.
Install Webpack and add to Package.json:

$ NPM Install Webpack--save-dev

Version

There are two versions of Webpack available. Stable version and beta version. The beta version is marked in the version character -beta . The beta version may contain weak or experimental functionality, and it has not been tested much. A stable version should be used in a formal scenario.

$ NPM Install [email protected]--save-dev

Development tools

If you want to use development tools, install it first

$ NPM Install Webpack-dev-server--save-dev

Original address: http://blog.csdn.net/keliyxyz/article/details/51571386

Introduction to Webpack (i)--webpack