Webpack blew everything out of the water. 80 lines of config, hot-reloading, code-spliting, hash-filenames... Looking forward to whats coming next.
The docs are very basic and there are so many configuration params.
If you want to do something that's not covered in tutorials or boilerplates, be prepared to spend a ridiculous amount of time reading Webpack PRs, issues and the codebase.
Webpack does a great job and it's a nice concept but it has very bad documentation.
[1] Isomorphic apps, or multiple builds for i18n etc
I really hate systems that are built like that. Nobody should build software like that.
I just want simple tools with a clear API that I can combine together and easily replace by other tools, like in the Unix tradition.
I guess it is a case of "LEGO versus Playmobil". The former allows modularity, while the latter is just complex crap that allows you to do nothing other than what the instructions say.
Think of it as a tool executing require.extensions at build time. It's not operating on files as much as it's looking directly at the source-code AST. That makes it more complex to get into over the glob tools but it's worth it.
It's also just as modular as anything else: http://npmsearch.com/?q=loader%20AND%20keywords:webpack
For anyone else in this position, sorry to the gulp/grunt guys, but skip them - go straight for webpack. It's still taken a lot of work to get a config that works nicely for my usecase, but all in all the experience was really good and I was 80% of the way there in no time at all.
Gulp is a looooot better, especially when I have things like Foundation 6's zurb-template, which is basically configured out of the box how I setup my Foundation 5 era projects.
I don't care how big a Gulp file is if I'm not the one having to do major maintenance on it.
Do authors of these build tools actually sit down for a couple of months looking at things like Makefiles that have been around forever, perhaps even Maven, etc. Take all these things together and go "This is what sucks in all of them, and here's how we can do it better" and still cater for all the use cases that these tools are brilliant at.
It's like there's no thought put into these tools and nothing is built on computer science foundations. Like why are you using Json as the syntax? Ant build files were an abomination and Json really isn't offering anything better (actually way less), except a slightly more readable syntax for trivial use cases.
When I saw that LiveScript was using Makefiles[0] to build, I was baffled. To me they were ancient and complicated C/C++ stuff. But when I looked into them, everything seemed rather straight forward, even a bit nicer than Gulp, because of the syntax.
[0] https://github.com/gkz/LiveScript/blob/master/MakefileThe big one is that they break if there are spaces in file or directory names.
Sure, you can argue spaces are bad practice. But they are common on OS X and windows. It's a little silly to use a build system that doesn't support them.
Its basically the NPM problem all over again, but as a build system, while also using NPM which doesn't make not not the NPM problem.
I personally work on things that still need other aspects of the task runners.
That said, I use gulp now and a notice lot of gulp seems to be replicating parts of JS itself - tasks are just functions, I don't see why they need to be special. There's always 'gulp foo' which is a less maintained wrapper around 'foo'. And browserify seems slow to build bundles - is webpack any faster?
Also it may have support for AMD, but it's key usage is to bundle libraries from npm using commonjs.
I'm not saying webpack is all roses (even in version 2), but these two things are not the issue.
"Webpack is a module bundler. It packs CommonJs/AMD modules i. e. for the browser"
If you use AMD as input you have to get updates to your libraries separately, and your libraries are bloated since AMD modules tend to use dependencies less.
You should also check out https://news.ycombinator.com/newsguidelines.html.
It accepts AMD as an option, but honestly, I've been using webpack for about a month and I haven't come across a single library that recommends using AMD. It's just there as an option for those who need it. Most of the world has moved on from AMD due to its issues, so I can't really see your point.
Being able to shim script tag libraries is mentioned in various places through the docs (and used to be even more prominent than it is now).
I'm responding out of charity here: you made an angry response, were shown to have misread the post, and haven't apologised. Be civil.
Re your original post, the 'damned' and 'what are you talking about' and not reading my post charitably (that I was lying rather than just reading the site description) seemed rude. Thank you for apologising.
Of course, the async thing (and such) is something I agree with, newer tooling has iterated and improved on Grunt.
Webpack is amazing tool, but it's not a task runner like gulp.