What's New in Webpack 2

[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.

[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.

[hakanderyal]

I was in the same boat in 2015, happily using a hacked-together solution of gulp-babel-browserify that took a few days to set up correctly. Than, after hearing about it enough, I decided to give webpack a try.

After a few hours of learning, I've succesfully set up webpack with hot module reloading and some other niceties. It was certainly much more cleaner than my old solution.

I'm a webpack user since than. It's easier to understand and easier to upgrade for me.

I didn't really took time to understand browserify, just enough to get me working, and I was an inexperienced JS developer at that time, which may explain why my first solution was hacky. But I still believe Webpack's architecture allows a cleaner and more understandable solution.

[fuzionmonkey]

I prefer browserify because of its emphasis on node compatibility, first and foremost. I think this narrower scope is a strength because as a result, browserify is super simple to use, works without config, and has a surprisingly small, readable implementation. Seriously, read the browserify source.

[maxthegeek1]

Browserify also has code splitting

https://github.com/substack/factor-bundle

and hot module reloading

https://github.com/AgentME/browserify-hmr

[octref]

What's needed for Webpack 2: better documentation.

[DanitaBaires]

I strongly agree. I had to set up a React application not so long ago and the Webpack docs were completely useless. I ended up following a step by step guide made by someone else, which was really easy to follow and reason about: http://survivejs.com/webpack_react/developing_with_webpack/

[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 :(

[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.

[b34r]

global.Promise = global.Promise || require('promise-pollyfill');

Something like that in your entry file.

[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.

[hardwaresofton]

I regularly use JSPM (with systemJS) for new projects, and I've liked it a lot.

Back when webpack first came out, I struggled a little bit with figuring out what it actually did. While I understand now, I am not why I would want to (or you) switch from JSPM to webpack. I don't see any features that webpack has that JSPM doesn't (and JSPM offered ES6 support well before of course, with babel on by default).

I like to use JSPM because of how relatively easy everything fits together -- and how straightforward it is to use and configure.

For those not familiar, JSPM is a package manager, module bundler, and module loader all in one for javascript applications.

This means you can:

  jspm install <package>

And JSPM will look in NPM/Github (and it's possible to add registries, like bower) for stuff . That's the package management facet.

  jspm bundle-sfx js/main dist/build.js

Bundle your code all together, and drop it in a file

  <import src="system.js">
  <script>
    // set our baseURL reference path
    System.config({
      baseURL: '/app'
    });

    // loads /app/main.js
    System.import('main.js');
  </script>

Load your modules on the fly like you would with something like RequireJS.

As you may have guessed, JSPM relies on SystemJS (https://github.com/systemjs/systemjs) internally for some of the features above.

This video really opened my eyes to what it could do: https://www.youtube.com/watch?v=iukBMY4apvI

[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.

[circlingthesun]

I'm using SystemJs + JSPM and it's awesome. I previously made use of bower + requirejs. I love how JSPM automatically populates the config.js file so I can start importing whatever I installed straight away. SystemJS loads pretty much any module format so it was easy to use AMD modules while I was migrating to CommonJS. I recently moved over to ES6 modules without having to touch my SystemJS/JSPM config. I've not really looked into Webpack. It seems to be more popular than SystemJS. When I was considering it, the docs were not that great.

[pdeva1]

we looked at jspm and switched to webpack. detailed comparison here: http://blog.dripstat.com/why-we-switched-from-jspm-to-webpac...

[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.

[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

[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