Hacker News Reader

Why is this still available? It still shows fairly high in Google: https://webpack.github.io/

BTW, your documentation effects inspired me partly for making the documentation of https://serverjs.io/documentation/

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.

But on embedded devices, do they download the whole artifact again and again? On the web this is a real issue

No in embedded if it is to big it can't fit, full stop. One byte too much means corrupt firmware.

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

[0] https://webpack.js.org/concepts/modules/

Yes, it does make a difference, in a few ways.

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

[0] https://medium.com/the-node-js-collection/the-current-state-...

[1] https://twitter.com/dan_abramov/status/938090483166924800

[2] https://github.com/markerikson/react-redux-links/blob/master...

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

> 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:

https://www.npmjs.com/package/@std/esm

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.

Actually - I just noticed I dropped an I. It's Final Fantasy 13 (FFXIII), not Final Fantasy 12 (FXII). The sizes are correct though.

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!