
What's New in Webpack 2 - scorchio
https://gist.github.com/sokra/27b24881210b56bbaff7
======
nathancahill
Huge. Between webpack and Babel, JS is quickly progressing towards becoming a
powerful language that is easy to write, read and reason about. I'm currently
in the process of moving an inherited "minified by hand" codebase to ES6, and
the difference is incredible. Not only are linters catching hundreds of
previously unknown edge cases and bugs, but the end result is more performant
and smaller in file size. It's very satisfying, makes me not mind coding in JS
again.

~~~
DCoder
Have you looked into TypeScript? Type system helps you catch even more errors.

~~~
Sir_Cmpwn
Since adopting Redux, I've not seen many advantages of TypeScript. My codebase
is just pure functions that describe simple state objects. What sort of
advantages do I stand to gain by bringing in TS in this situation?

~~~
s986s
When implementing overloaded functions, explicitly defining an interface would
allow for much easier debugging than testing it afterwards. Running tests
(that can take up to seconds sometimes) is far less efficient than seeing the
problem nearly immediately

------
bshimmin
What's the current thinking as of 2016 about Browserify versus Webpack? We've
been happy Browserify users for a couple of years now, but I'm drawn to both
the code splitting and dynamic expressions parts of Webpack.

On the other hand, I'm not keen on introducing more complexity or changing
things just to be "fashionable", and Browserify, Babel, and Gulp do work
together reasonably well for us (though I didn't much enjoy getting it all
working in the first place, and I'm always nervous about updating any of
them).

~~~
Chris_Newton
I think Browserify is an excellent tool. It does the one job I generally need
it to, importing dependencies so I can write modular JS code. Running it is a
one-liner, and running it with Babel is one extra option. Its behaviour is
reasonably transparent, so you can look at the actual output and see what is
really going on even if source maps aren’t helping for whatever reason.

Personally, I’m not such a fan of Webpack. It trips my “too complicated”
alarm, like RequireJS before it. I’ve never worked on a project that needed
the kind of dynamic behaviour these tools support, and you pay a price for
that flexibility in the complexity of the tool and the output it produces.
Likewise, while you can include almost anything as part of your bundled JS
output with Webpack, I’ve seen few real world cases where this is a
significant advantage, and again you get locked into Webpack and its
complexity as the downside. Perhaps on some types of project the features
Webpack offers represent more compelling benefits.

For perspective, I’m also not a fan of tools like Gulp, also on the grounds
that their ecosystems tend to be fragile and they add unnecessary complexity
to what is usually a pretty simply operation in the first place.

~~~
s986s
I selfishly want more people like you in the javascript ecosystem. I had a
debate with a freind if mine about gulp. My argument is that all of these
tools are useless since they can be done without them. If only certian tasks
should be run, create a commander script that takes in amount of args and runs
each of those tasks.

His argument is that these gulp and grunt files standardize build and test
scripts. Now its something you can definitively check off a list and when
looking at others code have a form of familiarity.

I personallt agree, complexity and extra wrappers around what is already
working makes little sense. But there are reasons these types of frameworks
exist

~~~
Chris_Newton
I guess I just don’t see what benefit is gained by writing a dozen lines of
fragile boilerplate to run Browserify via Gulp. If you want to put the build
automation in a well-known location, a typical Browserify+Babel build is _one
line_ in the scripts section in package.json that says something like

    
    
        "js": "browserify src/index.js -o dist/index.js -t [ babelify --presets [ es2015 ] ]"
    

If you need more complicated configuration, you can use separate sections of
package.json to set useful defaults, which is also the common convention for
build tools in the Node/NPM ecosystem.

~~~
s986s
Again, I agree. Picture this: mocha gives testing globals, browser offers the
window and dom, node offers process arguments. Coming from a partial teachers
perspective (well, I wasnt hired to teach but I did talk to the students alot)
gulp seemed to offer comfort and order in a world where "you can do anything"
seems to cause imobilization. That problem I believe can be solved through
introducing students to a philosophy of "you are in control, machines are
dumb, only google can save you" but I can see where seperation makes people
much more comfortable

------
octref
What's needed for Webpack 2: better documentation.

~~~
matt4077
Indeed! I gave up trying to configure it to load files relative to the root
and just lived with all the import '../../../lib/compents/...'.

I just tried the new beta and – surprise – it works!

I still think the structure of, say, Grunt is much nicer to work with – it's
just code and easy to understsand & modify. Webpack has what must be the most
awkward configuration file format currently in use.

The website also looks like it's from the late 90ies, but I guess that's not
too important.

