4 ms·

What is Webpack? A several horrific hours of googling how to fix its configs so that it just works

lwansbrough 8y ago
What is Webpack? A question you’ll find yourself Googling every month as the “best approaches” change.
gedy 8y ago
I hear this trope here a lot, always seems to gloss over what webpack improved on, which is replacing bespoke build scripts for web projects. Also that it greatly reduced the ye olde tradition of coding to the least common denominator subset of features that runs on all browsers. Webpack was and is awesome for that.
- sametmax 8y ago
  The fact having a broken arm is better than having aids doesn't mean breaking an arm is nice.
- lucisferre 8y ago
  > coding to the least common denominator subset of features that runs on all browsers Did Webpack do that or did Babel?
  - sametmax 8y ago
    Babel. Webpack is just a glue. An over complicated glue.
- dxhdr 8y ago
  > replacing bespoke build scripts for web projects Does it, though? No project of moderate complexity will be able to reuse a Webpack config. Conversely, how large of a problem was this for simple sites?
  - noir_lord 8y ago
    I still use shell scripts for moving assets around and build sass, I use webpack for the TypeScript/dependency managment (via yarn). I looked at doing it with webpack but frankly 2 lines of bash that'll work the same in a decade vs haha no wasn't a hard choice.
jlebrech 8y ago
it shouldn't be config based, should be a DSL or a library that's verbose enough to understand the workings of.
- YuukiRey 8y ago
  Interesting that you should mention it. This talk https://www.youtube.com/watch?v=mVVNJKv9esE https://www.youtube.com/watch?v=mVVNJKv9esE mentions some arguments why a DSL would not be a good approach for frontend/JS build tools. Namely that a DSL isn't adequate if the underlying best practices or requirements change a lot. That's why operating at a higher level of abstraction (function chaining/piping/composition) would make more sense. Now... that doesn't really favor Webpack. And I still don't quite understand why that tool is so popular.
  - bpicolo 8y ago
    > That's why operating at a higher level of abstraction (function chaining/piping/composition) would make more sense. That's just back to Gulp.
epicide 8y ago
I have spent many hours on many versions of WebPack for code that has gone to production for a large company. I cannot give any more detail than that. WebPack 1.x was very powerful but very difficult to understand and configure. There weren’t a lot of sane defaults and the docs did very little to adequately explain the core concepts. The problem(s) WebPack wolves are pretty complex and I haven’t seen anything else do quite what it does. Starting with 2.x, the docs are great. They explain the concepts pretty well. They give you basic setups and examples throughout. 2+ also has a simplified base config: you only need a few items in your config to start getting some pretty big benefits. While WebPack was not the first and certainly isn’t the only tool that provides what it does, it does provide a sort of one stop shop for a lot of what used to be separate tools. I don’t feel like it locks me in however. Along with the ability to minify and other such “utility” functions (which you don’t have to do with WebPack), you get things like tree shaking. This can drastically shrink your final bundle. As someone who does a lot of UI development, it’s also nice to be able to use ES2015 features like import without having to worry. tl;dr I see complaints about WebPack being complicated and config heavy. It used (1.x) to be exactly that. It’s much better and the benefits from using it far beyond worth the (now little) upfront learning IMO.
- sametmax 8y ago
  > The problem(s) WebPack wolves This is such a great typo. I'm going to keep this sentence next time I need to explain webpack in my trainings.
  - epicide 8y ago
    All I ask for is attribution ;)
Kagerjay 8y ago
Something that should be avoided unless you really need it

What is Webpack? A question you’ll find yourself Googling every month as the “best approaches” change.

gedy 8y ago

I hear this trope here a lot, always seems to gloss over what webpack improved on, which is replacing bespoke build scripts for web projects. Also that it greatly reduced the ye olde tradition of coding to the least common denominator subset of features that runs on all browsers. Webpack was and is awesome for that.

sametmax 8y ago
The fact having a broken arm is better than having aids doesn't mean breaking an arm is nice.
lucisferre 8y ago
> coding to the least common denominator subset of features that runs on all browsers Did Webpack do that or did Babel?
- sametmax 8y ago
  Babel. Webpack is just a glue. An over complicated glue.
dxhdr 8y ago
> replacing bespoke build scripts for web projects Does it, though? No project of moderate complexity will be able to reuse a Webpack config. Conversely, how large of a problem was this for simple sites?
- noir_lord 8y ago
  I still use shell scripts for moving assets around and build sass, I use webpack for the TypeScript/dependency managment (via yarn). I looked at doing it with webpack but frankly 2 lines of bash that'll work the same in a decade vs haha no wasn't a hard choice.

jlebrech 8y ago

it shouldn't be config based, should be a DSL or a library that's verbose enough to understand the workings of.

YuukiRey 8y ago
Interesting that you should mention it. This talk https://www.youtube.com/watch?v=mVVNJKv9esE https://www.youtube.com/watch?v=mVVNJKv9esE mentions some arguments why a DSL would not be a good approach for frontend/JS build tools. Namely that a DSL isn't adequate if the underlying best practices or requirements change a lot. That's why operating at a higher level of abstraction (function chaining/piping/composition) would make more sense. Now... that doesn't really favor Webpack. And I still don't quite understand why that tool is so popular.
- bpicolo 8y ago
  > That's why operating at a higher level of abstraction (function chaining/piping/composition) would make more sense. That's just back to Gulp.

epicide 8y ago

I have spent many hours on many versions of WebPack for code that has gone to production for a large company. I cannot give any more detail than that. WebPack 1.x was very powerful but very difficult to understand and configure. There weren’t a lot of sane defaults and the docs did very little to adequately explain the core concepts. The problem(s) WebPack wolves are pretty complex and I haven’t seen anything else do quite what it does. Starting with 2.x, the docs are great. They explain the concepts pretty well. They give you basic setups and examples throughout. 2+ also has a simplified base config: you only need a few items in your config to start getting some pretty big benefits. While WebPack was not the first and certainly isn’t the only tool that provides what it does, it does provide a sort of one stop shop for a lot of what used to be separate tools. I don’t feel like it locks me in however. Along with the ability to minify and other such “utility” functions (which you don’t have to do with WebPack), you get things like tree shaking. This can drastically shrink your final bundle. As someone who does a lot of UI development, it’s also nice to be able to use ES2015 features like import without having to worry. tl;dr I see complaints about WebPack being complicated and config heavy. It used (1.x) to be exactly that. It’s much better and the benefits from using it far beyond worth the (now little) upfront learning IMO.

sametmax 8y ago
> The problem(s) WebPack wolves This is such a great typo. I'm going to keep this sentence next time I need to explain webpack in my trainings.
- epicide 8y ago
  All I ask for is attribution ;)

Kagerjay 8y ago

Something that should be avoided unless you really need it