Hey thanks for the candid opinion!!! Sean from the webpack team here!!! Maybe it's been awhile since you have taken a look at our documentation! (webpack.js.org)!
I think something that individuals who try to make comparisons to their backend tooling that "just works" is that none of these tool have ecosystem constraints like the Web. I wanted to really talk about something that is important to understand about tooling, and why webpack might have some of the features it does.
In the web, you should only ship no more then ~<200kb of JavaScript (uncompressed), for your initial download. From there, you should be "dynamically" delivering JavaScript asynchronously in bundles/chunks. In addition, there are multiple module types that exist in the JavaScript ecosystem that libraries are published in. Sadly, some of the most popular libraries are being published with AMD Modules, or CommonJS, or no module system at all, and there is no consistency or way to know this about those modules without looking at their source code. Therefore, webpack out of the box supports the ability to load all of them. Not only that, but we employ a set of plugins that help optimize code using complex topological sorting, (aka things you'd probably never want to implement or hand optimize yourself) to ensure that your delivered code is the smallest possible.
Compare this to C++, or any "build" static toolchains. There are really _no_ size limits for the amount of dependencies or code that needs to be linked together. Therefore, there is no care in the world for application developers if they are generating 600GB Video Games, 10MB-100MB Applications, etc. Think if there was 5 ways to write C++ Modules/Java Modules, etc. and you had to apply the same constraints as the Web. (You'd probably see a lot more webpack's or a lot more convention tools that wrap things like webpack).
Anyways, as a maintainer of the project, we can't say this enough: "We are owned by our community". This means that if there are things we aren't doing right, that we owe you to make things easier to use, more conventional, when needed, and progressive in a way that lets you layer features and need on top of an awesome, and fast core product <3.
So if you have great ideas, please let me know. :-D
As Webpack user, I can affirm that the documentation and the error handling is way better than it used to be. Webpack, by it's nature, is not an easy to use tool.
I don't think all developers should have to deal with Webpack directly, for most developers a generic Webpack config generated by something like create-react-app should be good enough.
Of course this doesn't mean that Webpack itself should not try to improve, however users should be mindful of what a hard problem the tool is trying to solve.
> Compare this to C++, or any "build" static toolchains. There are really _no_ size limits for the amount of dependencies or code that needs to be linked together. Therefore, there is no care in the world for application developers if they are generating 600GB Video Games, 10MB-100MB Applications, etc.
Huh? Seriouosly? Embedded devices can be any size people want? Some software I develop uses C, Go, etc. and it would be nice to not have to worry about built artifact sizes. Admittedly I find it kind of fitting and funny that someone who maintains a popular JS library thinks that the web is the only (?) platform with build size (and possibly other) constraints, haha.
Anyway, I do appreciate your work in helping maintain an open source project, so keep that up.
> In the web, you should only ship no more then ~<200kb of JavaScript (uncompressed), for your initial download
Man I wish it was easier to convince people of this. I'm fighting with some teams at work who are shipping 2mb+ compressed with several seconds just for parse time...and all of the webpack tooling and features are needed just to keep it there (when it should be used to bring it down within that 200kbish threshold). And they feel its normal.
> Sadly, some of the most popular libraries are being published with AMD Modules, or CommonJS, or no module system at all
Not being current on JavaScript for the past couple years (which is about all it takes to be totally out of date - but I digress), I guess these are out of style, in favor of ES2015 import statements? The webpack docs [0] really don't say anything about that, just that they're supported.
As a consumer of webpack and $random_library should I care? Should I prefer a library with import over AMD or does webpack make that irrelevant?
I can't tell from these docs, but previous experience tells me this is the kind of thing that has the potential to trip me up later when it's a huge pain to switch everything.
AMD modules can effectively only be consumed by a browser, or a browser-focused bundling tool, since AMD was designed for the "cascading waterfall" loading approach. Anecdotally, I see no new libraries being written in AMD format, and some that are written in AMD are looking at transitioning to ES6 modules.
CommonJS modules are intended for synchronous loading under Node, and tools like Webpack and Browserify can wrap them up to be used in a browser.
ES6 modules are designed to be statically analyzable, which is a key factor in "tree shaking" to drop unused code out of a generated bundle. However, the ES6 spec only defined the syntax for modules, not how they should be loaded. Major browsers have finally implemented native support for ES6 modules, but there's still a lot of complexity around how they're going to be implemented in Node [0].
There's also complexity around how lib authors publish packages to NPM. The most compatible approach is to author lib code as ES6 modules and whatever syntax additions you want, then compile it to CommonJS and ES5 before publishing. However, that loses out on any possible benefits from tree shaking. See this Twitter thread with discussion from Dan Abramov [1].
For more info on the history and differences between various JS module formats, see the "Javascript Module Formats" section of my React/Redux links list [2].
> There's also complexity around how lib authors publish packages to NPM. The most compatible approach is to author lib code as ES6 modules and whatever syntax additions you want, then compile it to CommonJS and ES5 before publishing.
There's also a growing trend among some major libraries to publish NPM packages only as ESM and use an shim like @std/esm to load them in Node:
>Anecdotally, I see no new libraries being written in AMD format, and some that are written in AMD are looking at transitioning to ES6 modules
Quite possibly because one of the biggest backers of the AMD format, Dojo* is now transitioning to ES6 modules.
*I really gotta hand it to those folks. They pioneer quite a bit of tech. Sometimes it sticks, sometimes it falls by the wayside, and sometimes it returns as someone else's "idea".
The overwhelming majority of space taken by games is HD or 4K assets, not code in any language or plaintext script. I can't even think of a single game that is 600GB off the top of my head, the latest huge AAA: Doom, Halo and Witcher are all under 100GB I believe and still considered too heavy on users in Australia, users with bad connections, etc. (and again - vast majority of that is assets, not any code). The biggest game I actually have on my HDD now is around 60GBs and the exes and dlls take under 50 MBs, it's FFXII with both English and Japanese in it and there is a guide on Steam on removing one of the languages content to bring it down to 30GB. And the latest "don't worry about it, CPU/RAM/HDD is cheap" framework for "native" applications lately was not Qt, GTK+, LCL, etc. but actually a 'JavaScript' technology - Electron - notorious thanks to shenanigans of Slack and Atom.
Between the multiple exclamation points, emotes, PR fluff and the content itself I was actually unsure if this is a parody account or not but it seems to be a genuine Microsoft person.
So, just to get my own biases out of the way first: I'm a big webpack fan, with no qualifications. I think it's a fantastic tool, and I've had the complete opposite experience of the OP.
This response comes off as kind of snide, as does the post it responds to; I don't care to tone police, so that's fine, but I do want to try to understand the perspectives here.
I'm imagining you're coming from a place of: you have a (fantastic) tool with unique challenges, and it's incredibly frustrating to have that tool judged a) based on requirements it wasn't designed around and b) (likely?) based on older versions of your tool that has since been improved. Those are fair things to take issue with.
A couple things, though:
"Hey thanks for the candid opinion!!!" - This seems pretty obviously disingenuous.
"Maybe it's been awhile since you have taken a look at our documentation!" - Comes from the position that OP is simply out of touch, and that their issues aren't valid. They may or may not be, but this is "Maybe you're wrong!" and not "Maybe there's been a misunderstanding!"
"So if you have great ideas, please let me know. :-D" - In context with the above, this is more like "Let me know when you actually have a great idea" than it is like "Please open an issue or pull request so we can actually fix it". The OP does clearly have an issue with Webpack - "You spend 2 days getting it into some semblance of a working state, and never touch it for fear of introducing a new issue" - and that issue can be addressed, if developed into something more actionable, or may already be solved by the improved documentation of 2.0 & 3.0. As it stands, though, it seems more likely to me that nothing comes out of it, which is a shame.
Not trying to put words in your mouth, I just expect you're more frustrated and want to make a better tool than you are trying to necessarily defend your tool, and I'm not sure you're communicating the former over the latter. Would love clarification if I've misinterpreted something, or correction if I seem totally off the mark. And again, lest I come off more aggressive/dismissive than I intend - thank you for all your work developing and maintaining Webpack. I imagine it's a relatively thankless task for the breadth of what it offers.
Hey Sean, I just want to say thanks for all the work; I'm not sure the complaints from others but webpack has helped us quite a bit by making development life closer to what it should be!
I think something that individuals who try to make comparisons to their backend tooling that "just works" is that none of these tool have ecosystem constraints like the Web. I wanted to really talk about something that is important to understand about tooling, and why webpack might have some of the features it does.
In the web, you should only ship no more then ~<200kb of JavaScript (uncompressed), for your initial download. From there, you should be "dynamically" delivering JavaScript asynchronously in bundles/chunks. In addition, there are multiple module types that exist in the JavaScript ecosystem that libraries are published in. Sadly, some of the most popular libraries are being published with AMD Modules, or CommonJS, or no module system at all, and there is no consistency or way to know this about those modules without looking at their source code. Therefore, webpack out of the box supports the ability to load all of them. Not only that, but we employ a set of plugins that help optimize code using complex topological sorting, (aka things you'd probably never want to implement or hand optimize yourself) to ensure that your delivered code is the smallest possible.
Compare this to C++, or any "build" static toolchains. There are really _no_ size limits for the amount of dependencies or code that needs to be linked together. Therefore, there is no care in the world for application developers if they are generating 600GB Video Games, 10MB-100MB Applications, etc. Think if there was 5 ways to write C++ Modules/Java Modules, etc. and you had to apply the same constraints as the Web. (You'd probably see a lot more webpack's or a lot more convention tools that wrap things like webpack).
Anyways, as a maintainer of the project, we can't say this enough: "We are owned by our community". This means that if there are things we aren't doing right, that we owe you to make things easier to use, more conventional, when needed, and progressive in a way that lets you layer features and need on top of an awesome, and fast core product <3.
So if you have great ideas, please let me know. :-D