Apparently, it produces better output :(

~~~
tobz
This was definitely confusing at first for me, too, but with a little work,
you can clean up your imports/requires with just a few lines:
[https://github.com/tobz/scryer/blob/master/webpack.config.js](https://github.com/tobz/scryer/blob/master/webpack.config.js)

Note the resolve section. I have mine rooted at either app or node_modules,
and I have some basic extensions set up. This lets me require something like
'components/CardBinder', which ends up then mapping to
'app/components/Cardbinder.jsx'.

It ends up working nicely and lets me forget about precisely what type of
thing I'm importing, instead focusing on the fact that I'm simply importing
some resource, period.

------
julenx
Hm, I'm not sure about having to pull in a Promise polyfill to support code
splitting (`require.ensure()`) in IE11... If I'm already using a promises
library from X, would it be possible to somehow instruct webpack use that?
Does that make sense? Am I missing something?

~~~
stevenrossuk
You would have to make the Promise object from your choosen promise library
global before any calls to require.ensure.

------
sotojuan
For me the big thing in this version is tree shaking. I think it will change
usage of JS stuff more than most people think. For example, I will use Cycle
more because currently I feel bad importing all of RxJS for my toy projects.

------
sandGorgon
has anyone used systemjs + jspm here ? I inherited a codebase using jspm (due
to the override registry system that works great with legacy javascript
packages - like Handsontabe) and am wondering about webpack.

~~~
pgz
We are using jspm on an inherited codebase that was concatenated "by hand"
with Rails' asset-pipeline (it has lots of old libraries and the overrides are
very good to handle them).

What we hate is jspm is extremely slow in development for us. There are two
main causes:

    
    
      - The amount of xhr. This is solvable with http2's server push (but
        our dev server is in Ruby, and there's no http2 webserver yet).
      - Apparently jspm doesn't cache the result of Babel's compilation,
        so for each page refresh every file has to be recompiled again.
    

We will look at Webpack2 when it's released, if it allows us to use these
legacy libraries and wins us some development speed we will not look back.

~~~
hardwaresofton
Do you have cache disabled?

Also, how long does your actual bundle time take? For small projects, I
actually get away with just triggering the bundle command when appropriate
files in the project change. I highly doubt it would work for you, but if
you're spending 10 seconds waiting for stuff to come in over the network, and
your bundle command runs in 5, you could just do that instead, and actually
work with the bundled code (and generated source map)

Looks like I'm not the only one who thinks it's sometimes a good idea:
[https://60devs.com/optimizing--default-jspm-workflow-with-
gu...](https://60devs.com/optimizing--default-jspm-workflow-with-gulp-and-
nginx.html)

~~~
ravicious
I think JSPM should stress the part about bundling. It's the second person
that I see who says "JSPM is slow" and the reason behind this slowness is that
they didn't bundle the files or bundled them incorrectly.

We do the same in our project: we bundle all the 3rd party libs when they
change, so only our own code gets retranspiled on each page load. During
deployment, we bundle all the JS in a single bundle (which is good for us, as
we don't have too much JS in that project).

~~~
darkmagnus
Any chance you can go into detail how you bundle your 3rd party dependencies
separately? I have tried that, without much luck.

~~~
true_religion
For me it's like this:

> jspm bundle app/ __/ * - [app/ __/ *] js/tmp/dependency-bundle.js --inject
> --no-runtime

That tells JSPM to bundle everything except your application if your app lives
within the app/ directory.

> jspm bundle babel js/tmp/bundles/babel.js --inject --skip-source-maps
> --minify

This tells it to bundle the Babel dependencies which aren't considered in the
above.

------
rco8786
I'm really curious about the decision to support es6 modules here. Seems like
Webpack is stepping into Babel's territory, but I'm not sure to what end?

------
ry_ry
Huh, they've pulled es6 compilation in, away from babel?

It's early in the morning here so my pre-coffee brain might be terrible, but
did they say which compilation engine they were using for es6?

~~~
amasad
ES6 modules support are now baked into Webpack, which makes sense because
that's supposed to be it's primary concern. Any other feature you'd still need
to use Babel.

~~~
ry_ry
Yeah I saw that, I was more curious as to whether they had said anything about
using a pre-existing compiler, or if they had built their own.

------
quaffapint
For people in corporate environments that can't run webpack/browserify are
there any standalone tool alternatives?

------
sdnguyen90
Is tree shaking still planned for this version?

~~~
Sheepsteak
Yeah, it's in there.

[http://www.2ality.com/2015/12/webpack-tree-
shaking.html](http://www.2ality.com/2015/12/webpack-tree-shaking.html)

------
k__
I tries cycle.js the other day and had to use some webpack.

Seems like npms default webpack Version is some 2.0 beta?!

Somehow requires in scoped modules didn't work with it ans I searched about n
hour for an solution till I saw that the webpack devs seem to consider a beta
a good 'default' Version....

Going back do 1.12.12 helped.

I love npm D:

~~~
wildpeaks
It may have been temporary because right now the default version it installs
is 1.12.12

