The original article was published at www.rails365.net

1. webpackWhat is?

Let’s start with what Webpack is.

Webpack officially defines it as follows:

webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset.

In Chinese, it basically means:

Webpack can be thought of as a module baler: what it does is analyze the structure of your project, find JavaScript modules and other extended languages (Scss, TypeScript, etc.) that browsers don’t run directly, and convert and package them into an appropriate format for the browser to use.

In plain English, you can say:

Webpack is a front-end modular solution with more emphasis on module packaging. We can treat all resources (images, JS files, CSS files, etc.) in the development as modules, process the resources through loader and plugins, and package them into front-end resources suitable for production environment deployment.

If that doesn’t make sense, let’s talk about the cause and effect.

In today’s society, as web development, will be more and more aware of the importance of front-end, with the development of HTML5, CSS3, ES6 various technologies, front-end development is more and more popular. Even some applications are single page applications (SPA), purely JavaScript development, JavaScript file management is also a problem. Modularized programming in JavaScript has become an urgent need, which has led to the emergence of modular solutions to JavaScript, previously in requireJS or SeaJS, and now in WebPack.

For example, a lot of people have developed great JavaScript modules or components, and we don’t want to reinvent the wheel, but we want to take advantage of other people’s modules, like require or include, and bring in other people’s modules. But JavaScript doesn’t have such a concept as a class or a package, so how do you do that?

How to introduce someone else’s module? When you introduce it, you make sure that the dependencies don’t go wrong. Right? This is the problem that WebPack addresses.

Now that we understand the concept of modularity, what about the word packaging?

In fact, once the modularity problem is solved, WebPack can combine the various resource modules into a single file and export it to the browser. These resources can also be processed during the packaging process, such as compression to reduce the volume, sass to CSS, coffee to JS. So, in some ways, it has the same function as grunt/gulp. The differences with GRunt /gulp are discussed below.

And 2.grunt/gulpThe difference between

Grunt /gulp is defined in Task Runner. It’s kind of like Rake or Thor in Ruby, and if you don’t know Ruby, make in C/CPP, which you should know. Grunt /gulp is a tool for writing tasks, but grunt/gulp uses JavaScript to write tasks.

Grunt /gulp emphasizes the workflow of front-end development. We can configure a series of tasks, define the transactions (such as file compression and merging, Sprite chart, server startup, version control, etc.), and then define the execution order for grunt/gulp to execute these tasks. Thus building the entire front-end development process of the project.

const gulp = require('gulp');
const babel = require('gulp-babel');

// gulp.src specifies the source file, and then passes the contents to the next processing method using the pipe function. Finally, gulp.dest outputs the contents of the processed file.
gulp.task('default', () =>
    gulp.src('src/app.js')
        .pipe(babel({
            presets: ['es2015']
        }))
        .pipe(gulp.dest('dist')));Copy the code

For example, if your engineering module dependencies are simple, you don’t need to bundle JS or various resources, but simply merge and compress, then you don’t need WebPack. Grunt /gulp is sufficient. On the other hand, if you have a large project that uses a lot of libraries in your pages (which can easily happen in SPAs), you can use WebPack because it allows modularized management and some of the grunt/gulp features such as compression and converting Coffeescript to JS.

Gulp can also be used with WebPack. There is a webpack-Stream plugin in Gulp. Let’s have webpack do module dependency work, generate a bundle.js file, and then use gulp to do all the minify, uglify stuff. Then it was discovered that WebPack had a plugins option that could be used to further process the bundle.js generated by the Loader, so someone wrote the corresponding plug-in. So minify/ Uglify, the hash generation work can be transferred to WebPack itself, cannibalizing gulp’s share of the market. In most cases, you don’t need gulp/grunt anymore because it’s just a combination of plugin commands. So a lot of the new projects you see now are package.json with a bunch of scripts written inside, and a webPack is all you need outside. (from https://segmentfault.com/q/1010000008058766)

To sum up:

Both are front-end automated build tools, but their positioning is not equivalent.

Strictly speaking, modularity is not what GRunt/GULp emphasizes. It’s about regulating the front-end development process.

Webpack is even more heavily modularized, and features such as file compression and merging, preprocessing, etc., are just features that come with it.

3. Compare to Browserify

Webpack is better compared to Browserify than grunt/gulp because they are more similar, but Browserify should be replaced by Webpack. I don’t know much about Browserify, so I won’t go into the details here.

Advantage of 4.

  1. Webpack can handle not only JS, but ALSO CSS, HTML, and even images and other front-end resources.

  2. It is easy to develop and can take over some of the grunt/gulp tasks such as packaging, compression obfuscations, and converting images to Base64 with just one configuration file.

  3. Strong expansibility, perfect plug-in mechanism.

5. Why studywebpack

If you want to learn and use some of the most popular technologies like React, Vue, Angular, etc., you can’t help but run into WebPack, because webPack is used to build front-end development environments. So why not?

See more articles: www.rails365.net