
The Wonderful World of Webpack - Cyph3r90
http://jackhiston.com/2017/9/4/the-wonderful-world-of-webpack/
======
mrgalaxy
I think Webpack solves a real problem in the web world, but holy cow is it a
pain to configure in large applications. Anyone who has had to maintain a
larger (and often dynamic) Webpack configuration knows what I am talking
about.

I think Webpack is a step in the correct direction, but web bundlers are still
in need of improving.

~~~
256cats
True. Several times I have resorted to putting random console.log's into the
webpack core and it's plugins as the only way to figure out why the
configuration doesn't work.

~~~
travmatt
You can also run your build in chrome canary and step through in the debugger:
[https://medium.com/webpack/webpack-bits-learn-and-debug-
webp...](https://medium.com/webpack/webpack-bits-learn-and-debug-webpack-with-
chrome-dev-tools-da1c5b19554)

------
tombh
I think an interesting reflection when considering the config setup
difficulties of Webpack are the so-called 'zero-config' projects like;

[https://github.com/insin/nwb](https://github.com/insin/nwb)

[https://github.com/saguijs/sagui](https://github.com/saguijs/sagui)

[https://github.com/mozilla-neutrino/neutrino-dev](https://github.com/mozilla-
neutrino/neutrino-dev)

[https://github.com/facebookincubator/create-react-
app](https://github.com/facebookincubator/create-react-app)

They help frame this domain's perspective on the timeless tension between
usability and flexibility - ie am I prepared to sacrifice some configuration
options in return for being able to get quickly setup?

Clearly the answer in a lot of cases is going to be 'no', but nevertheless
seeing how difficult it can be to find that sweet spot between usability and
flexibility might help one better appreciate the value returned by those
difficulties.

Personally, I've found the commitment to stick to the conventions enforced by
Create React App to have been largely beneficial (at least so far (in one
project)). And I've been surprised how willing and able I am to creatively
work within those limitations.

~~~
zumu
> am I prepared to sacrifice some configuration options in return for being
> able to get quickly setup?

The best part about create-react-app is the `eject` option. So you never have
to ask that question. You can just get going with the defaults, then 'eject'
your config files to tweak once you uncover your specific needs.

I am convinced this 'no lock-in' approach is the way to go for scaffolding
builders and frameworks in general.

~~~
allover
> The best part about create-react-app is the `eject` option

Best part or necessary evil? I'm glad it exists, but ultimately you lose a lot
of the benefits of create-react-app (seamless updates to react-scripts, e.g.
the move from Webpack 1 to 2) as soon as you eject, which is why it is
somewhat discouraged, and why some people have built projects that allow you
more config overrides _without_ ejecting.

------
styfle
I had a hard time starting with webpack. Because it's so flexible, there are
so many choices.

That's why I made a boiler plate project with React SSR, TypeScript, and
Webpack

[https://github.com/styfle/react-server-example-
tsx](https://github.com/styfle/react-server-example-tsx)

~~~
bluepnume
I had the same problem -- after throwing together a few open source front-end
libraries, and struggling with each to get webpack, babel, karma, flow, etc.
all working seamlessly together, I put together
[https://github.com/krakenjs/grumbler](https://github.com/krakenjs/grumbler)
and now just fork this every time I want to start something new.

Being able to just start writing code without spending forever setting up the
perfect environment is hugely liberating. I'd encourage everyone to find good
boilerplates for what they want to do (or put together their own if nothing
else fits)

~~~
swyx
in case its helpful to anyone, i was frustrated with this same thing too so i
made a webapp to help with the boilerplate search. It also measures the
"cognitive load" of a boilerplate to add some sort of cost function.

Here are the two boilerplates mentioned:

[https://packagejason.herokuapp.com/krakenjs/grumbler](https://packagejason.herokuapp.com/krakenjs/grumbler)

[https://packagejason.herokuapp.com/styfle/react-server-
examp...](https://packagejason.herokuapp.com/styfle/react-server-example-tsx)

and you can search others to your fancy.

~~~
doingmything
I could've sworn you guys were joking but you're all serious. This is utter
madness!

~~~
ajdlinux
How much time do we now need to spend trying to choose a boilerplate?

~~~
dotancohen
No, now that time is being used to choose a boilerplate comparison webapp.

~~~
swyx
lol piss taking in its highest form

------
yladiz
I dealt with some Webpack issues at my last job, and for my current job, which
started around the time that Rollup was becoming popular, I decided to try
Rollup. Even though it happened to have some bugs (which I've reported and
they were fixed) it seemed to be a lot better than my Webpack experience,
partly because it didn't try to do too much and I had more freedom to do what
I wanted. Of course the project I'm working on isn't terribly complex, so I
don't need a ton of specific configurations, but it does use React and I felt
working with Rollup was a bit easier than Webpack when concerning React,
_especially_ when talking about speed; I absolutely hated working with Webpack
because I didn't want to wait 1.5-2 minutes just to start working, and have to
wait 10 seconds each time I save a file. The only thing I hated more was the
attitude from some coworkers that my computer was too slow rather than the
tool being bad.

------
time4tea
Webpack just makes me so sad. It is slow, arbitrary, inconsistent and
unstable. Just like gulp and grunt. I seek a proper, fast, consistent,
dependency driven JavaScript build tool. Won't somebody share their make rules
for .js?

~~~
paulddraper
I work on ~1000 lines of GNU make for a front-end build pipeline with dozens
of projects with 600 kLOC TypeScript, 400 kLOC JavaScript, 80 kLOC LESS, and a
variety of other things (formatting, i18n, Closure Compiler, Angular AOT,
etc).

Make is truly a timeless tool. Parallel, incremental, and declarative; it's a
well architected tool based on correct principles. Everything else -- Ant,
Maven, Grunt, Gulp -- are diappointments by comparison. Unfortunately,
however, make wasn't made to compose well; you'll rarely see people (including
me) publishing and re-using rules.

If you want a general-purpose composable non-sucky build tool, check out
Google Bazel (in beta): [https://bazel.build/](https://bazel.build/)

Blog post from Google Angular engineer, including thoughts on make and Bazel
for front-end builds: [https://medium.com/@Jakeherringbone/building-angular-
apps-at...](https://medium.com/@Jakeherringbone/building-angular-apps-at-
scale-813ef42add04)

~~~
seanwilson
> Unfortunately, however, make wasn't made to compose well; you'll rarely see
> people (including me) publishing and re-using rules

I'm not saying Gulp, Grunt or Webpack will suit your needs but I find
Makefiles quickly become very unreadable and hard to debug. Its syntax for
loops, conditions and arithmetic is awkward and hard to remember and the
behaviour of variables is confusing. At least with the others the syntax is
decent and there's tons of plugins for common tasks.

Why would Gulp for example not suit your use case?

------
erikpukinskis
A lot of comments in this thread about struggles with setting up a config.

My intuition is that this is because we are using a declarative programming
model: a config file, rather than code.

I don't really understand why we would use, say, Ruby to encode a web server,
and then use JSON to encode the build process. We choose our programming
languages very carefully for their ability to express powerful control
structures, ease of maintenance, debuggability.... and then we use a brittle,
underspecified language of flags, nested keys, and filesystem tests and side
effects to program our build system... Why?

Can someone who believes in this declarative config build system explain why,
in the abstract, it's a good fit for build processes, when we'd never choose a
language like that for our actual codebase?

I'm influenced here by Jonathan Blow, who designed into Jai the ability to run
arbitrary Jai code during the build process, for this exact reason.

------
Pharylon
I have an Angular 1.x app bundled with Webpack, which allows me some nice ES6
features. I especially like it for imports (which allows much better code
completion than Angular's native Dependency Injection).

Configuring Webpack to do this was one of the hardest things I've ever done.
:D

------
GlennS
Anyone still using Google's Closure Compiler? How does it compare these days?

~~~
paulddraper
I am (work at Lucid Software: www.lucidchart.com www.lucidpress.com). We're
using in conjunction with Closure Library, Clutz, Tsickle and Angular AOT
template compilation to get great code sizes.

And Google has always been a heavy user of course.

Closure Compiler is preternaturally good at dead code removal, inlining,
minification. But you have to use advanced optimization mode, and write JS
amenable to its static analysis. If you're willing to put in that work, you'll
get fantastic minification. If you're not, you should just find another tool.

Scala.js includes Closure Compiler adv optimizations right in the standard
workflow, so it's a good bet any Scala.js project will be using it.

------
latchkey
Every time I start a new web project, I try to find ways to not have to use
something like Webpack. I keep hoping the community has finally solved the
problem in a more elegant way. The additional mental overhead of a dependency
like this isn't worth it.

Sadly, I haven't found a way around the dependency yet.

~~~
colordrops
Modules are now enabled by default in Chrome 60. Hopefully this will be a good
first step in making things better.

------
wbillingsley
Still much more a fan of sbt (and sbt-web for bundling just about anything on
the web side).

Smaller, type-checked build files, even has a native packager plugin for
building RPMs... really very nice.

------
arve0
> What if we could take C# code, and transpile it into JavaScript? What if we
> could take a YAML configuration file, and create a working program just out
> of configuration? What if we took an image, and automatically made it
> cropped and greyscaled?

What?! Image, crop and greyscale? That doesn't sound like a job for a bundler.
Is this sarcasm?

~~~
jogjayr
It's a valid use case. Think of something like a thumbnail generator for a
directory of images. If you include an image in your application, maybe you
also want to be easily pull in a thumbnail for it on a different summary page
in your app.

~~~
chii
This sounds more like a build tool than a code "packing" tool...

~~~
jogjayr
In the context of webapps I'm not sure there's much of a distinction...

