Hacker News Reader

> For Webpack, that's creating an empty project and incrementally adding config, starting with just an entry point (use a simple script importing some modules) and an output filename. Add one loader/plugin at a time. Move into boilerplates once you're familiar with the basic concepts.

I attended a General Assembly bootcamp last year (to great success afterward for me), and the pervasiveness of jumping right into a generator / boilerplate really caught me the wrong way.

I felt like going the path you describe, starting with relatively low complexity and building on top of it, was/is the right way.

Even talking to co-workers who have been doing this stuff for years, there's little incentive to jump into a boilerplate, if only there's then two learning curves... one for the boilerplate / its layout, and one for the tooling involved (React or Angular, etc).

> A boilerplate is another person's code, and while it's good to avoid NIH, unless it's superbly documented, it contains tricks and workarounds that only cloud real understanding.

This caused a lot of headaches with other students in my class (and classes afterward).

My idea to "solve" it was to incrementally build out my/our own boilerplate so we'd be able to at least use that confidently, as well as maybe have some understanding into how someone else built their boilerplate. It got shot down due to time constraints, though.

Whenever I'm asked to come in and mentor newer students for their projects, this is something I try to impart, though.

You're all selling this as if it were some sort of philisophy. But it's not. Webpack just happens to be a piece of software that for reasons nobody will ever fully understand ended up being the de facto standard, all while being the most miserable to configure piece of software seen by mankind. (I. e. 4-level depth nested configuration with no indication of errors, a few different common patterns – ph, and there are two versions of webpack and the documentation rarely mentions which one it's talking about)[0].

Webpack is, essentially, a compiler. It, or something else, will mature to the point where you don't configure it any more except for maybe a debug flag. At that point learning it's internals will be as useful to a web programmer as learning LLVM's (by which I don't mean "not useful", but probably not worth neglecting whatever the trade-off may be).

[0] I think it was mostly developed by a single guy with a day job, and it has had more impact than any software I have or probably will ever build, so it's not meant to be insulting. Annoyances such as these are the price of a fast-moving field.

Webpack?!? Somebody didn't get the memo... I think we're supposed to use Rollup [0] now...

[0] http://rollupjs.org/

Webpack 2 is where it's at. Tree-shaking was Rollup's big feature and Webpack 2 has it.

That's great, but it ain't there yet. [0] Incidentally, releasing a version 2 without deprecating version 1 seems a bit of a project smell... It might be the right thing to do in a particular situation, but what happened on the project that led to that situation?

[0] Tree shaking completely broken? #2867 https://github.com/webpack/webpack/issues/2867

Whole versions don't get deprecated. Visible features get deprecated when they are still present in the latest version but will be missing or incompatible in the next major version.

Not smell just semver – http://semver.org/

To my mind, the "semver way" would be to make tree-shaking an option on a new minor version. After some number of releases, it might become a default on a new major version, if the maintainers so chose. Splitting the project into multiple codebases is not required by semver.

Wait, are we actually praising the webpack docs now? How far have we come.

I think you're being downvoted due to strawman ([s]he praised documenting concepts, not the documentation as a whole) but you're right though. I've never dived into my toolchain code (due to missing or frugal documentation) more than I've been forced to with Webpack.

It suffers from tutorial-like instructions and a lack of formal list-like documentation, which leads to conflicting or confusing configurations (very easy since there are multiple ways to do the same thing, shortcuts found in the CLI but not in the configuration, etc.)

I love Webpack, but the documentation is really rough in some places.

> ([s]he praised documenting concepts, not the documentation as a whole)

Exactly. I wish I could help with docs for Webpack, but personally I'm willing to trade extensive documentation for a friendly community. These aren't mutually exclusive of course, but I've seen my share of OSS projects with a bad attitude towards beginners and people who are just missing some detail for the whole thing to click.

Likewise, my point re: boilerplates would be moot if most boilerplates had good docs (even if just a detailed README).