
Webpack 2.2 – Release Candidate - thelarkinn
https://medium.com/webpack/webpack-2-2-the-release-candidate-2e614d05d75f#.3nrnoh6zc
======
scrollaway
Looking at the list of changes
([https://webpack.js.org/guides/migrating/](https://webpack.js.org/guides/migrating/)),
it seems like a lot of "magic" has been removed.

That's good. It's kinda funny how this is a very frequent pattern: Build
something full of magic and, as you grow more mature and hit pain points, end
up removing the magic.

I've had a very similar experience in my career so far as a dev. My code used
to be full of magic, auto-guessing things based on how methods are named, etc.
I've moved away from that, it wastes more time than it saves.

Anyone else with the same experience?

~~~
sergiotapia
Smart defaults, allow configurations. That's the key.

I learned how to use Webpack but still think it sucks and it's incredibly
complicated for what it does for 90% of use cases.

Smart defaults. -Then- let me configure if I need to.

~~~
thelarkinn
Totally understand, now that webpack 2 is almost out the door, this is one of
our top 5 overhauls we want to make.

"Can we make smarter defaults"

We support a lot of build targets and are agnostic to library and stack so
it's going to be a challenge but with your help and the community I know we
can get it done.

~~~
ch4s3
I love how you turn up immediately whenever someone mentions webpack!

~~~
thelarkinn
Well, as one of the maintainers besides working on core, and loaders/plugins,
my role is to rep the voice of all of you to the core team, and also the other
way around. Just here to help :)

~~~
ch4s3
You're doing a great job! Keep it up!

------
tonyhb
Recently moved to this from webpack 1 for both personal projects and work.
Webpack 2 combined with Yarn running inside of Docker to automate builds is
the nicest (and fastest) frontend build pipeline I've had yet.

The experience with Webpack2 is so much better:

    
    
      - Cleaner documentation
    
      - Saner configuration files:
    
        - It errors out if you add incorrect flags!
    
        - This means that postcss et. al. use config files
    
      - Saner module definitions (now called rules):
    
        - No query flags!
    
        - Actual object support!
    
    

Plus tree shaking, code splitting etc. It's way better. Now looking forward to
integrating babili within webpack to remove uglify.

If you're thinking of upgrading it's not that much effort given the new
documentation, too. Definitely worthwhile, and there seems to be less
occasional build bugs using this with newer babel plugins (originally switched
because of a crazy stackoverflow parsing a two-deep object).

~~~
BinaryIdiot
> Webpack 2 combined with Yarn running inside of Docker to automate builds is
> the nicest (and fastest) frontend build pipeline I've had yet.

See, maybe this is the get-off-my-lawn coming out of me but it pains me that
_that_ complex setup is the nicest and fastest frontend build pipeline you've
had.

Almost a whole _decade_ ago we had pretty simple and straight forward build
patterns for frontend. Essentially running the site as is from the VCS was in
"debug" mode and you'd write scripts that combines and minifies everything and
plugs it right back into the html when you "build" it. And that it was it.
Simple and fast.

I'm sure using ES2015, TypeScript, SCSS, handlebars and a million other things
that get transpiled, concatenated and minified help with productivity for some
people but it just seems insanely overly complex to me especially when half of
the examples that show how "simple" many of these technologies are can also be
made very simple using standard API calls.

I like things simple. As simple as possible. Webpack is probably not for me
but I wanted to provide my own perspective to see if anyone shares it or if
I'm more of an outlier.

~~~
maktouch
I think it really depends on what you work on.

> Almost a whole decade ago we had pretty simple and straight forward build
> patterns for frontend.

a decode ago, we didn't really build web apps like today though. The browser
landscape was different. The technology was different.. but the most
important: the expectation was different. Man, 10 years ago we still had
flash.

> [...] help with productivity for some people but it just seems insanely
> overly complex to me

It is. To be honest, if I'd start today, I'd be super lost too.. but it is a
one-time cost/investment to start to gain that productivity.

I think the biggest upside of this whole thing is working at scale in terms of
human. Good modularization allows you to achieve this.. in the old school day,
that was either a big javascript bundle, or a bunch of them inserted in the
pages as global.

My opinion is: if you think you don't need it, don't bother with it. I didn't
understand webpack until I needed it. I didn't understand React until I needed
it. I didn't understand docker and kubernetes until I needed it. Trying to
force yourself to use thing when you don't see the usefulness is counter
productive.

~~~
BinaryIdiot
Fair enough though

> a decode ago, we didn't really build web apps like today though. The browser
> landscape was different. The technology was different.. but the most
> important: the expectation was different. Man, 10 years ago we still had
> flash.

Other than dealing with more browser incompatibilities that we have less of
most of my work was still fairly complex web applications. We just didn't have
many if any frameworks so depending on the experience of the starting
developer you most likely walked into a wall of spaghetti which I understand
frameworks can sometimes help even new developers write cleaner code.

Also Flash was amazing back then, heh :)

------
fiatjaf
This thing is so complicated and so full of magic and options and the
documentation is so shallow, I can't find examples, can't get a tutorial that
isn't uselessly superficial.

I've tried using Webpack in its begginings, because React people only talked
in Webpack terms, but then switched back to Browserify, which is simple, not
magical and straightforward. I tried using Webpack again lately, with the
bizarre Gatsby static site generator, and the failures are enourmous. I can't
even understand how exactly does a loader work. Gatsby makes forced use of
something called webpack-config or something like that, which is just a
useless abstraction on top of the already confusing Webpack config.

