
Webpack: The Missing Tutorial - shekhargulati
https://github.com/shekhargulati/52-technologies-in-2016/blob/master/36-webpack/README.md
======
sotojuan
There's no shortage of Webpack tutorials, and this one looks fine so props to
the author. However, the _best_ Webpack tutorial I've seen for beginners (and
experts!) is this video that explains it from a conceptual point of view[1],
explaining what exactly Webpack does and not just how to use it:

[https://www.youtube.com/watch?v=WQue1AN93YU](https://www.youtube.com/watch?v=WQue1AN93YU)

[1] This thread's post does this too, which is awesome!

~~~
vonmoltke
I may be in the minority, but I don't want to watch videos when learning how
to use things. I want written tutorials that I can refer back to when
necessary.

My big problem with tutorials in JS-land is that so many seem to assume too
much background knowledge in the reader. Webpack has been no exception; as
someone who generally doesn't do front-end stuff I have really had to dig
around to find out how things actually work and find things like lists of
valid options for different sections.

~~~
mobiuscog
I love videos to learn... but as someone working for a company that don't
allow any videos through the firewall... written posts are also useful.

------
cromwellian
Odd that 7 years later, and JS build tools still don't match the level of
optimization you get in Closure Compiler.

IMHO, the speed of the build tool is less of a priority than the speed of the
code it produces. You pay the cost of the build tool mostly in integration
tests or production builds but shouldn't pay it during development.

However your users pay for inefficiencies times the number of times the app is
loaded. The state of JS tooling is woefully behind other languages and IMHO
still behind the state of the art 5 years ago. Any non trivial sized app for
example will require global dead code analysis and method and field level
pruning as your dependencies grow over the lifetime of your app, all apps tend
to bloat from unneeded code pulled in.

~~~
thelarkinn
I think closure compiler is the perfect example of how saving extra 100kb is
has never been worth the poor user experience. Despite the pain in setting up
webpack, the result is an excellent collection of features that goes beyond
just JavaScript.

~~~
cromwellian
By "user" you mean developer, but you're trading off compile time pain for
you, and saddling everyone else with downloading an extra 100kb, which on
mobile networks or in developing countries is unforgivable.

~~~
thelarkinn
True, which is why we haven't ignore this and are hoping to add features like
scope hoisting (and personally I'd love to pass the AST program that webpack's
parser creates right in to closure compiler js to see how "advanced" it can
compiler) and other features. Because in the end, the api possibilities that
webpack provides for plugins makes the tool limitless.

~~~
cromwellian
Closure Compiler also has pluggability, however the plugins must be written in
Java, which is a downside for the JS ecosystem. For example, asset packaging
wise, there's stuff like GSS Compiler integration, where
goog.getCssName('foo') is translated into an obfuscated short className, while
the GSS compiler optimized, prunes, and combines GSS.

GWT was the same way, asset packaging was a core feature even in 2009. For
example, it would automatically compile CSS, UI templates, and images, auto-
optimizing them, and auto-sprite-sheeting everything, while packaging things
into as few HTTP requests as possible.

The real issue is that to do this in a safe way for JS requires coding
conventions be adhered to, or the adoption of TypeScript and annotations.
Closure's advanced mode will break JS that tries to get too fancy with
dynamism.

------
eyelidlessness

        require('style!css!../css/style.css');
    

What is this I don't even.

~~~
pigpigs
In case it was really a question: this passes `../css/styles.css` into the css
loader then the style loader when `require`-ing. Normally this is setup in a
webpack.config so you can just do `require('../css/styles.css')` normally

------
davedx
Be careful jumping into webpack and getting it to load everything (JSON, style
sources, HTML partials (!)) with require/import. It can wreak havoc with your
testing.

~~~
kjsthree
Couldn't agree more. Also, if you want server side code to work without
bundling you'll want to be careful there too.

I have css requires restricted to the client entry file to keep other modules
testable/usable server side otherwise.

------
Blaiz0r
I hate to say it (I've enjoyed the benefits of using webpack on a few projects
now) but I feel like it's all a bit too late for webpack (2).

Rollup or Brunch seem to offer a preferable alternative with speed, ease of
use, and optimisation.

~~~
tiles
What is Rollup vs Brunch? Coming from someone who just understood why we have
Webpack vs Browserify.

~~~
Blaiz0r
They're both alternative build tools

Rollup is very similar to Webpack but is architectually different to allow it
to optimise assets further and faster.

Brunch has actually been around since before Grunt, it's just not marketed. It
works in very simple fashion, just install plugins via npm and start using
them, no need to edit configuration files (unless you have very specific
requirements).

I would consider Rollup as the new hotness, building upon the success of other
tools and starting from a better position to create an optimised tool.

Brunch is a long time standing tool that does a job very well and if your
project doesn't require any special configuration or architecture it's so easy
to use (it can be configured though).

~~~
namelezz
How fast is Brunch and Rollup compared to Webpack? Is there something similar
to Webpack dev server [0] in Rollup?

[0] - [https://webpack.github.io/docs/webpack-dev-
server.html](https://webpack.github.io/docs/webpack-dev-server.html)

~~~
thelarkinn
Here is a up to date write-up for our proposal and review of performance in
our repo
[https://github.com/webpack/webpack/issues/2873#issuecomment-...](https://github.com/webpack/webpack/issues/2873#issuecomment-241458071)

~~~
namelezz
Thank you for the link. This sounds scary though.

> Webpack will perform less-favorably compared to Rollup as the number of
> modules increases.

~~~
thelarkinn
It's not, in the end load and runtime perf boil down more to what and how much
you load up front.

