The origin of modular packaging tools

Modularity is a great solution to our code organization problems in complex application development, but as we introduce modularity, our applications will have new problems.

The first is that ES Modules, which we use, has some environmental compatibility issues, even though the latest versions of major browsers already support this feature.

However, there is no way to unify the browser usage of all users, so we still need to solve compatibility issues.

The second is through the modular way, divided module files will be more, and our front-end application is running in the browser.

Then every file we need in the application needs to be requested back from the server, and these scattered module files will inevitably lead to frequent requests from the browser, thus affecting the efficiency of our application.

The third point is not actually a problem, should be we in the implementation of JS modular based on a divergence, is that we in the front-end application development process, not only JavaScript code needs to be modular. Because as our applications get more complex, so do our HTML, CSS, and other resource files.

And from a macro perspective, these files can also be viewed as a module in the front-end application, but the type and purpose of these modules is different from our JavaScript.

For the entire development process, the module must be necessary, but we need the original on the basis of introducing better program or tool to solve the above questions or needs, let the developers in the application development phase can continue to enjoy the advantages brought by the modular and don’t have to worry about some of the impact on production environment of modularity.

Then we come up with some ideas for this so-called better solution or tool, and we hope they satisfy our ideas.

First of all, we want a tool that will help us compile our code, that is, we will include new features in our development phase of the code directly into the most compatible code, so that we face the environment compatibility problems do not exist.

The second is the ability to repackage our scattered module files, which eliminates the frequent requests for module files in our browsers.

As for modular file partitioning, we only need it during development because it helps us organize the code better, but it is not necessary for the runtime environment, so we can choose to write it in a modular way during development.

During the production phase we still packaged them into the same file and ended up supporting different types of front-end resource types.

In this way, you can put the front-end development process involved, style, pictures, fonts and so on all resource files as modules to use, that for our whole front-end application, there will be a unified modular scheme.

Because those modularity solutions that we introduced were really just modularity solutions for JavaScript, and now we want to emphasize modularity solutions for the whole front-end application. What about these resources?

We have this modular solution that we can control through code, and we can maintain it in line with our business code, which makes more sense for the whole application.

In front of two requirements we can use know before some of the build system to cooperate with some compile tools can be achieved, but the demand for the last one, we will be hard to solved in this way to pick up, so there will be a next, we introduce a topic, namely the front-end module packaging tools.

  • New feature code compiled

  • Modular JavaScript packaging

  • Supports different types of resource modules

Module packaging tool

There are several tools in the front-end space that address these issues well, and the most popular are Webpack, Parcel, and rollup.

Taking WebPack as an example, some of its core features perfectly meet the requirements described above.

First of all, Webpack, as a Module Bundler, can solve some problems in the packaging of modular javascript codes. Some scattered Module codes can be packaged into the same JS file through Webpack.

For those codes that have environment compatibility problems, we can compile and transform them through module Loader during the packaging process.

Second, WebPack also has the idea of Code Splitting, which means that all the Code in an app should be packaged as we need it.

This way we don’t have to worry about the problem of packing all the code together and creating a larger file.

We can pack together the modules that are necessary for the first run of the application during load and store the others separately. And then when the application works and actually needs a module we load that module asynchronously to do incremental or incremental loading, so that we don’t have to worry about the file being too fragmented or the file being too big, those two extremes.

Finally, webpack allows us to load any type of resource file in javascript in a modular manner. For example, we can import a CSS file directly in Webpack through javascript. These CSS files will eventually work with style tags.

Other types of files can be implemented in a similar way, and this is where WebPack addresses these requirements. Other packaging tools are similar.

In summary, all packaging tools aim at modularity, but by modularity we mean the whole front-end project, which is a bit more macro than js modularity we talked about earlier.

It allows us to enjoy the advantages of modularity in the development phase without worrying about the impact of modularity on the production environment. This is where modular tools come in.