Please, someone explain to me what does this thing do that Browserify can't.

~~~
vmasto
> Please, someone explain to me what does this thing do that Browserify can't.

Nowadays not a lot more, but when it came out it was a revelation.

The key thing to note is that replicating webpack's abilities in browserify
takes about the same or more amount of config and boilerplate.

~~~
fiatjaf
What were these great things Webpack introduced? Not HMR.

~~~
skrebbel
When I switched from browserify to webpack, everybody was using grunt or gulp
to trigger full browserify builds on every change. Browserify had watchify,
but it was bolted on, buggy, and slow. Webpack had a devserver with
incremental builds that just worked.

More generally, browserify seemed very Node-focused in attitude and webpack
made a lot of design choices particularly for the web. Things like having
uglify built in, ability to not just bundle javascript but also other assets
(like pictures and css). I bet all these things were possible with browserify,
given the right transform, but I liked that with webpack it was the norm. It
seemed designed for the problem I had: coding a web app. Browserify seemed
designed for "I have this huge node program that i want to port to the browser
with a little effort possible".

------
ctulek
It is hard to find well maintained JS libraries in these days. Thanks a lot
for the mature work done here, especially in terms of documentation. So many
OS projects launch their new shiny versions in such a rush, they leave their
users in darkness for a very long time.

~~~
dsissitka
Didn't they do that with 2.0?

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

~~~
vmasto
No they didn't. Webpack 2 has been kept in alpha and beta for so long exactly
because the documentation was lacking. If anything that fact alone shows a
good amount of maturity.

------
msoad
One big question I have from Webpack is this:

In age of HTTP/2 packing is not recommended anymore but I love so many
features of Webpack, are you guys going to adopt to HTTP/2 paradigms?

Great work, thanks!

~~~
thelarkinn
We have a plugin built around the research on HTTP/2 and web perf (which based
on the data so far points to bundling still yielding the optimal results)
called AgressiveSplittingPlugin.

It's designed to allow you to specify a max and min file size and webpack(2)
will create x bundles of those size up to a certain number (if specifies). The
advantages are now you are drastically increasing the delivery of your js and
other assets but still bundled for opt.

Sokra (Tobias) wrote an article about this research if you are interested!!

[https://medium.com/webpack/webpack-
http-2-7083ec3f3ce6#.5yca...](https://medium.com/webpack/webpack-
http-2-7083ec3f3ce6#.5ycapkafg)

Also to see an example of the API usage you can visit our core repo under
examples where we explain the trade offs (compression vs cacheability):

[https://github.com/webpack/webpack/tree/master/examples/http...](https://github.com/webpack/webpack/tree/master/examples/http2-aggressive-
splitting)

------
mstijak
webpack is great. HMR and code-splitting are killer features. Only thing that
I'm worried about is tree shaking. There are a couple of long standing issues
about problems with classes and export all statements. Rollup is missing code-
spliting, webpack doesn't do tree shaking well and complains about bundle
sizes. Not sure what to do. If somehow rollup could be integrated, that would
be perfect.

~~~
abritinthebay
HMR & code splitting weren't even original to WebPack... where does this
fiction come from that it introduced them?

(Side note - I have a complex app but still get ~1sec build times, why the
fuss over HMR?)

~~~
kentor
Not having to refresh which means preserving state. If I have a modal opened
and I want to make a change to the modal UI, if I refresh I would have to
reopen the modal. With HMR the modal just rerenders.

Also even if you have a fast build, refreshing might require refetching data
from a server.

In any case browserify also has HMR and it's great.

------
ahayter
Thank goodness I decided to bite the bullet last week and make the jump to v2.
Upgrade took a while but was rather painless thanks to the great migration
guide on the new documentation site.

If you are using a ton of loaders that aren't v2 ready you may have a more
painful experience, you'll have to get familiar with the LoaderOptionsPlugin.

If you're newish to webpack it could be a frustrating experience.

Shout out to the webpack team though, It's an impressive tool.

~~~
progx
I wait some month until the major Loaders are Webpack 2 ready. Don't have time
to waste in such things.

------
julenx
Reading through the Webpack2 release tags I came across the v2.1.0-beta28
changelog, which mentions:

> * add `import()` as Code Splitting construct. It should be used instead of
> `System.import` when possible. `System.import` will be deprecated in webpack
> 2 release (removed in webpack 3) as it's behavior is incorrect according to
> the spec.

I was under the impression `System.import` would be the new way to do code
splitting and hence supersede `require.ensure()`. After further checking, now
it seems like the function-like `import()` will be used instead [1], which is
better accepted in browsers than `System.import()`.

[0]
[https://github.com/webpack/webpack/releases/tag/v2.1.0-beta....](https://github.com/webpack/webpack/releases/tag/v2.1.0-beta.28)
[1]
[https://github.com/webpack/webpack/issues/3098](https://github.com/webpack/webpack/issues/3098)

------
sotojuan
We have an ejected CRA web pack confit that I wanna update to 2 eventually.
What's a good migration guide?

~~~
thelarkinn
Check the actual article and you'll see the v1-v2 migration link embedded into
the post!!!

------
te_chris
Quick, time for Laravel Elixir to find another beta version to bundle before
an actual release happens...

