The official concept

Essentially, WebPack is a static module packaging tool for modern JavaScript applications. When WebPack works with an application, it internally builds a dependency graph that maps to each module required for the project and generates one or more bundles.

Please refer to the official WebPack manual for details.

The difference between loader and plugin

Easy Answers (translation + explanation + Examples)

Loader is used to load files

Such as:

  • Babel loader is used to load advanced JS and turn it into IE supported JS
  • The CSS loader and style loader are used to load the CSS and turn it into a style tag in the page

Plugin, plugin, used to extend the functions of Webpack

  • HtmlWebpackPlugin is used to generate HTML files
  • The MiniCssExtractPlugin is used to combine multiple CSS files into a single CSS file

Complicated answer

From the point of view of function:

  1. Loader:

Loader means to load something.

Webpack itself can only package COMMONJS standard JS files, so files in CSS, images and other formats cannot be packaged, so we need to introduce third-party modules for packaging.

Loader extends Webpack, but it only focuses on the area of transform files, compression, packaging, and language translation.

Loader runs in NodeJS.

Just to pack, just to pack, just to pack, say it three times!!

       

For example, the CSS-loader and style-loader modules are designed to package CSS

The babel-loader and babel-core modules are used to convert ES6 code into ES5

Url-loader and file-loader package images.

       

2. What does plugin do?

Plugin is a function that loader cannot complete.

Plugin is also designed to extend the functionality of WebPack, but plugin works on webPack itself. Besides, Plugin is not only limited to packaging and resource loading, but also has richer functions. It is powerful enough to handle a wide variety of tasks, from packaging optimization and compression to redefining environment variables. Webpack provides many plugins out of the box: CommonChunkPlugin is mainly used to extract third-party libraries and public modules. It is an optimized tool to avoid bundles loaded on the first screen, or bundles loaded on demand that are too large and take too long to load. In multi-page applications, bundles can be created for the application to share code between each page.

Plug-ins can carry parameters, so pass in a new instance in the plugins property.

Such as:

1) HtMl-webpack-plugin for packaging and copying HTML files (and lots more).

Not only complete the HTML file copy, packaging, and HTML automatically added to the introduction of packaged JS file code (), but also can specify the JS file to the bottom of the HTML file and so on.

For specific use, you can see: Webpack (mainly to process HTML files) and start the server

 

From the point of view of running time

 

  1. Loader runs before the package file (loader is a pre-processed file when the module is loaded)
  2. Plugins work throughout the compile cycle.

Why Webpack

To understand why we want to use WebPack, let’s take a look back at how we used JavaScript on the Web before packaging tools came along.

There are two ways to run JavaScript in a browser. The first way is to reference some script for each function. This solution is difficult to scale because loading too many scripts can cause network bottlenecks. The second way is to use a large.js file that contains all the project code, but this can cause problems with scope, file size, readability, and maintainability.

  • Invoked Function Expression (IIFE) – Immediately Invoked Function Expressions

IIFE addresses scope issues for large projects; When script files are encapsulated inside IIFE, you can safely concatenate or combine all files without worrying about scope conflicts.

IIFE is used to produce tools such as Make, Gulp, Grunt, Broccoli or Brunch. These tools, called task executors, splice all the project files together.

However, modifying a file means that the entire file must be rebuilt. Concatenation makes it easy to reuse scripts across files, but it makes it more difficult to optimize the build results. How do YOU tell if the code is actually being used?

Even if you only use one of the functions in LoDash, you must include the entire library in the build result and then compress them together. How does treeshake code depend on? Lazy-loading blocks of code are difficult to implement on a large scale and require a lot of manual work by developers.

  • Thanks to Node.js, JavaScript modules were born

Node.js is a JavaScript runtime that can be used on computers and servers outside of the browser environment. Webpack runs in Node.js.

When Node.js was released, a new era began, and it brought new challenges. Since you’re not running JavaScript in a browser, there are no HTML files or script tags you can add to the browser. So how does a Node.js application load a new chunk of code?

CommonJS came out and introduced the require mechanism, which allows you to load and use a module in the current file. The ability to import every module we need, right out of the box, helps us solve the scope problem.

  • NPM + Node.js + modules – Mass distribution modules

JavaScript has taken over the JavaScript world as a language, a platform, and a way to quickly develop and create fast applications.

But CommonJS doesn’t have browser support. There is no live binding. Circular references have problems. Synchronously executed module resolution loaders are slow. While CommonJS is an excellent solution for Node.js projects, browsers don’t support modules, resulting in packaging tools like Browserify, RequireJS, and SystemJS that allow us to write CommonJS modules that run in browsers.

  • Esm-ecmascript module

The good news from the Web project is that modules are becoming an official feature of the ECMAScript standard. However, browser support is incomplete and versions are not iterated fast enough, and the implementation of the earlier modules above is still recommended.

Traditional task building tools such as the Google-based Closure compiler require you to manually declare all dependencies at the top. However, packaging tools like WebPack automatically build and infer dependent graphs based on what you reference or export. This feature, along with others such as plug-ins and loaders, makes the developer experience better.

  • None of these looks very good…

Can there be a way that not only lets us write modules, but also supports any module format (at least until we get to the ESM) and can handle resources and assets at the same time?

That’s why WebPack exists. It is a tool to package your JavaScript applications (ESM and CommonJS support) that can be extended to support many different assets such as images, Fonts and stylesheets.

Webpack cares about performance and load time; It is always improving or adding new features, such as asynchronously loading chunks and prefetching, to provide the best experience for your project and your users.