5 ms·

I think this is a great exaggeration of the "javascript build tools are hard to config" meme, and it honestly is obsolete. Maybe the meme was relevant two years

by yzmtf2008 8y ago

I think this is a great exaggeration of the "javascript build tools are hard to config" meme, and it honestly is obsolete. Maybe the meme was relevant two years ago, but every since (1) create-react-app and (2) webpack 3, the configuration story has greatly improved. With Webpack 4 and Parcel especially, these tool are both zero config and configurable. Your point 1 and 3 are actually not mutually exclusive, and repeating the meme just sounds like you're perhaps out of the loop for a bit. While the Javascript developer experience truly was horrible a few years back, it has dramatically become better. Try it, and you might be pleasantly surprised :)

Soinou 8y ago
I'll be speaking for Webpack, since it's the only one I use for the few internal applications at work, and I've never really used Parcel yet. Configuring Webpack is still pretty bad. If the zero config works for you, great. But if you need to configure it yourself, it's really verbose, it's really complicated, and the documentation is a bit thin. SplitChunks in Webpack are like black magic, they work but you don't have any idea how, and when they don't work, you still have no idea how. And you don't know if it's because you didn't configure them properly, because you don't know what is configuring them properly, because the documentation on them is so bad. Maybe I'm just bad at configuring Webpack, but I still don't understand how many things in Webpack work, and it's given me a lot of headaches, even with the "zero config" Webpack 4.
dmitriid 8y ago
You are so wrong on so many levels. Have you ever looked at what CRA does? Just do an `eject`. It layers and layers and layers of configuration. The moment you need something not covered by CRA you'll be stuck with the insanity that is webpack config. [1] webpack 3 did nothing to solve the configuration problems. Heck, just half a year ago one of the core devs of webpack argued that there could be no defaults in webpack and that webpack config is horrendous "because it's javascript" [2] [3] webpack 4 addresses just some of the long-standing problems with webpack configuration leaving the actual config as insane and inscrutable as ever. And the only reason it exists is probably due to the public outcry of the larger community and tools like Parcel somewhat stealing the thunder. Parcel is probably the best thing to happen to JS bundlers in recent years, but it's still not without its problems. [1] I did: https://twitter.com/dmitriid/status/908677755046449154 https://twitter.com/dmitriid/status/908677755046449154 [2] Webpack team arguing there can't be defaults in October 2017: https://twitter.com/dmitriid/status/920542261020160000 https://twitter.com/dmitriid/status/920542261020160000 [3] And continues pretending config issues are because of Javascript: https://twitter.com/dmitriid/status/920714918625775618 https://twitter.com/dmitriid/status/920714918625775618
- yzmtf2008 8y ago
  Hey, I looked at ejecting as early as September 2016, but why let that stop you from saying “you’re wrong on so many levels” :) Looking at JavaScript build tools today and ridiculing it makes as much sense as ridiculing the width of car lanes (from width of wagons) or ridiculing the width of rockets (width of railroads). Create-react-app works just fine with the 80% case you wanted so badly for webpack team to implement. (Not to mention there are easy ways to make incremental changes without ejecting.) But why let that stop you from writing a rant about webpck’s lack of default either :)
  - dmitriid 8y ago
    You can look at it today, it will be mostly the same: hacks, inscrutable configuration, custom overrides for stupid things etc. etc. etc. I just looked at it a minute ago. As for the rest you are equally wrong in anything from assuming that webpack 3 made configuration easier to assuming that configuration became easier just because CRA hides all this complexity from us.
    - egeozcan 8y ago
      You don't need to deal with the configuration for 80% of the use cases. If you need something custom, it's a good investment to learn the tool you are depending, and I don't think it's inscrutable: https://webpack.js.org/concepts/ https://webpack.js.org/concepts/
      - dmitriid 8y ago
        Concepts don't describe how to string together four conflicting plugins together just to get predictable caching, for example. There's only so many hours in the day. There are better things in life than to fight a build tool.
        egeozcan 8y ago
        You don't have to. Just don't use those plug-ins? If you do need that functionality, it makes sense to "fight the build tool" a bit (or just go through the docs, they really aren't as bad as you say). I personally always found a solution with Webpack. I find this amazing for a tool which is so young and written in a language without static types.

Soinou 8y ago

I'll be speaking for Webpack, since it's the only one I use for the few internal applications at work, and I've never really used Parcel yet. Configuring Webpack is still pretty bad. If the zero config works for you, great. But if you need to configure it yourself, it's really verbose, it's really complicated, and the documentation is a bit thin. SplitChunks in Webpack are like black magic, they work but you don't have any idea how, and when they don't work, you still have no idea how. And you don't know if it's because you didn't configure them properly, because you don't know what is configuring them properly, because the documentation on them is so bad. Maybe I'm just bad at configuring Webpack, but I still don't understand how many things in Webpack work, and it's given me a lot of headaches, even with the "zero config" Webpack 4.

dmitriid 8y ago

You are so wrong on so many levels. Have you ever looked at what CRA does? Just do an `eject`. It layers and layers and layers of configuration. The moment you need something not covered by CRA you'll be stuck with the insanity that is webpack config. [1] webpack 3 did nothing to solve the configuration problems. Heck, just half a year ago one of the core devs of webpack argued that there could be no defaults in webpack and that webpack config is horrendous "because it's javascript" [2] [3] webpack 4 addresses just some of the long-standing problems with webpack configuration leaving the actual config as insane and inscrutable as ever. And the only reason it exists is probably due to the public outcry of the larger community and tools like Parcel somewhat stealing the thunder. Parcel is probably the best thing to happen to JS bundlers in recent years, but it's still not without its problems. [1] I did: https://twitter.com/dmitriid/status/908677755046449154 https://twitter.com/dmitriid/status/908677755046449154 [2] Webpack team arguing there can't be defaults in October 2017: https://twitter.com/dmitriid/status/920542261020160000 https://twitter.com/dmitriid/status/920542261020160000 [3] And continues pretending config issues are because of Javascript: https://twitter.com/dmitriid/status/920714918625775618 https://twitter.com/dmitriid/status/920714918625775618

yzmtf2008 8y ago
Hey, I looked at ejecting as early as September 2016, but why let that stop you from saying “you’re wrong on so many levels” :) Looking at JavaScript build tools today and ridiculing it makes as much sense as ridiculing the width of car lanes (from width of wagons) or ridiculing the width of rockets (width of railroads). Create-react-app works just fine with the 80% case you wanted so badly for webpack team to implement. (Not to mention there are easy ways to make incremental changes without ejecting.) But why let that stop you from writing a rant about webpck’s lack of default either :)
- dmitriid 8y ago
  You can look at it today, it will be mostly the same: hacks, inscrutable configuration, custom overrides for stupid things etc. etc. etc. I just looked at it a minute ago. As for the rest you are equally wrong in anything from assuming that webpack 3 made configuration easier to assuming that configuration became easier just because CRA hides all this complexity from us.
  - egeozcan 8y ago
    You don't need to deal with the configuration for 80% of the use cases. If you need something custom, it's a good investment to learn the tool you are depending, and I don't think it's inscrutable: https://webpack.js.org/concepts/ https://webpack.js.org/concepts/
    - dmitriid 8y ago
      Concepts don't describe how to string together four conflicting plugins together just to get predictable caching, for example. There's only so many hours in the day. There are better things in life than to fight a build tool.
      - egeozcan 8y ago
        You don't have to. Just don't use those plug-ins? If you do need that functionality, it makes sense to "fight the build tool" a bit (or just go through the docs, they really aren't as bad as you say). I personally always found a solution with Webpack. I find this amazing for a tool which is so young and written in a language without static types.