
Webpack 4 Beta released - schneidmaster
https://medium.com/webpack/webpack-4-beta-try-it-today-6b1d27d7d7e2
======
skrebbel
I suspect that the Webpack team thinks that developers' favourite job is to
upgrade tool configurations. I mean, it's great that improvements are being
made, but breaking changes are not.

Remember that the Webpack team has shown to be actively hostile to people who
just want to keep their 2-year-old codebases work without doing needless
upgrade work. They _removed_ the webpack 1 docs [1], so if you have a few-
years-old codebase that you want to get up and running, and somehow you get a
webpack error, the message from Webpack is "screw you, upgrade to webpack 3
first and only then we'll allow you to read the docs".

I have no reason to not expect the same to happen with Webpack 4, and the
inevitable Webpack 5, 7 months from now. Webpack 2/3 docs will be subtly
removed, retired and forgotten. We're all forced to keep doing work to make
something work that already worked perfectly fine.

Now, I'm well aware that an angry rant on the internet about the voluntary
work from open source contributors is not particularly constructive. I've
singled out the Webpack team here, but the reality is that a big part of the
web dev ecosystem, across languages, does not care much about backward
compatibility. I'd love for that attitude to change.

In semver, every major version is a tragedy.

[1] [https://webpack.github.io/docs/using-
plugins](https://webpack.github.io/docs/using-plugins)

~~~
thelarkinn
We strive to be as backwards compatible as possible. But we also hold
ourselves accountable to keeping pace with the ecosystem.

Most breaking changes are to accommodate the number one ask of our users:
faster, smaller builds.

We asked what the time frame they wanted for releases. We got out of a couple
thousand responses 6mo being the sweet spot. Appreciate the candid feedback
though.

In regards to the v1 docs: we wanted to have a fresh start. I don't imagine
our docs pages now changing for awhile. Each major breaking change we ship a
migration guide so that people can upgrade.

~~~
skrebbel
Sean, you don't know this but for quite a while now I've been amazed about
your work responding to everybody complaining about Webpack on the internet,
anywhere. There's absolutely no requirement for you to be so nice to users and
yet, here you are again. Hats off, you're making the world a little bit
prettier.

This time I'm the one complaining, and I must admit that I'm curious about the
exact wording of that question about release time frames. If you asked "how
often do you want to make config changes just so you can update Webpack to the
latest version", I bet many people would answer "never" instead of "6 months"
:-)

But hey, we established that we have different ideas about what the compat
sweet spot is and you and yours are the one doing all the selfless work and
I'm the guy complaining on the internet, so take everything I say with a bag
of salt.

