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.
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.
[0] Tree shaking completely broken? #2867 https://github.com/webpack/webpack/issues/2867
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.
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).
Unless you're already familiar with a tool, I'd suggest starting with the very Hello, world basics.
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 wish more projects had a Concepts page like Webpack now has: https://webpack.js.org/concepts/)
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.
---
Eric wisely started the article with JavaScript & DOM Fundamentals. For people like me, who were familiar with pre-ES6 JS but weren't actively writing JS lately, the basics themselves have changed a bit.