2 ms·

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 too

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

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.