8 ms·

Webpack 3: Official Release

97 points by daviddumon 9y ago

GlennS 9y ago
Having gone through script tags -> Browserify -> Webpack, I now have the sneaking suspicion that Google's Closure compiler was the right thing all along, and that I should have learned that to begin with.
elmigranto 9y ago
Every time I start a new project, I try using latest webpack first. Result is always me getting frustrated and replacing it with simple `browserify` call with couple of `--transform` flags. Recently I tried bootstrapping it with `create-react-app` and ejecting, so I can modify webpack config. `yarn start` kept linting something deep inside `node_modules`, and failing for some nefarious reason even after linting step was removed completely from everywhere I could reach. `build` command work fine, though, so go figure. Not sure if "magic comments" will solve my problem, but it surely is nice to have simple alternative, thanks substack and everyone behind browserify! https://github.com/substack/node-browserify https://github.com/substack/node-browserify
- manigandham 9y ago
  webpack is just more complicated, which means it takes longer to start - it also has some bad naming and quirks which happens when design-by-committee decisions take place. the webpack book by survivejs takes a few hours to read completely, or an hour to read the important parts, and you'll be very comfortable with it. https://leanpub.com/survivejs-webpack https://leanpub.com/survivejs-webpack or https://survivejs.com/webpack/preface/ https://survivejs.com/webpack/preface/
  - daviddumon 9y ago
    I second this recommandation. This book was really a good help setting up webpack for the first time.
  - teknologist 9y ago
    It's so horrendously complex. I can already sense the "you-dont-need-webpack" wiki page being made by some pissed off developer out there!
    - mkohlmyr 9y ago
      It really is. Back when I was trying to get excited about learning yet another way to bundle things (YAWTBT(TM)) I attended two tech talks that concerned webpack. I really wanted to 'get it'. I left the second one having decided to never touch it again if avoidable. The first was by a developer who had recently moved a sizable codebase to webpack. He had pages after pages of graphs of how he had tuned webpacks code splitting capabilities. The end result of all this work was actually a larger sum of file sizes - and a slower loading speed. But I guess those days / weeks of tuning shave off a few kB when they deploy minor changes. The second talk was by one of the primary maintainers of webpack. It was completely incoherent. It was a jumble of things that "can be done with webpack" - not one good reason why. E.g. "You can extract CSS from your javascript files with this plugin" - what genius came up with the idea of inlining styles in a javascript bundle to begin with?
      - deleted 9y ago
        [deleted]
      - fenomas 9y ago
        > what genius came up with the idea of inlining styles in a javascript bundle to begin with? I do this in a project and it's terrific. The JS files in question are front-end components (for Vue.js in my case), and the point of having the styles inline is so that components can be a single file, styles can be prefixed to be local to that component, and so on. It's light-years easier to work with than trying to do something similar without a module bundler.
        nobleach 9y ago
        Because there are instances where one doesn't want to block rendering with large CSS file downloads? For above the fold content, inlining makes perfect sense.
  - bicubic 9y ago
    > the webpack book Holy shit, I thought you were kidding. We're at a point where the bundler, one of a dozen elements required for a 'barebones' modern js application, needs a book. I'm finding it hard to find motivation to do any kind of web based side projects these days because they inevitably begin with 'which combination of latest and greatest libraries do I need to spend an entire day wiring up before I can do hello world this time?'. Someone make this madness end. Modern javascript tooling makes 90s C++ look pretty pleasant.
    - baystep 9y ago
      Have you ever tried Gulp? Honestly I had the same feeling with webpack, I like it for my "professional" day job project that's grown to huge size and webpack can chop through it quickly; but for side projects, probably not. Then I found gulp. Uses a more functional streaming style, but for the end goal of [Turn ES6 into ES5]->[Stick it in this folder] it's dead simple and quick.
    - positivecomment 9y ago
      JavaScript is trying to get rid of the script! https://www.manning.com/books/java-development-with-ant https://www.manning.com/books/java-development-with-ant
    - Sacho 9y ago
      I think your hyperbole is unwarranted; if you're building a "hello world" application, you don't need to use a bundler, or any of the "latest and greatest libraries". Pick tools which you are comfortable with and which solve problems you actually have. Otherwise, you'll be left complaining about some vague "community" that is "forcing" you to adopt the "modern standard", even though there's nothing "standard" about the apps this "community" develops as a whole.
      - susw 9y ago
        Hello World is only your first test case to get all the tooling up and running. The real work starts after Hello World and is expected to become more complex. Within minutes you will grow tired of manually running transpilers, minifiers, tests, adding each new js module to index.html etc. You will want to automate all of this. At least this is my experience every time I start a new project.
