8 ms·

What's New in Webpack 2

147 points by scorchio 11y ago

nathancahill 11y ago
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 11y ago
  Have you looked into TypeScript? Type system helps you catch even more errors.
  - seivan 11y ago
    Second this. There is no reason not to use TypeScript now that's easier to work with .jsx and add 3:rd party libraries without dealing with type definitions. Also, make sure to try out atom-typescript by Basarat. It's genuinely amazing and feels like Swift. :)
    - egeozcan 11y ago
      Another supporter here. I was very reluctant at the beginning but after seeing how it helped catch bugs earlier, I can't go back. I actually think that TypeScript makes JS more flexible because of the patterns it enables. I enjoy it even more than C#.
  - Keats 11y ago
    Another vote, catches so many errors and if decide to refactor you can pretty much just follow the compiler errors till it compiles.
  - k__ 11y ago
    Why not purescript or elm? I have the feeling that those Haskell like type-systems are superior to this whole Java/C# stuff.
    - Keats 11y ago
      Well those 2 are entirely new languages, not just javascript with types added so they are not the same thing. Not everyone knows or want to learn Haskell
    - Matthias247 11y ago
      I would guess that compatibility with existing JS libs is far easier with Typescript. You can trivially consume an existing JS lib from TS or export/compile your TS lib to pure JS, which other JS then can seamlessly consume. Although I don't have bigger experience with Elm, Purescript, Scala.js, Ceylon, Websharper & Co I guess its more complicated with them. An advantage here is also that Typescript does not bring along it's own standard library (e.g. new collection types) which could cause problems on interoperability. Another advantage is getting other people on board. Getting developers from pure JS to typescript is not difficult, especially when they are used to Java/C++/C# (which most developers are). The learning curve for the other languages will be higher for most developers.
  - Sir_Cmpwn 11y ago
    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?
    - deleted 11y ago
      [deleted]
    - s986s 11y ago
      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
ry_ry 11y ago
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 11y ago
  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 11y ago
    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.
  - wildpeaks 11y ago
    I wish Node supported ES6 modules without transpilation as well
sdnguyen90 11y ago
Is tree shaking still planned for this version?
- Sheepsteak 11y ago
  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
sandGorgon 11y ago
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 11y ago
  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 11y ago
    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-gulp-and-nginx.html https://60devs.com/optimizing--default-jspm-workflow-with-gu...
    - ravicious 11y ago
      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).
bshimmin 11y ago
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).
- hakanderyal 11y ago
  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.
- maxthegeek1 11y ago
  Browserify also has code splitting https://github.com/substack/factor-bundle https://github.com/substack/factor-bundle and hot module reloading https://github.com/AgentME/browserify-hmr https://github.com/AgentME/browserify-hmr
  - alessioalex 11y ago
    Browserify is so much easier to understand and interact with, I'm sticking with it as well.
    - egeozcan 11y ago
      I've been a huge fan but the fact that it's very less opinionated enabled me to ruin my build workflow too often. Now a happy webpack user.
julenx 11y ago
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 11y ago
  You would have to make the Promise object from your choosen promise library global before any calls to require.ensure.
- b34r 11y ago
  global.Promise = global.Promise || require('promise-pollyfill'); Something like that in your entry file.
k__ 11y ago
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 11y ago
  It may have been temporary because right now the default version it installs is 1.12.12
octref 11y ago
What's needed for Webpack 2: better documentation.
- DanitaBaires 11y ago
  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/ http://survivejs.com/webpack_react/developing_with_webpack/
- matt4077 11y ago
  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 11y ago
    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.
  - true_religion 11y ago
    I made my way through it, but in the end I went with JSPM because of the ES6 imports, and the fact that it handles installs from NPM and automatically adds it to the dependency list for you. It feels much more seamless than webpack.
sotojuan 11y ago
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.
- deleted 11y ago
  [deleted]
