6 ms·

This thing is so complicated and so full of magic and options and the documentation is so shallow, I can't find examples, can't get a tutorial that isn't useles

by fiatjaf 10y ago

This thing is so complicated and so full of magic and options and the documentation is so shallow, I can't find examples, can't get a tutorial that isn't uselessly superficial. I've tried using Webpack in its begginings, because React people only talked in Webpack terms, but then switched back to Browserify, which is simple, not magical and straightforward. I tried using Webpack again lately, with the bizarre Gatsby static site generator, and the failures are enourmous. I can't even understand how exactly does a loader work. Gatsby makes forced use of something called webpack-config or something like that, which is just a useless abstraction on top of the already confusing Webpack config. Please, someone explain to me what does this thing do that Browserify can't.

lobster_johnson 10y ago
Complicated, you say? https://pbs.twimg.com/media/CxfCRzbVQAAXszJ.jpg:large https://pbs.twimg.com/media/CxfCRzbVQAAXszJ.jpg:large
- fiatjaf 10y ago
  Did you just draw that?
  - thelarkinn 10y ago
    No that was handwritten by Tobias the original author and I shared it on Twitter a few weeks back. We do have a lot of abstraction and complexity internally. But we like the direction and way it has allowed us to pivot toward and away new/old features.
vmasto 10y ago
> Please, someone explain to me what does this thing do that Browserify can't. Nowadays not a lot more, but when it came out it was a revelation. The key thing to note is that replicating webpack's abilities in browserify takes about the same or more amount of config and boilerplate.
- fiatjaf 10y ago
  What were these great things Webpack introduced? Not HMR.
  - skrebbel 10y ago
    When I switched from browserify to webpack, everybody was using grunt or gulp to trigger full browserify builds on every change. Browserify had watchify, but it was bolted on, buggy, and slow. Webpack had a devserver with incremental builds that just worked. More generally, browserify seemed very Node-focused in attitude and webpack made a lot of design choices particularly for the web. Things like having uglify built in, ability to not just bundle javascript but also other assets (like pictures and css). I bet all these things were possible with browserify, given the right transform, but I liked that with webpack it was the norm. It seemed designed for the problem I had: coding a web app. Browserify seemed designed for "I have this huge node program that i want to port to the browser with a little effort possible".
- abritinthebay 10y ago
  That's never been true. It takes a few plugins that require almost no config or boilerplate. The main difference was that WebPack bundled it all together so it was all ready out of the box.
thelarkinn 10y ago
Hey sorry this was your first (or many) experience(s). If I can be of any help, I'd recommend checking out our Concepts section which I authored for first-time users and those trying to understand the overall principles of loaders/plugins. webpack.js.org/concepts
- fiatjaf 10y ago
  That seems a nice place to start, I'll read it later. Thank you.
iso-8859-1 10y ago
> Please, someone explain to me what does this thing do that Browserify can't. Native ES2015 modules support?
- fiatjaf 10y ago
  Since everybody (who cares about ES2015) is using Babel, that is currently meaningless, right?
- kentor 10y ago
  That's true, and I'm glad they aren't jumping the gun. Browserify is all about node compatibility, so I'll gladly wait until Node implements ES Module support.
abritinthebay 10y ago
Long story short: nothing. Longer story: it's more of a kitchen sink approach that does more out of the box whereas Browserify is more minimal. Webpack is very config heavy too. I give Webpack a lot of crap on Twitter about what I see as encouraging bad practices but to it's credit it's developing very nicely. But if you're happy with Browserify there is absolutely no reason to switch other than tool-chain momentum.
- boubiyeah 10y ago
  Browserify is not maintained anymore. It's sad, but it simply is out of the competition. Also, chances are you can easily find webpack loaders for your workflow where you would struggle to find an equivalent browserify plugin that works and is maintained. I'd say that's pretty big. If you want a simple build tool, that works out of the box, you could check brunch perhaps.
  - fiatjaf 10y ago
    Browserify is finished, that's different.
  - abritinthebay 10y ago
    Or I could use Browserify - like I am - and have no issues?
sciyoshi 10y ago
Webpack has the very useful "chunking" system which is able to figure out common dependencies, and based on how often they are re-used across your app, determine whether they should be bundled separately. It's really good if you're trying to find an optimal balance between the number of files on a page and the cacheability of each one. I haven't seen that feature in Browserify or other module bundlers. Of course, with HTTP/2 server push hopefully a lot of these issues will go away.
- flukus 10y ago
  That sounds like exactly the sort of magic they are talking about. I'll take predictable over magic any day, in this case it sounds like the sort of decision that's best left to people anyway.