- teknologist 9y ago
  Would you mind posting an example of such a browserify call for someone who isn't too familiar?
  - elmigranto 9y ago
    Here's my Makefile, which includes all the configuration: react, babel, etc. (I do not have any dotfiles in root except for linter). `watch` recompiles on changes and has sourcemaps. You can require any node modules and calls to `fs.readFileSync` will be replaced with `Buffer` objects. NODE_MODULES=../../node_modules NODE_BINARIES=${NODE_MODULES}/.bin BABEL_PRESETS=--presets [ es2017 react ] BABEL_PLUGINS=--plugins [ transform-object-rest-spread ] FLAGS= \ --transform [ babelify ${BABEL_PLUGINS} ${BABEL_PRESETS} ] \ --transform brfs \ --outfile ../../public/bundle.js \ entrypoint.js build: ${NODE_BINARIES}/browserify ${FLAGS} watch: ${NODE_BINARIES}/watchify --debug --verbose ${FLAGS} What it doesn't have is any kind of automatic page reload or code swap and you can't `require` non-js files. There is also no minification for production build. I believe you can have those after couple of minutes on npm, but I haven't tried. Dependencies: yarn add --dev browserify watchify babelify babel-plugin-transform-object-rest-spread babel-preset-es2017 babel-preset-react brfs
    - Yaggo 9y ago
      For minification you can use e.g. uglifyify transform. Envify also comes in handy. I'm big fan of browserify & npm scripts, I love the simplicity.
- just-boris 9y ago
  > I tried bootstrapping it with `create-react-app` and ejecting, so I can modify webpack config I am pretty much confident that everything worked well before you have made any modifications in the webpack config. So, the negative effects, that you are describing after, is a result of your efforts, but not anybody else. And why did you want to eject in the first time? Most popular use-cases are already covered into create-react-app by default.
skrebbel 9y ago
In semver land, every major release is a tragedy. I love that they're really doing hard (and free!) work to make the transition as smooth as possible, but I still wish the JS ecosystem culture would be more conservative about releasing breaking changes.
- coffeedoughnuts 9y ago
  From the article: Migrating from webpack 2 to 3, should involve no effort beyond running the upgrade commands in your terminal. We marked this as a Major change because of internal breaking changes that could affect some plugins. So far we’ve seen 98% of users upgrade with no breaking functionality at all
  - skrebbel 9y ago
    Your point being? The plugin interface is a public interface too, right? Again, I really appreciate all the work done to make this smooth, but there's still a little underlying "compatibility matters less than features" sentiment here.
    - nilliams 9y ago
      > The plugin interface is a public interface too, right? It didn't say 'plugin interface'. It said 'internal changes' that could affect some plugins. The way I read that is some plugins could be relying on internals (that they technically shouldn't, they may have good reason ofc).
cytzol 9y ago
My favourite part of the Webpack 1->2 transition was when they updated their old documentation to say that Webpack 1 was deprecated [0], but failed to mention if the user was currently looking at the Webpack 1 docs or the Webpack 2 docs! I ended up reading the Webpack 1 documentation for several weeks after 2 came out. I'd see the warning, go "oh, I better not use Webpack 1 then", and continue reading its docs. Cue lots and lots of head scratching. Webpack developers: if you're going to release a new set of documentation for 3, then please, please make this clear. [0]: For example, https://webpack.github.io/docs/code-splitting.html https://webpack.github.io/docs/code-splitting.html. "webpack v1 is deprecated. We encourage all developers to upgrade to webpack 2." There's a link, sure, but I didn't follow it because I had no reason to think I wasn't already on the Webpack 2 docs page. grumble grumble
- positivecomment 9y ago
  Me too. I was shouting "dude, I literally copy pasted you from the docs, you HAVE TO work" at my screen. I'm glad they are focusing on the ease-of-use. Otherwise, we really would start hiring webpack-developers. Sometimes I wonder how it would have been if I sticked to Browserify.
- sschueller 9y ago
  Sounds like the varnish docs. https://varnish-cache.org/docs/5.1/users-guide/vcl-grace.html https://varnish-cache.org/docs/5.1/users-guide/vcl-grace.htm... would indicated valid config for 5.1 but in fact "fetch" in a "vcl_hit" is not a valid response in 5.1. Should be "miss"