rco8786 11y ago
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?
quaffapint 11y ago
For people in corporate environments that can't run webpack/browserify are there any standalone tool alternatives?

147 points by scorchio 11y ago

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 11y ago
Have you looked into TypeScript? Type system helps you catch even more errors.
- seivan 11y ago
  Second this. There is no reason not to use TypeScript now that's easier to work with .jsx and add 3:rd party libraries without dealing with type definitions. Also, make sure to try out atom-typescript by Basarat. It's genuinely amazing and feels like Swift. :)
  - egeozcan 11y ago
    Another supporter here. I was very reluctant at the beginning but after seeing how it helped catch bugs earlier, I can't go back. I actually think that TypeScript makes JS more flexible because of the patterns it enables. I enjoy it even more than C#.
- Keats 11y ago
  Another vote, catches so many errors and if decide to refactor you can pretty much just follow the compiler errors till it compiles.
- k__ 11y ago
  Why not purescript or elm? I have the feeling that those Haskell like type-systems are superior to this whole Java/C# stuff.
  - Keats 11y ago
    Well those 2 are entirely new languages, not just javascript with types added so they are not the same thing. Not everyone knows or want to learn Haskell
  - Matthias247 11y ago
    I would guess that compatibility with existing JS libs is far easier with Typescript. You can trivially consume an existing JS lib from TS or export/compile your TS lib to pure JS, which other JS then can seamlessly consume. Although I don't have bigger experience with Elm, Purescript, Scala.js, Ceylon, Websharper & Co I guess its more complicated with them. An advantage here is also that Typescript does not bring along it's own standard library (e.g. new collection types) which could cause problems on interoperability. Another advantage is getting other people on board. Getting developers from pure JS to typescript is not difficult, especially when they are used to Java/C++/C# (which most developers are). The learning curve for the other languages will be higher for most developers.
- Sir_Cmpwn 11y ago
  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?
  - deleted 11y ago
    [deleted]
  - s986s 11y ago
    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

ry_ry 11y ago

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 11y ago
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 11y ago
  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.
- wildpeaks 11y ago
  I wish Node supported ES6 modules without transpilation as well

sdnguyen90 11y ago

Is tree shaking still planned for this version?

Sheepsteak 11y ago
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

sandGorgon 11y ago

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 11y ago
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 11y ago
  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-gulp-and-nginx.html https://60devs.com/optimizing--default-jspm-workflow-with-gu...
  - ravicious 11y ago
    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).

bshimmin 11y ago

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

hakanderyal 11y ago
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.
maxthegeek1 11y ago
Browserify also has code splitting https://github.com/substack/factor-bundle https://github.com/substack/factor-bundle and hot module reloading https://github.com/AgentME/browserify-hmr https://github.com/AgentME/browserify-hmr
- alessioalex 11y ago
  Browserify is so much easier to understand and interact with, I'm sticking with it as well.
  - egeozcan 11y ago
    I've been a huge fan but the fact that it's very less opinionated enabled me to ruin my build workflow too often. Now a happy webpack user.

julenx 11y ago

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 11y ago
You would have to make the Promise object from your choosen promise library global before any calls to require.ensure.
b34r 11y ago
global.Promise = global.Promise || require('promise-pollyfill'); Something like that in your entry file.

k__ 11y ago

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 11y ago
It may have been temporary because right now the default version it installs is 1.12.12

octref 11y ago

What's needed for Webpack 2: better documentation.

DanitaBaires 11y ago
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/ http://survivejs.com/webpack_react/developing_with_webpack/
matt4077 11y ago
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 11y ago
  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.
- true_religion 11y ago
  I made my way through it, but in the end I went with JSPM because of the ES6 imports, and the fact that it handles installs from NPM and automatically adds it to the dependency list for you. It feels much more seamless than webpack.

sotojuan 11y ago

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.

deleted 11y ago
[deleted]

rco8786 11y ago

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?

quaffapint 11y ago

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