My FeedDiscussionsHeadless CMS
New
Sign in
Log inSign up
Learn more about Hashnode Headless CMSHashnode Headless CMS
Collaborate seamlessly with Hashnode Headless CMS for Enterprise.
Upgrade ✨Learn more
Stop using Webpack for building projects

Stop using Webpack for building projects

Yanni Nightingale's photo
Yanni Nightingale
·Aug 23, 2016

Webpack is an amazing tool, for bundling, not for building.

Issues

Nowadays, I heard that more and more developers using Webpack to build their web front-end projects. That sounds comprehensible and reasonable: npm, not bower, is becoming the most important ecosystem for JavaScript language, especially ES2015 which has an official modular system.

However, I have to say that some building steps seem quite weird within. Using css-loader to inject css codes into JavaScript, and that creates a style element dynamically. Apparently that will affect performance during runtime. I cannot believe why this repo could have 1000+ stars. Are there so many lazy developers? I just can’t stand this performance loss. Beyond that, import “com.css” is so antipathetic in JavaScript.

Analogously, somebody uses plugins to copy files, or something else has nothing to do with “bundling”.

Indeed, Webpack plugins have ability to do a lot of stuff. But, Webpack is still a module bundler, which bundles JavaScript modules together. That’s why it is created, and that’s what it is indeed good at.

You cannot predict how complicated your project will transform to be. If you already have used Webpack to do all the works of your project building, in a way your project is kind of a little simple. Someday, the requirements may be changed, then you have to update your building process, that may be deadly fatal if your building architecture is not flexible enough.

Webpack cannot illustrate the steps of project-building quite well. Actually, it does not build, but bundle, so it needs an entry file, that should be a JavaScript. Webpack looks up all the recursive dependencies, passes them through a chain of “loaders”. Plugins add more steps, but mainly for bundle. Handling other resources is implemented indirectly, “options” for instance.

Building other kinds of resources could be very complicated too, their steps are as same important as bundling JavaScript modules:

  1. Images minify;
  2. Less/css compile, link images, minify;
  3. HTML link JavaScript/css and images;
  4. Others just copy

Also, your JavaScript modules may run on Node.js in an isomorphic project, which means a copy should not be bundled, but copied, and compiled to ES5 if necessary.

My options

Building a project is a complex work, you may solve it with Webpack, but that’s not the best way. Webpack has many limitations, and won’t be suitable to all requirements.

Of course, if you’re building a library, Webpack would be a good choice.

The best practice is treating Webpack as a plugin of a real building tool like Grunt or Gulp. They are both good at processing multiple kinds of files. I suggest Gulp because it’s faster and controls building flow much easier.

Using Webpack with Gulp is quite easy: gulp-webpack is Gulp plugin.

See? Just like a normal Gulp plugin like babel, less, uglify and so on.

Remember, only use Webpack to bundle, use Gulp or any other tool you love to build, because this is important and sustainable:

Each performs its own functions.

So, what do you think?