- rukuu001 9y ago
  Thank God I wasn't the only one. I was having one of those 'am I taking crazy pills' moments before I clicked. For a tool with arcane concepts and config, the docs mixup was the cuckoo icing on the cake.
- simon83 9y ago
  When I google for "webpack someproblem" then the the first results are usually pointing to the webpack 1 docs. I often don't even find documentation for webpack 2 on the first page, unless I explicitly search for "webpack 2". It took me some time, but now I'm always appending the version number to all my searches. I think Angular has/had the same problem. Edit: and luckily it's easy to discern the webpack docs: v1 docs look ugly and are lacking information, v2 docs look much nicer and are more detailed ;) They did a great job so far improving the documentation.
hoodoof 9y ago
Thanks to the Webpack people for focusing on ease of use, ease of migration and avoiding breaking changes. react-router has recent gone from version 3 to version 4, which is essentially a completely new and almost unrelated piece of software to V3 and requires a major rearchitecture of your application to make the transition. In effect it is one big breaking change.
- aocvr 9y ago
  Upgrading from 3 to 4 is not required. Version 3 is still maintained. It's not ideal since there will probably be no future major 3 versions, but no one is forced to make a 'big breaking change' strictly speaking. > We intend to keep supporting the 3.x branch indefinitely (published separately on npm to aid in migration), although there will likely not be any future major versions based on that code. 4.0 is the future, but we won't leave you hanging if you want to stick with 2.x/3.x. https://github.com/ReactTraining/react-router/releases/tag/v4.0.0-0 https://github.com/ReactTraining/react-router/releases/tag/v... Previously discussed here: https://news.ycombinator.com/item?id=12511419 https://news.ycombinator.com/item?id=12511419
  - tchow 9y ago
    4.0 is a regression imo. The docs say that if you do server side rendering with code splitting then 'God Speed' (their words not mine). I don't see the benefit of switching if v3 allowed me to ssr and code split while v4 doesn't allow me to do both. From the user pov it went from instantly displayed page with minimal js required to choosing one of those options. What benefits could exist that supercede giving the user the best possible experience? (Genuine question). I can't imagine huge speed gains going from one page to the next from this change and indeed changing pages in SPAs are essentially instant. So what could possibly be better that makes it worth getting rid of ssr and code splitting? Imo I won't be using react-router in future products because they are too fickle with their codebase.
    - jazoom 9y ago
      This was the madness that finally pushed me over the edge and towards Vue about 8 months ago. No regrets here!
kakarot 9y ago
Nice, I noticed the push earlier tonight on github and tried upgrading to 3.0 in the project I was working on, but I guess it was a little too soon and I ran into dependency errors. Here's to hoping that we see a performance increase instead of a performance decrease as was the case with 2.0.
finchisko 9y ago
I'm kind of surprised how cold reactions are against Webpack here on HN. I consider Webpack by far the best module bundler. My path was: scripts, stealjs, requirejs, requirejs + grunt and also recently tried SystemJS. All of them are pretty awful. Try one of those and you'll realize how amazing Webpack is. For example one of the newer bundler - SystemJS pretty much force you to use jspm package manager. Jspm changes SystemJS configuration on every new package installation, so you can be never sure, if build is failing because jspm changed something. You can forget on imports without providing correct extensions (js,jsx,...), or prepare to fill you config will lot of defaultJSExtensions/file mapping. Also import Module from './module where module is folder with index.js file doesn't work out of the box and mapping has to be added. etc... The only thing I'm personally missing in webpack, is option to provide custom chunk loader, so I can load chunks with any other AMD loader, something similar to requirejs+almodjs or SystemJS static SFX builds, which was the reason I've tried SystemJS at first place, but it wasn't worth the pain.
- beefsack 9y ago
  I use Webpack in a couple of projects, but it only seems to fit well for single page applications that fit their near-standard configurations. We tried to replace Gulp with it at work for some relatively complex software but it was an absolute nightmare; Webpack is highly opinionated and to get it to build multiple different targets with different configurations requires jumping through a lot of hoops or worse, having to have separate Webpack configs and different build commands for each different asset target. The last straw for us was how messy it got trying to build our LESS at the same time. Packaging all the LESS into your compiled JS, then having to extract it to put it in other files is absolutely ridiculous.
  - finchisko 9y ago
    That is something I forgot to mention. Webpack is great for SPAs and not so great for classic site with lot of html files. You can have multiple entries (html files), but share common chunks between them might be difficult in some special cases.
deleted 9y ago
[deleted]
daliwali 9y ago
I used both and still prefer Browserify. No configuration required, it just does what you want. Also its source code is quite short and easy to grok.

