4 ms·

> Webpack: The most popular bundler for standard JavaScript look for simple starter kit/boilerplate config examples to get things running fast Unless you're al

by dictum 10y ago

> Webpack: The most popular bundler for standard JavaScript look for simple starter kit/boilerplate config examples to get things running fast 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/ 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.

gamesmaxed 10y ago
Wait, are we actually praising the webpack docs now? How far have we come.
- kaoD 10y ago
  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.
  - dictum 10y ago
    > ([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).
d2xdy2 10y ago
> 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.
- matt4077 10y ago
  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.
jessaustin 10y ago
Webpack?!? Somebody didn't get the memo... I think we're supposed to use Rollup [0] now... [0] http://rollupjs.org/ http://rollupjs.org/
- Kiro 10y ago
  Webpack 2 is where it's at. Tree-shaking was Rollup's big feature and Webpack 2 has it.
  - jessaustin 10y ago
    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 https://github.com/webpack/webpack/issues/2867
    - jdd 10y ago
      Not smell just semver – http://semver.org/ http://semver.org/
      - jessaustin 10y ago
        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.
    - prodigal_erik 10y ago
      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.

by dictum 10y ago

gamesmaxed 10y ago

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

kaoD 10y ago
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.
- dictum 10y ago
  > ([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).

d2xdy2 10y ago

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

matt4077 10y ago
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.

jessaustin 10y ago

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

Kiro 10y ago
Webpack 2 is where it's at. Tree-shaking was Rollup's big feature and Webpack 2 has it.
- jessaustin 10y ago
  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 https://github.com/webpack/webpack/issues/2867
  - jdd 10y ago
    Not smell just semver – http://semver.org/ http://semver.org/
    - jessaustin 10y ago
      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.
  - prodigal_erik 10y ago
    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.