Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why should one use a module bundler (webpack) over a task-runner (grunt)? [closed]

In the past I've used a yeoman-generator Grunt for all of my dev tasks. Usually when working on a project I'll use it with compass to compile my scss, and then package and uglify my JS, optimize images, lint my code, and many other useful things.

Recently I've seen a trend towards people to use webpack instead of grunt plugins for many of these tasks. Why is this? What is better about a module bundler in this regard?

like image 338
Chris Pawlukiewicz Avatar asked Sep 21 '15 21:09

Chris Pawlukiewicz


1 Answers

I'm sure others have their reasons, but the biggest reason why I migrated to webpack (more specifically webpack-dev-server), is because it serves your bundle from memory (as opposed to disk), and its watcher will recompile only the files you changed while reusing the rest from cache (in memory). This allows development to be much faster. What I mean is, while I am actively editing code, I can ctrl + s in Sublime Text, by the time I alt + tab to Chrome, it's already done rebuilding. I had a grunt + browserify + grunt-watch setup before, and it took at least 5 seconds to rebuild every time I save (that is after I've made bunch of specialized optimizations in grunt build). That being said, I still integrated webpack with gulp, so I got a task-runner for my project.

EDIT 1: I also want to add that the old grunt + LESS/SASS + browserify + uglify + grunt-watch setup didn't scale well. I was working on a major project from scratch. At first it was fine, but then as the project grew, it got worse every day. Eventually it became incredibly frustrating to wait for grunt to finish building every ctrl + s. It also became apparently that I was waiting for bunch of unchanged files.

Another nice little thing is that webpack allows you to require stylesheets in .js, which establishes coupling of source files in the same module. Originally we established stylesheet dependencies by using import in .less files, but that disconnected source files in the same module and established a separate dependency graph. Again all of these are highly opinionated, and this is just my personal opinion. I'm sure others think differently.

EDIT 2: Alright after some discussions below, let me try to offer a more concise and less opinionated answer. One thing that webpack does really well is that can watch, read, preprocess and update cache and serve with minimal amount of file I/O and processing. Gulp pipe works pretty great, but when it comes to bundling step, it inevitably ends up having to read all of the files from a temp directory including those unchanged. As your project grow, wait time for this step grows as well. On the other hand, webpack-dev-server keeps everything cached in memory, so the amount of wait time during development is kept minimal. However to achieve this kind of memory caching, webpack will need to cover from watch to server, so it will need to know your preprocessing configs. Once you have configured webpack to do just that, you might as well just reuse the same configs for spiting out builds other than dev server. So we ended up in this situation. That being said, exactly what steps you want webpack to do is still up to your personal preferences. For example, I don't do image processing or lint in my dev server. In fact, my lint step is a totally separate target.

like image 156
initialxy Avatar answered Sep 17 '22 17:09

initialxy