ww520 10y ago
They are all complicate. I've tried the older Webpack 2.x and got a number of errors. Didn't have time to resolve all of them. Went with the simpler rollup, and be done with it. For my workflow, I just need ES6 transpile, module bundling, minifying, and auto build with watch for multiple pages. Code split sounds good on paper but I do my grouping of files explicitly anyway. HMR sounds nice but I haven't got hot reload working yet. Manual refresh the page isn't too bad. I've spent way too much time on configuration and getting the tool chain to work, and less time on developing real feature. Getting really sick of it.
- thelarkinn 10y ago
  Sorry to hear that was your experience, but also glad to hear you found a solution that works. If you do come back to trying webpack, we're happy to help get you up and running. Feel free to reach out on twitter or github @TheLarkInn

by fiatjaf 10y ago

lobster_johnson 10y ago

Complicated, you say? https://pbs.twimg.com/media/CxfCRzbVQAAXszJ.jpg:large https://pbs.twimg.com/media/CxfCRzbVQAAXszJ.jpg:large

fiatjaf 10y ago
Did you just draw that?
- thelarkinn 10y ago
  No that was handwritten by Tobias the original author and I shared it on Twitter a few weeks back. We do have a lot of abstraction and complexity internally. But we like the direction and way it has allowed us to pivot toward and away new/old features.

vmasto 10y ago

> Please, someone explain to me what does this thing do that Browserify can't. Nowadays not a lot more, but when it came out it was a revelation. The key thing to note is that replicating webpack's abilities in browserify takes about the same or more amount of config and boilerplate.

fiatjaf 10y ago
What were these great things Webpack introduced? Not HMR.
- skrebbel 10y ago
  When I switched from browserify to webpack, everybody was using grunt or gulp to trigger full browserify builds on every change. Browserify had watchify, but it was bolted on, buggy, and slow. Webpack had a devserver with incremental builds that just worked. More generally, browserify seemed very Node-focused in attitude and webpack made a lot of design choices particularly for the web. Things like having uglify built in, ability to not just bundle javascript but also other assets (like pictures and css). I bet all these things were possible with browserify, given the right transform, but I liked that with webpack it was the norm. It seemed designed for the problem I had: coding a web app. Browserify seemed designed for "I have this huge node program that i want to port to the browser with a little effort possible".
abritinthebay 10y ago
That's never been true. It takes a few plugins that require almost no config or boilerplate. The main difference was that WebPack bundled it all together so it was all ready out of the box.

thelarkinn 10y ago

Hey sorry this was your first (or many) experience(s). If I can be of any help, I'd recommend checking out our Concepts section which I authored for first-time users and those trying to understand the overall principles of loaders/plugins. webpack.js.org/concepts

fiatjaf 10y ago
That seems a nice place to start, I'll read it later. Thank you.

iso-8859-1 10y ago

> Please, someone explain to me what does this thing do that Browserify can't. Native ES2015 modules support?

fiatjaf 10y ago
Since everybody (who cares about ES2015) is using Babel, that is currently meaningless, right?
kentor 10y ago
That's true, and I'm glad they aren't jumping the gun. Browserify is all about node compatibility, so I'll gladly wait until Node implements ES Module support.

abritinthebay 10y ago

Long story short: nothing. Longer story: it's more of a kitchen sink approach that does more out of the box whereas Browserify is more minimal. Webpack is very config heavy too. I give Webpack a lot of crap on Twitter about what I see as encouraging bad practices but to it's credit it's developing very nicely. But if you're happy with Browserify there is absolutely no reason to switch other than tool-chain momentum.

boubiyeah 10y ago
Browserify is not maintained anymore. It's sad, but it simply is out of the competition. Also, chances are you can easily find webpack loaders for your workflow where you would struggle to find an equivalent browserify plugin that works and is maintained. I'd say that's pretty big. If you want a simple build tool, that works out of the box, you could check brunch perhaps.
- fiatjaf 10y ago
  Browserify is finished, that's different.
- abritinthebay 10y ago
  Or I could use Browserify - like I am - and have no issues?

sciyoshi 10y ago

Webpack has the very useful "chunking" system which is able to figure out common dependencies, and based on how often they are re-used across your app, determine whether they should be bundled separately. It's really good if you're trying to find an optimal balance between the number of files on a page and the cacheability of each one. I haven't seen that feature in Browserify or other module bundlers. Of course, with HTTP/2 server push hopefully a lot of these issues will go away.

flukus 10y ago
That sounds like exactly the sort of magic they are talking about. I'll take predictable over magic any day, in this case it sounds like the sort of decision that's best left to people anyway.

ww520 10y ago

They are all complicate. I've tried the older Webpack 2.x and got a number of errors. Didn't have time to resolve all of them. Went with the simpler rollup, and be done with it. For my workflow, I just need ES6 transpile, module bundling, minifying, and auto build with watch for multiple pages. Code split sounds good on paper but I do my grouping of files explicitly anyway. HMR sounds nice but I haven't got hot reload working yet. Manual refresh the page isn't too bad. I've spent way too much time on configuration and getting the tool chain to work, and less time on developing real feature. Getting really sick of it.

thelarkinn 10y ago
Sorry to hear that was your experience, but also glad to hear you found a solution that works. If you do come back to trying webpack, we're happy to help get you up and running. Feel free to reach out on twitter or github @TheLarkInn