97 points by daviddumon 9y ago

Having gone through script tags -> Browserify -> Webpack, I now have the sneaking suspicion that Google's Closure compiler was the right thing all along, and that I should have learned that to begin with.

elmigranto 9y ago

Every time I start a new project, I try using latest webpack first. Result is always me getting frustrated and replacing it with simple `browserify` call with couple of `--transform` flags. Recently I tried bootstrapping it with `create-react-app` and ejecting, so I can modify webpack config. `yarn start` kept linting something deep inside `node_modules`, and failing for some nefarious reason even after linting step was removed completely from everywhere I could reach. `build` command work fine, though, so go figure. Not sure if "magic comments" will solve my problem, but it surely is nice to have simple alternative, thanks substack and everyone behind browserify! https://github.com/substack/node-browserify https://github.com/substack/node-browserify

manigandham 9y ago
webpack is just more complicated, which means it takes longer to start - it also has some bad naming and quirks which happens when design-by-committee decisions take place. the webpack book by survivejs takes a few hours to read completely, or an hour to read the important parts, and you'll be very comfortable with it. https://leanpub.com/survivejs-webpack https://leanpub.com/survivejs-webpack or https://survivejs.com/webpack/preface/ https://survivejs.com/webpack/preface/
- daviddumon 9y ago
  I second this recommandation. This book was really a good help setting up webpack for the first time.
- teknologist 9y ago
  It's so horrendously complex. I can already sense the "you-dont-need-webpack" wiki page being made by some pissed off developer out there!
  - mkohlmyr 9y ago
    It really is. Back when I was trying to get excited about learning yet another way to bundle things (YAWTBT(TM)) I attended two tech talks that concerned webpack. I really wanted to 'get it'. I left the second one having decided to never touch it again if avoidable. The first was by a developer who had recently moved a sizable codebase to webpack. He had pages after pages of graphs of how he had tuned webpacks code splitting capabilities. The end result of all this work was actually a larger sum of file sizes - and a slower loading speed. But I guess those days / weeks of tuning shave off a few kB when they deploy minor changes. The second talk was by one of the primary maintainers of webpack. It was completely incoherent. It was a jumble of things that "can be done with webpack" - not one good reason why. E.g. "You can extract CSS from your javascript files with this plugin" - what genius came up with the idea of inlining styles in a javascript bundle to begin with?
    - deleted 9y ago
      [deleted]
    - fenomas 9y ago
      > what genius came up with the idea of inlining styles in a javascript bundle to begin with? I do this in a project and it's terrific. The JS files in question are front-end components (for Vue.js in my case), and the point of having the styles inline is so that components can be a single file, styles can be prefixed to be local to that component, and so on. It's light-years easier to work with than trying to do something similar without a module bundler.
      - nobleach 9y ago
        Because there are instances where one doesn't want to block rendering with large CSS file downloads? For above the fold content, inlining makes perfect sense.
- bicubic 9y ago
  > the webpack book Holy shit, I thought you were kidding. We're at a point where the bundler, one of a dozen elements required for a 'barebones' modern js application, needs a book. I'm finding it hard to find motivation to do any kind of web based side projects these days because they inevitably begin with 'which combination of latest and greatest libraries do I need to spend an entire day wiring up before I can do hello world this time?'. Someone make this madness end. Modern javascript tooling makes 90s C++ look pretty pleasant.
  - baystep 9y ago
    Have you ever tried Gulp? Honestly I had the same feeling with webpack, I like it for my "professional" day job project that's grown to huge size and webpack can chop through it quickly; but for side projects, probably not. Then I found gulp. Uses a more functional streaming style, but for the end goal of [Turn ES6 into ES5]->[Stick it in this folder] it's dead simple and quick.
  - positivecomment 9y ago
    JavaScript is trying to get rid of the script! https://www.manning.com/books/java-development-with-ant https://www.manning.com/books/java-development-with-ant
  - Sacho 9y ago
    I think your hyperbole is unwarranted; if you're building a "hello world" application, you don't need to use a bundler, or any of the "latest and greatest libraries". Pick tools which you are comfortable with and which solve problems you actually have. Otherwise, you'll be left complaining about some vague "community" that is "forcing" you to adopt the "modern standard", even though there's nothing "standard" about the apps this "community" develops as a whole.
    - susw 9y ago
      Hello World is only your first test case to get all the tooling up and running. The real work starts after Hello World and is expected to become more complex. Within minutes you will grow tired of manually running transpilers, minifiers, tests, adding each new js module to index.html etc. You will want to automate all of this. At least this is my experience every time I start a new project.
