[modeless]

You really prefer autotools or CMake to esbuild just because they are older and don't change as much? I will take esbuild over CMake every day of the week and twice on Sunday. C++ build tools are an abject disaster. (And CMake does change anyway)

[klodolph]

Not the parent commenter. I spent time using autotools long ago and developed a grudging respect for what they did and how they worked. Their design made sense, even though the system itself was quite cursed. CMake also—I never choose it for my own projects, and I hate using it, but I respect the consistency and portability.

Building JavaScript is just a fucking disaster. I’ve used a fair number of different bundling tools—Browserify, Webpack, Rollup, Esbuild, and Closure (the compiler). I’ve also used old-school concatenation… anything from <script> tags to something like “cat”. It’s just fucking awful. Stay on the straight, narrow path and you’ll survive. Deviate slightly and you’re doomed.

Making things worse, you might have two different environments you run your code in. Node.js and the browser. Surprisingly, the browser lurches ever fowards, and Node.js is the anchor keeping us in the past. Making things worse, you might try to use TypeScript. Making things worse, you might use JSX.

Nearly every JS project I work on needs a ton of babysitting w.r.t. the build system. At various places I’ve worked, there might be a team handling that for me, but if I’m working on a side project, it is very difficult to keep the complexity of the build system down to a reasonable level. Most guides on how to use frameworks will tell you to do something like “oh, just use create-react app” or similar, and you end up with a couple dozen new dependencies. Your build system will be a mix of templated code pasted in to your repo and third-party libraries. Integrating with anything else often requires various "adapter" dependencies, but it's a roll of the dice whether those libraries are built reasonably.

My basic desire is often a fairly simple list… I want front-end TypeScript code to be type-checked and bundled, I want a dev server that serves the bundle, I want to see build errors quickly and easily, I want to run tests without a browser environment. I know this is possible, but every time I’ve gotten it, it’s taken an unreasonable amount of effort.

[mynegation]

Not your parent commenter. I worked both with CMake/autotools and Java build tools (not esbuild specifically) and the point (which I agree with) is - yes - C/C++ build tools are complicated, but once you set it up it just runs most of the time without any problem. With things like webpack you are always one upgrade away from things breaking down in spectacular fashion, and the troubleshooting involves hunting github issues, blogs, and sometimes looking through the source code to figure out why this combination of npm package versions gives you the trouble.

[mst]

Somebody once described configuring fvwm2 (which is still my WM of choice, and indeed was theirs at the time of writing) as "like training a brain damaged hyena."

The thing is, as the same somebody noted, that then it stays trained.

To quote from upthread, "the same insane for 30 years" is in and of itself a huge feature that makes up for quite a lot of insane.

[Steltek]

I must be crazy because I still prefer regular Make to CMake. It seems like CMake tried to fix autotools problems (which were not Make's problems) but then created new problems of it's own. Why is setting an install prefix so complicated when it's the ONE option that almost everyone wants? Why the case sensitive name ending in .txt?

And CMake still seems extremely C/C++ focused. I don't want a language-specific build tool anymore. Heck, I'm not even sure I necessarily need a build tool so much as a generic task runner with patterns and complex/dynamic dependencies.

[akitzmiller]

I think CMake is a real pain and Autotools is an older pain. But I can figure them out and things I learned two blue moons ago are still basically true. The churn in JS makes it really hard for me to accumulate knowledge and solutions.

[ehutch79]

I think you missed the point. Churn is a real problem. Even if the tools are improving, it does need to be balanced against stability. They admited autotools was insane. but it was a consistent well know insanity.

Things are getting better. but js has definitely had more churn, and reinvented more wheels than anything else i know of.

[modeless]

I think you missed my point. Churn is obviously less desirable in the abstract, but the state of C++ build tools in particular is deplorable and the lack of churn doesn't come close to compensating for how terrible it is.