The problem with Webpack is that if you want to do something that's not straightforward[1] or covered in the dozen tutorials that are on the web, you're going to have a hard time.

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

> The problem with Webpack is that if you want to do something that's not straightforward[1] or covered in the dozen tutorials that are on the web, you're going to have a hard time.

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.

Webpack does not glob-search against the filesystem like grunt/gulp/brunch/broccoli/make. If you look for that: Sorry, webpack does not "replace" simple tools like that.

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

Funny enough, if you look at the comments for pretty much the landing page of web pack you get the same sentiment

http://webpack.github.io/docs/what-is-webpack.html

Yeah I agree with most of the sentiment but I let it by when you go to the github repo and check out contributor statistics. Pretty much it's just sokra doing everything and he does it in his free time last I heard. I think webpack is missing the support it needs in regards to how much it's actually getting used.

I could not for the life of me get Webpack to bundle '.json' files that were require()d by some library code I was using. Of course, this functionality comes out of the box with Browserify.

I went through this in the last couple of weeks. After about a week of infuriating behaviour trying to get gulp/grunt working even remotely how I wanted (eg vendor stuff split so builds don't take 10 seconds) I decided to give webpack a shot.

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.

Grunt was nasty as hell, and clearly didn't learn any of the lessons from, say, proper Makefiles from the UNIX world over the past 30 years.

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.

This is what I don't get.

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.

I think not even Node or NPM learned any lessons from older tools. Look at the recent leftpad fiasco. A decent part of it could have been avoided with namespacing (hello Maven groupIds!). npm didn't have it from day 1 and even now it's optional and basically unused.

Haha, yes.

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/Makefile

Makefiles have some glaring issues that can't be easily fixed.

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

That isn't entirely true. It depends entirely on how you quote your filenames. But yes, historically, there's a lot of broken Makefiles that way.

Ah, didn't know that.

I don't get it, what part of Makefiles are missing in Grunt? I've set up a project pretty simply through Grunt without too many headaches (after grocking how to properly write base tasks)

The simplicity, plus Grunt has an entire ecosystem of already made tasks that none of them really work the same, so you have to learn the quirks of other people's code.

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.

Holy crap! I left a company 6 months ago and we were using Gulp there, and it was, as far as I am aware, the hot thing to use (I'm no front-end dev). Now you're telling me it is obsolete?! Javascript world is silly.

It isn't obsolete. Webpack just reduces task runners even more, since webpack takes care of taking your source, copying your source to your build/dist/whatever directory, minifying everything, creating hashes in filenames, being able to update html with those hash names, etc.. Basically, if you can use `import` on a file in Webpack 2 or `require` in either Webpack 1/2 you don't need Gulp/Grunt to do that work.

I personally work on things that still need other aspects of the task runners.

I am sorry but if someone told me that the product which came out yesterday is obsolete then I'd understand that Javascript world is silly, but if at your company a product which was popular 3 years ago cool, then it's your company's fault.

Javascript was popular 3 years ago. What new, cool thing have you moved on to?

I don't regret learning gulp. Node streams are bizarre, interesting construct and I'd probably had no chance to touch them but gulp made me understand them to the minute detail.

One thing this dissuaded me from webpack is that it markets itself on support for AMD and script tags - if you need JS modules that are only available as AMD or script tags in 2016 it's a worry.

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?

Markets itself with support for AMD and script tags? What are you talking about, it's all about bundling things automatically without script tags, you don't even need to write the damned html file if you use loader for it.

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.

You misunderstand what I meant. Nobody has written or suggested that webpack outputs script tags or AMD. I simply stated that webpack markets itself as using script tags and AMD as input, which is true: from the meta description on webpack.github.io:

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

Where does it say it uses script tags for input? The quote you mention says CommonJS/AMD. CommonJS is the de-facto standard these days. Typically, people write in ES6 imports, which then gets transpiled to CommonJS anyway.

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.

I think by script tags he means JS modules that only "export" things using globals.

You admit most of the world had moved on from AMD, but don't see why advertising AMD support as a main feature - to the point it's mentioned in the sites description - would dissuade people?

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.

Mr. that was not my reply, and I didn't made a angry response... If you thought my characters conveyed angryness I apologize, I just critcized your points.

oops I didn't realise someone else chimed in.

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.

The 800 lines are you or your team's own fault; it's just a file run in NodeJS, it's trivial to separate it in task-specific files and load them with either `require` or one of the `loader` projects. Build tooling (what Grunt is) configuration, maintenance and maintainability is also the responsibility of developers.

Of course, the async thing (and such) is something I agree with, newer tooling has iterated and improved on Grunt.

Not everything is covered by webpack. And also you just replaced huge configuration with another huge configuration.

Webpack is amazing tool, but it's not a task runner like gulp.

Totally agree, the key was loaders...