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