teknologist 9y ago
Would you mind posting an example of such a browserify call for someone who isn't too familiar?
- elmigranto 9y ago
  Here's my Makefile, which includes all the configuration: react, babel, etc. (I do not have any dotfiles in root except for linter). `watch` recompiles on changes and has sourcemaps. You can require any node modules and calls to `fs.readFileSync` will be replaced with `Buffer` objects. NODE_MODULES=../../node_modules NODE_BINARIES=${NODE_MODULES}/.bin BABEL_PRESETS=--presets [ es2017 react ] BABEL_PLUGINS=--plugins [ transform-object-rest-spread ] FLAGS= \ --transform [ babelify ${BABEL_PLUGINS} ${BABEL_PRESETS} ] \ --transform brfs \ --outfile ../../public/bundle.js \ entrypoint.js build: ${NODE_BINARIES}/browserify ${FLAGS} watch: ${NODE_BINARIES}/watchify --debug --verbose ${FLAGS} What it doesn't have is any kind of automatic page reload or code swap and you can't `require` non-js files. There is also no minification for production build. I believe you can have those after couple of minutes on npm, but I haven't tried. Dependencies: yarn add --dev browserify watchify babelify babel-plugin-transform-object-rest-spread babel-preset-es2017 babel-preset-react brfs
  - Yaggo 9y ago
    For minification you can use e.g. uglifyify transform. Envify also comes in handy. I'm big fan of browserify & npm scripts, I love the simplicity.
just-boris 9y ago
> I tried bootstrapping it with `create-react-app` and ejecting, so I can modify webpack config I am pretty much confident that everything worked well before you have made any modifications in the webpack config. So, the negative effects, that you are describing after, is a result of your efforts, but not anybody else. And why did you want to eject in the first time? Most popular use-cases are already covered into create-react-app by default.

skrebbel 9y ago

In semver land, every major release is a tragedy. I love that they're really doing hard (and free!) work to make the transition as smooth as possible, but I still wish the JS ecosystem culture would be more conservative about releasing breaking changes.

coffeedoughnuts 9y ago
From the article: Migrating from webpack 2 to 3, should involve no effort beyond running the upgrade commands in your terminal. We marked this as a Major change because of internal breaking changes that could affect some plugins. So far we’ve seen 98% of users upgrade with no breaking functionality at all
- skrebbel 9y ago
  Your point being? The plugin interface is a public interface too, right? Again, I really appreciate all the work done to make this smooth, but there's still a little underlying "compatibility matters less than features" sentiment here.
  - nilliams 9y ago
    > The plugin interface is a public interface too, right? It didn't say 'plugin interface'. It said 'internal changes' that could affect some plugins. The way I read that is some plugins could be relying on internals (that they technically shouldn't, they may have good reason ofc).

cytzol 9y ago

My favourite part of the Webpack 1->2 transition was when they updated their old documentation to say that Webpack 1 was deprecated [0], but failed to mention if the user was currently looking at the Webpack 1 docs or the Webpack 2 docs! I ended up reading the Webpack 1 documentation for several weeks after 2 came out. I'd see the warning, go "oh, I better not use Webpack 1 then", and continue reading its docs. Cue lots and lots of head scratching. Webpack developers: if you're going to release a new set of documentation for 3, then please, please make this clear. [0]: For example, https://webpack.github.io/docs/code-splitting.html https://webpack.github.io/docs/code-splitting.html. "webpack v1 is deprecated. We encourage all developers to upgrade to webpack 2." There's a link, sure, but I didn't follow it because I had no reason to think I wasn't already on the Webpack 2 docs page. grumble grumble

positivecomment 9y ago
Me too. I was shouting "dude, I literally copy pasted you from the docs, you HAVE TO work" at my screen. I'm glad they are focusing on the ease-of-use. Otherwise, we really would start hiring webpack-developers. Sometimes I wonder how it would have been if I sticked to Browserify.
sschueller 9y ago
Sounds like the varnish docs. https://varnish-cache.org/docs/5.1/users-guide/vcl-grace.html https://varnish-cache.org/docs/5.1/users-guide/vcl-grace.htm... would indicated valid config for 5.1 but in fact "fetch" in a "vcl_hit" is not a valid response in 5.1. Should be "miss"
rukuu001 9y ago
Thank God I wasn't the only one. I was having one of those 'am I taking crazy pills' moments before I clicked. For a tool with arcane concepts and config, the docs mixup was the cuckoo icing on the cake.
simon83 9y ago
When I google for "webpack someproblem" then the the first results are usually pointing to the webpack 1 docs. I often don't even find documentation for webpack 2 on the first page, unless I explicitly search for "webpack 2". It took me some time, but now I'm always appending the version number to all my searches. I think Angular has/had the same problem. Edit: and luckily it's easy to discern the webpack docs: v1 docs look ugly and are lacking information, v2 docs look much nicer and are more detailed ;) They did a great job so far improving the documentation.