All that said, any chance you could make a teeny tiny little link from the
Webpack 1 "THESE DOCS ARE GONE" pages to
[http://devdocs.io/webpack~1/](http://devdocs.io/webpack~1/) or some place
like that? There are people who inherit old codebases and it would be very
nice for them to not _have_ to update Webpack just to find answers to their
problems.

~~~
thelarkinn
Ah yes so we removed the page but is all still under our WIKI on
webpack/webpack. Mind submitting an issue and we could surface a little note
on our README?

~~~
skrebbel
Done, thanks!

------
y0ghur7_xxx
Do you remember the time when you just copied your file over to the server,
and magically everything was deployed? I do. It was a good time. Yes, I am
old.

In search for something that makes me work like the good old times, but with
modern javascript solutions, I stumbled upon mod_pagespeed[1]: it minifies
your javascript and html, optimizes images, and more or less does what webpack
does (minus the typescript -> js compilation).

The good old times are back for me: deploying is now an scp away.

For important projects I copy the static assets to the server, let jenkins run
integration tests on staging and if everything works as expected just copy it
over to production. One less thing to worry about for me.

[1][https://www.modpagespeed.com/](https://www.modpagespeed.com/)

~~~
moogly
Did you also have to tell your users to press Ctrl+F5 to get the updated
assets?

~~~
linkmotif
What is there a better way??!

~~~
staz
Assuming your are not just joking, the keyword to look for is "cache busting"

~~~
linkmotif
Hehe I was joking. Really enjoying the cache busting functionality in webpack
:)

------
fenomas
These look really solid!

For anyone else who was confused by the minimal explanation of the
"sideEffects: false" feature, apparently this targets cases where (1) module A
exports some code, (2) module B imports from A and exports end points, some of
which depend on A, and (3) module C imports code from B that doesn't reference
code from A.

In this situation by default webpack assumes that the code from A might have
side effects inside B, but if A declares "sideEffects: false" in its
package.json, the tree-shaker will assume it's safe to omit module A from the
final bundle.

Incidentally the end user can also declare in their config that module B
should use sideEffects:false, even if the module doesn't declare it. Details
here:
[https://github.com/webpack/webpack/issues/6065](https://github.com/webpack/webpack/issues/6065)

~~~
wereHamster
Too many assumptions, too many ways how developers can make mistakes, by
declaring code side-effect free while it has some.

~~~
WorldMaker
Sure, but if you author a package and put sideEffects: false in your
package.json, but don't actually follow through on that in your code, that's a
bug in your library, and the easiest fix is a quick PR to remove sideEffects:
false from package.json, with a stop gap that if I find a library with that
sort of bug I could tell webpack sideEffects: true to override the behavior
until the bug is fixed.

------
toadkicker
One of things I absolutely despise about the JS community is this obsession
with build tools. JS is meant to be a runtime language and the amount of
transpilers, minifiers, uglifiers, obfusicationifiers, is absolutely endemic
to the messy state of change the language is undergoing.

However with this release I'm excited to start deleting a bunch of ridiculous
build code to make Webpack work. Really a build tool is a tool, it should
never be in the way of developing features. I haven't enjoyed using webpack
until now. No sensible defaults, poor documentation, and no standard
conventions. This release changes all of those complaints. A boost for
productivity is a win in my book.

~~~
gotofritz
Found the grumpy old coder

~~~
dang
Personal attacks will get you banned here. So will repeatedly posting
unsubstantive comments, which I'm afraid you have.

Could you please take the spirit of this site more to heart, as described at
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)
and
[https://news.ycombinator.com/newswelcome.html](https://news.ycombinator.com/newswelcome.html)?
That means posting civilly and substantively, or not at all.

------
dmitriid
As a web dev I am extremely happy Webpack team changed their stance from
"webpack config is the way it is because everyone's needs are different and
also because that's just how Javascript works" to "yes, we can provide sane
defaults out of the box".

Aaand that their communication has improved a thousand-fold.

------
onion-soup
Jeez tone down them emojis a bit pal. And I'm seeing black squares on windows
7 anyway

------
realPubkey
Has anyone ever updated a minor webpack-version without having to touch the
config? Me not.

~~~
lwansbrough
Only a masochist updates webpack once they get it working.

------
paws
Two years ago I would have invested some effort to read this thoroughly and
try to stay on top of the API changes. I'm sure it's helpful to a lot of
folks.

For sure I do care about my build toolchain. The nice thing about being a
React developer today, is that thanks to create-react-app, more specifically
react-scripts [1], I'm thankful I get to choose to not worry about it. Just
like I didn't have to worry about 2.0 -> 3.0 last time.

Cheers to the CRA maintainers. Thanks for giving me some time back!

[1] [https://github.com/facebook/create-react-
app/blob/next/packa...](https://github.com/facebook/create-react-
app/blob/next/packages/react-scripts/package.json#L62)

~~~
needcaffeine
In your experience, is CRA just for people starting out with a new project or
can large apps implement and use it without ejecting and diverging?

~~~
paws
If your existing large app is a React app, the naive thing to try would be
migrating the src/ folder into a new CRA app and see what happens.

If you get a lot off runtime errors you have an easier time migrating to CRA,
if you eject a new CRA app and gently/iteratively adjust the webpack config on
your existing project to match CRAs.

------
danjoc
Is there really any point to webpack now that we have http2? I'm looking for a
way to code split all the things and webpack is making that difficult. I want
cache performance over download speed now that I've gone mobile only on data.

~~~
joshribakoff
Yes.

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

To quote the article:

There is still a protocol overhead for each request compared to a single
concatenated file. The compression of the single large file is better than
many small files. Servers are slower serving many small files than a single
large file.

~~~
danjoc
I'm really less interested in speed though. I want to optimize for file
transfer bandwidth. Going all mobile data for a week has shown me two
problems. JS has severely bloated websites, and staying up to date with
software patches is expensive. In both cases, the amount of new material being
transferred is very low. A point update on a JS library or patch is a few
lines change, but we must download the entire library again. Compounding this
for JS is every site using the same libs are sending the same data, because of
browser origin policies. One way around that is CDNs, but then you are
submitting to a centralized point of failure/spying.

Sending the whole file again is the easiest route for developers, but the most
expensive for mobile only cord cutters.

~~~
joshribakoff
Webpack does that with chunk hash. Common chunks go into common.js, and my app
goes into app.js, if I change my app's JS, only app.js gets downloaded which
is probably 50kb whereas common.js is maybe 300kb.

The point is there is a tradeoff between speed & efficiency. If every line of
code were its own file, you'd have a high amount of efficiency when only 1
line changes, but loading that would be a nightmare on mobile.

------
farnsworthy
I've been running the alpha, to help get past the Webpack/Uglify ES6 support
issues.

It sounds like webpack-dev-server will also disappear soon, too? (Replaced
with a more tightly integrated solution, or?)

~~~
gotofritz
Yes, sorry cannot find the link, but they are going to get rid of it from what
I read. There is no more tightly integrated solution in the pipelines, you'll
have to roll out your own with Express or something (or, more likely, a third
party will come up with a solution that will become the norm)

------
unquietcode
Oh good. I just finished upgrading my project to Webpack 3. Can't wait to do
it all again...

I'm all for rapid progress, but the pace of web development is absolutely
breakneck.

~~~
h1d
There are other options that requires no config.

------
tjpnz
A few years ago I was asked by a frontend team to investigate their Jenkins
build. What used to take 90 seconds went to 15 minutes and it only started
happening when the team switched to Webpack. I recall Webpack being hideously
complicated with a lot of the documentation either missing or just plain wrong
- no wonder they managed to make a mess of things so easily. Has any of that
changed?

~~~
schneidmaster
The documentation got substantially better in 2.0 (imo), and simplifying the
configuration overall was a major initiative for 4.0. You can now start with
zero config if you want to follow their defaults of putting your source in
/src and built output in /dist, and they also added production/development
"modes" that enable a bunch of sane defaults for each. You can still get into
really complicated configuration cases depending on your project but it's
definitely been on an upwards trajectory in that regard.

------
RobertRoberts
I don't use Webpack, would it help with regular website dev? Or is this just
for web apps?

Also, does it really make things faster? What about HTTP2/SPDY, do we really
care about making everything one file anymore? This seems like a paradigm that
is no longer valid (like using tables instead of grid for website layout).

~~~
simonlc
You pretty much will always need a bundler, unless you write everything from
scratch, and don't support legacy browsers. Webpack actually does do things
like code splitting for you, so no, not everything goes into one file.

~~~
RobertRoberts
Can you explain if Webpack would help with Wordpress sites? Or is Webpack
really only for webapps?

What is the benefit gained from "code splitting"? Would it make a blog run
faster? What if the largest amount of JS on your site is 5k? Why would there
be a need to code split this?

~~~
slig
I'm not the parent, but you don't need webpack for something like a WP blog.

Code splitting is great on bigger webapps such as GMail or Facebook. For
instance, when you want to see your contacts on gmail, it can load the
required JS file of that module on demand. Same thing on FB: the chat widget
can be loaded separately, and only if needed.

~~~
RobertRoberts
Thank you, this explains some basic things that seem to be assumed by so many
web devs/blogs/etc... :P

A while back I went through the process of evaluating a lot of build tools,
and I simply couldn't see any benefits of replacing my bash scripts with these
tools, and you cleared it up nicely.

------
fiatjaf
I use Browserify and it works great.

Maybe there are some legitimate cases in which you would prefer Webpack, but I
really don't understand why have EVERYBODY migrated to Webpack, with all its
bloat and breaking changes and build errors and boilerplate.

~~~
frou_dh
I'm happy with ES5 + npm + browserify.

Just bundling. No lang->lang transpiling or asset munging.

~~~
haroldf
Use whatever works.

------
simooooo
Emoji in the first title? Emoji in every damn title?

Are children developing webpack?

~~~
crbelaus
After reading the title this was exactly my first thought.

Polluting the titles with emojis feels unnecessary and childish to me. I them
a mental burden that makes it difficult to read the important information. I
can not imagine a new car announcement page filled with emojis and I don't
know why it should be different for software.

~~~
Latty
I must admit, as I searched, I didn't think I'd find something so on-point:
[http://media.gm.com/content/dam/Media/images/US/Release_Imag...](http://media.gm.com/content/dam/Media/images/US/Release_Images/2015/06-2015/Cruze/Chevrolet_MediaAlert_10_MOL.jpg)

~~~
oblio
I always figured the Egyptians were wrong, with the hieroglyphics. It seems
Chevrolet is proving me right :)

------
baybal2
Shameless promotion

[https://rollupjs.org](https://rollupjs.org) \- JS module loader with tree
shaking and async loader that works out of the box.

Asynchronous loading and code

Take a try if webpack takes toll on your productivity

~~~
degurechaff
well, I think 2018 is the year of parceljs...

grunt -> gulp -> browerify -> webpack -> parcel?

~~~
avarun
Now when did this come out?

~~~
RobertRoberts
Yesterday, are you behind already on the newest trend? Best get cracking
moving all your projects to the newest and bestest!

~~~
ausjke
I actually must use Parcel these days to avoid being left-out, joke aside,
Parcel is extremely easy to use, I spent 10 minutes to read the instructions
and one article about how to use it, and have been using it ever since

