Tools don't have to be complex. We have about a fifteen line json config for brunch for the usual build chain. It took a day or two to develop and can be copied with few changes to other projects. Compare this to one of our devs spending over a week and hundreds of lines of config with webpack and still couldn't achieve an identical config. The de facto tools like webpack, gulp, grunt, etc. are unnecessary complexity monsters. That's what people are complaining about here and they have a right to. It's not the idea that's flawed, it's the ridiculously over complex, constantly breaking implementations like the ones above and most similar tools. Not too mention the low quality of such tools and npm itself requiring one to now be an expert on not only the build chain, but npm and yarn before even starting any project. The complaints are more than valid when there are tools that do the same job without the unnecessary complexity.
> Compare this to one of our devs spending over a week and hundreds of lines of config with webpack and still couldn't achieve an identical config. The de facto tools like webpack, gulp, grunt, etc. are unnecessary complexity monsters.
> That's what people are complaining about here and they have a right to. It's not the idea that's flawed, it's the ridiculously over complex, constantly breaking implementations like the ones above and most similar tools.
Well, the complexity is because webpack/gulp/grunt are do-everything tools.
There are lots of features to assist everyone, and usually if you have some obscure requirements, webpack has an solution.
Yeah, webpack is complex - IMO one shouldn't use webpack just to bundle up JS files. There are opinionated tools like Parcel or CRA(which automatically configures webpack under-the-hood), and those will fit 90% of the users. Only the left 10% which existing opinionated solutions cannot accommodate can fiddle with the webpack config directly.
> Not too mention the low quality of such tools and npm itself requiring one to now be an expert on not only the build chain, but npm and yarn before even starting any project.
Well, do you really think JS has low-quality tools? I really don't see them as low-quality... And you should know npm/yarn before starting a JS project; it's like knowing gcc/clang before starting a C project, or knowing cargo before starting a Rust project.
> The complaints are more than valid when there are tools that do the same job without the unnecessary complexity.
(Assuming you're talking about npm/yarn) If you can do the same job without all the dependencies, you don't have to know package managers. If you want to, you should know the package managers.
What I mean when I say by 'know npm/yarn' is that you have to know the internals, how they operate, and why they break. You have to debug npm/yarn themselves. That's not something one should know to build anything on the frontend. In many years with other languages' dependency tools like PHP's composer and Clojure's leiningen, I've had to deal with dependency and internal package manager issues maybe once or twice and that's being generous as I really don't remember any times. So do I think the JS tools are shitty? They are shitty beyond all fucking imagination and comparing them to tools in other languages can objectively prove that by simply looking at the number of times and the way these tools break vs. the tools that don't break. I wouldn't be so adamant about it except I spend more time (as I'm sure many here do) dealing with breakages in npm and yarn than in any other system related deployment task. And the insanity of it is that this isn't even application code. It just concats some files and runs them through a few code processors like babel and scss. That's fucking insanely bad tooling.
As far as webpack, I understand that it's a jack of all trades. But if even trying to replicate a simple bundling config takes many days, then it's a perfect example of a tool that's not only overly complex, but one that doesn't do its own core job well.