hoodoof 9y ago

Thanks to the Webpack people for focusing on ease of use, ease of migration and avoiding breaking changes. react-router has recent gone from version 3 to version 4, which is essentially a completely new and almost unrelated piece of software to V3 and requires a major rearchitecture of your application to make the transition. In effect it is one big breaking change.

aocvr 9y ago
Upgrading from 3 to 4 is not required. Version 3 is still maintained. It's not ideal since there will probably be no future major 3 versions, but no one is forced to make a 'big breaking change' strictly speaking. > We intend to keep supporting the 3.x branch indefinitely (published separately on npm to aid in migration), although there will likely not be any future major versions based on that code. 4.0 is the future, but we won't leave you hanging if you want to stick with 2.x/3.x. https://github.com/ReactTraining/react-router/releases/tag/v4.0.0-0 https://github.com/ReactTraining/react-router/releases/tag/v... Previously discussed here: https://news.ycombinator.com/item?id=12511419 https://news.ycombinator.com/item?id=12511419
- tchow 9y ago
  4.0 is a regression imo. The docs say that if you do server side rendering with code splitting then 'God Speed' (their words not mine). I don't see the benefit of switching if v3 allowed me to ssr and code split while v4 doesn't allow me to do both. From the user pov it went from instantly displayed page with minimal js required to choosing one of those options. What benefits could exist that supercede giving the user the best possible experience? (Genuine question). I can't imagine huge speed gains going from one page to the next from this change and indeed changing pages in SPAs are essentially instant. So what could possibly be better that makes it worth getting rid of ssr and code splitting? Imo I won't be using react-router in future products because they are too fickle with their codebase.
  - jazoom 9y ago
    This was the madness that finally pushed me over the edge and towards Vue about 8 months ago. No regrets here!

kakarot 9y ago

Nice, I noticed the push earlier tonight on github and tried upgrading to 3.0 in the project I was working on, but I guess it was a little too soon and I ran into dependency errors. Here's to hoping that we see a performance increase instead of a performance decrease as was the case with 2.0.

finchisko 9y ago

I'm kind of surprised how cold reactions are against Webpack here on HN. I consider Webpack by far the best module bundler. My path was: scripts, stealjs, requirejs, requirejs + grunt and also recently tried SystemJS. All of them are pretty awful. Try one of those and you'll realize how amazing Webpack is. For example one of the newer bundler - SystemJS pretty much force you to use jspm package manager. Jspm changes SystemJS configuration on every new package installation, so you can be never sure, if build is failing because jspm changed something. You can forget on imports without providing correct extensions (js,jsx,...), or prepare to fill you config will lot of defaultJSExtensions/file mapping. Also import Module from './module where module is folder with index.js file doesn't work out of the box and mapping has to be added. etc... The only thing I'm personally missing in webpack, is option to provide custom chunk loader, so I can load chunks with any other AMD loader, something similar to requirejs+almodjs or SystemJS static SFX builds, which was the reason I've tried SystemJS at first place, but it wasn't worth the pain.

beefsack 9y ago
I use Webpack in a couple of projects, but it only seems to fit well for single page applications that fit their near-standard configurations. We tried to replace Gulp with it at work for some relatively complex software but it was an absolute nightmare; Webpack is highly opinionated and to get it to build multiple different targets with different configurations requires jumping through a lot of hoops or worse, having to have separate Webpack configs and different build commands for each different asset target. The last straw for us was how messy it got trying to build our LESS at the same time. Packaging all the LESS into your compiled JS, then having to extract it to put it in other files is absolutely ridiculous.
- finchisko 9y ago
  That is something I forgot to mention. Webpack is great for SPAs and not so great for classic site with lot of html files. You can have multiple entries (html files), but share common chunks between them might be difficult in some special cases.

deleted 9y ago

[deleted]

daliwali 9y ago

I used both and still prefer Browserify. No configuration required, it just does what you want. Also its source code is quite short and easy to grok.