
Keep Webpack Fast: A Field Guide for Better Build Performance - firloop
https://slack.engineering/keep-webpack-fast-a-field-guide-for-better-build-performance-f56a5995e8f1
======
shawn
If anyone is tired of Webpack configuration issues / slow performance, give
Parcel a try:

[https://parceljs.org/](https://parceljs.org/)

The project is less than two months old, so Parcel might not be a good fit for
you. But if it is, it's usually a drop-in replacement. Zero configuration.
Just run it and go.

We're working hard to add the most requested features: source map support is
coming very soon, for example. But if you can put up with a few rough edges,
Parcel promises to give you a ~5x performance increase over webpack.

(We kick off multiple processes to do the actual bundling work, and we have an
asset cache, which accounts for most of the speedups.)

If you'd like to participate or have any questions, hop on our Slack!
[https://slack.parceljs.org/](https://slack.parceljs.org/) We have about 500
devs ready to help you out and chat with you (about anything, really).

Feel free to snag an issue and start working on it:
[https://github.com/parcel-
bundler/parcel/issues?utf8=%E2%9C%...](https://github.com/parcel-
bundler/parcel/issues?utf8=%E2%9C%93&q=is%3Aissue+sort%3Aupdated-desc+)
There's plenty of work to go around.

It's been really cool to see so many people pitching in. We recently had a
Japanese contributor help get Parcel up and running for multi-language
projects:
[https://qiita.com/zacky1972/items/0ce05454b67506edc634](https://qiita.com/zacky1972/items/0ce05454b67506edc634)

~~~
PudgePacket
Maybe a naive question but did you consider writing it in language that is
typically faster (C++/Go/Rust)? I understand the many benefits of it being
written in JS but there is an inherent maximum level of performance that JS
can achieve in certain workloads.

~~~
fenomas
My naive answer, but I'd think that the heavy lifting for bundlers like this
lies mostly in the external packages that parse and modify the code (Babel,
uglify, postcss, etc). The core work of the bundler to wrangle which
dependencies to pass to those external libraries probably isn't a performance
bottleneck, surely?

~~~
ioquatix
In my experience you are not wrong. Resolving a build graph can be done
efficiently. The main cost is typically the tools invoked to satisfy build
targets. However, if the build graph does unnecessary work, it can slow the
build down by a large amount, e.g. compiling files which were already
compiled. In. a large project, it might be the difference between a 10 second
build and a 10 minute build for example.

------
acemarke
Excellent summary of some of the techniques you can use to speed up Webpack
builds. It'll be interesting to see how the ongoing work on performance in
Webpack 4 relates to this [0] [1], and I'd guess that the just-announced
Rust->WASM sourcemap lib work [2] will help too.

If anyone's looking for more info on this topic, my React/Redux links list has
a large section of additional posts on improving Webpack build perf, code
splitting, bundle size optimization, and other related techniques [3].

[0]
[https://github.com/webpack/webpack/issues/6244](https://github.com/webpack/webpack/issues/6244)

[1]
[https://twitter.com/TheLarkInn/status/945486181575340032](https://twitter.com/TheLarkInn/status/945486181575340032)

[2]
[https://twitter.com/TheLarkInn/status/954053251854344192](https://twitter.com/TheLarkInn/status/954053251854344192)

[3] [https://github.com/markerikson/react-redux-
links/blob/master...](https://github.com/markerikson/react-redux-
links/blob/master/webpack-advanced-techniques.md)

------
Game_Ender
Can anyone explain how someone can make a build system and not make
correctness and speed the top priorities from the start? Once you do that
parallelism is third feature you implement, the first being running an action,
and the second being a hash based dependency graph of those actions inputs &
outputs. Once you have that dependency graph parallelism and caching just
appear pretty much for free.

It looks like google uses bazel (a parallel dependency graph based build)
internally and they have 1-2 second rebuild times on apps much larger then
Slack [0].

0 - [https://medium.com/@Jakeherringbone/what-angular-is-doing-
wi...](https://medium.com/@Jakeherringbone/what-angular-is-doing-with-bazel-
and-closure-21f526f64a34)

~~~
swsieber
See also, pants and buck.

I think it's a story of PostgreSQL vs Mongo - do you start out with
conservative correctness and slowly expand your feature set, or do you
advertise a lot of (poorly imolemented) features, and with the large userbase
slowly increase your quality.

------
jamesmcintyre
From someone who has experienced the dev flow on apps with very large, gnarly
webpack configs 17 seconds is extremely impressive and sounds like heaven!

What a lot of devs may not be aware of, if their projects aren't of a certain
scale & complexity (support for legacy code/library-choices/extreme-
modularity/etc.) is that the magical nearly-instant hot-module reloading you
experience with a clean, "normal" project should not be taken for granted
because webpack builds/reloading can become a monster! Not to say you can't
scale up good webpack performance (obviously slack has) just that it's not an
automatic thing but something that requires some TLC.

Thanks for taking the time to share slack team!

------
jsmeaton
Hoping that someone might have some recommendations for a problem that we have
in particular.

We have multiple sites, each of which has it's own theme. Our various sass
files check the theme variable passed into the sass loader, and decide on the
correct values for particular styles. Our react components import the
stylesheet and reference values accordingly. We also have a spattering of old
backbone on some pages, so it's not just react involved.

Unfortunately, this means that we have to build our entire application for
each theme. This takes an excruciating amount of time. Parallel Webpack makes
it somewhat manageable, but I'd like to eliminate building for each theme
altogether.

Any ideas on paths we can look into? If our application was all React, I'd
consider styled components or a theme HOC. It's not though, so I've put those
options on the back burner for the moment.

------
simooooo
I use webpack every day. But the config for it scares the crap out of me.

~~~
osteele
I recently discover Poi [https://poi.js.org/](https://poi.js.org/). It’s built
on top of webpack. If your issues with webpack are configuration complexity,
not speed, then Poi may be appealing to you.

~~~
edmorley
Another option similar to Poi, that I'd recommend adding to any comparison, is
[https://neutrino.js.org/](https://neutrino.js.org/)

------
mbrumlow
I hate webpack, it has been a hack from the start. I can't wait till HTTP2 is
more widely supported.

My latest projects use polymer and a custom built service (in go) to
automatically parse entry points to my application and index the required
files. When a HTTP2 connection is made -- and the browser supports push, I
will automatically push all the required files. With browsers like chrome the
results are near instant and I have full control over what gets pushed or not.

Personally I think we need to stop hacking the web together and properly solve
these problems. I think HTTP2 with push is a good step in that direction.

~~~
jaredklewis
I don't see how HTTP2 can replace webkack. Even if websites stop making single
file bundles of JS, I think we'll still need something to: \- Transpile from
latest ES standards, to browser supported code \- Compile from non-JS
languages like TypeScript, Flow, and so on \- Do dead code elimination,
minification, and tree shaking \- Bundle code shared by other bundles \-
Optimize images And on and on...

I think webpack is a mess, but I think it really is just a reflection of the
complexity of the web platform.

~~~
mbrumlow
You are just highlighting more of the problem. The fact a blunder is
responsible for doing all these things is just proof of more hacking.

Most of the things you described live outside of webpack, and webpack is NOT
required to use them.

~~~
jaredklewis
Sure, I don't disagree that webpack merely brings those features together into
one place. But webpack was born because 80% of the time you make a webapp you
don't want just minifcation, or just transpiling, or just cache busting file
names, or just file event based recompiles, or just bundling, or just tree
shaking, and on and on. Most of the time, you want all of that stuff. People
got tired of maintaining their 1000 line npm/gulp/grunt task files, so a bunch
of projects were launched with the goal of eliminating that glue code. Webpack
is the most popular, but there are of others like Brunch or more recently,
Parcel.

I think webpack is a mess, but will probably end up being the mess we're stuck
with for sometime, because while it is complicated, it does solve a lot of
problems. I see a lot of parallel with the GNU make and autotools setups used
to build most C projects. The layered way that autoconf, configure, and make
build configuration to compile and install programs is pretty complex (to my
eye). Sure, it could probably be simplified a bit, but cross compiling code
that dynamically links to libraries and installing it on different operating
systems is just a complex problem.

~~~
petepete
I use and am very happy with Brunch. Yes, Webpack might have more features but
my Brunch config is like 25 lines and it just works. It took me fifteen
minutes to set up having struggled with Webpack for a couple of days.

