6 ms·

I know it's just piling on at this point, but I've been doing a lot of software builds and deployment over the last 20 years, mostly in a scientific computing c

I know it's just piling on at this point, but I've been doing a lot of software builds and deployment over the last 20 years, mostly in a scientific computing context. Nothing I've dealt with is as bad as JavaScript. I've generated and hacked dozens of autotools builds and written m4 macros of my own; I've hacked CMake builds; written RPM spec files; fixed Rcpp package installs; written and modified innumerable Makefiles; setup Tomcat webapps; and use Python for most of my daily work. I've even hacked around with Boost's build thing. Complexity is not the issue with JavaScript. Stability is the problem. Most devs do not want to "know" build systems. You want it to work most of the time and when it doesn't, you want to be able to find the answer to a problem. You want that knowledge to accumulate over time so that the answer you found the last time still works. Autotools is an insane system, but it's been the same insane for 30 years. Currently using vue-cli with Vue 2 and Vuetify, a configuration depending on a lot of precisely pinned versions to get functional. There is a pile of deprecated library warnings during the lengthy build process that I have no idea how long it will take me to address. Could be a couple of hours, could be several days, could be impossible. Would like to try Vite or esbuild because God knows we could use the speed up, but after investing a couple of weeks to figure out the precise balance of versions that will work and propagating to our 8 or 9 applications, where are we going to be next year? I saw a Tweet yesterday about vite on swc. Is that going to be the winner? I half wish Richard Stallman would take over. How desperate is that?

deleted 5y ago
[deleted]
rglover 5y ago
esbuild is the gold standard. Its creator has done a phenomenal job (and it's still early in its lifecycle). It's the first time I used a JS build tool and didn't scream at the monitor when dealing with nonsensical APIs and error output. Re-implemented a complex setup using it in an afternoon with very few hiccups: https://github.com/cheatcode/joystick/blob/master/cli/src/functions/start/buildFile.js https://github.com/cheatcode/joystick/blob/master/cli/src/fu....
- maxfurman 5y ago
  The "early in its lifecycle" part is the source of GP's worry. esbuild _seems_ great now, but based on the history of JS tooling, who knows what will happen in a year or two. Look at the recent example of the JS community's multi-year embrace and then rejection of Webpack. I would be nervous about migrating too.
  - rglover 5y ago
    I share a similar fear (generally speaking), but in this particular case I think the risk is worth it because the cost of setup is next to zero and the speed of the thing is unreal. If something catastrophic happens with the project years down the road, at most I'll have spent a few hours getting it wired up (worth it considering the positive impact it's had on my productivity). It's not the usual JS personality screaming "wEbPaCk iS dEaD!!!lol" it's clear the author is thoughtful (observable via the project itself, the docs, and how he interacts with people in Github comments). Restored my faith quite a bit.
    - mst 5y ago
      Plus if the author is keeping to go versioning standards they'll probably also keep to go compatibility aesthetics which bodes well for the future. It's still a risk, but in this case one I suspect I'll also take next time I need to add a build step to a JS project.
modeless 5y ago
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)
- ehutch79 5y ago
  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 5y ago
    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.
- akitzmiller 5y ago
  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.
- mynegation 5y ago
  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.
colejohnson66 5y ago
You'd really take autotools and M4 over some other build system? This honestly reads like a "get off my lawn. The old days were better" post.
- akitzmiller 5y ago
  You're not totally wrong; I'm getting into that age range. It's not that I prefer those tools; they are really obtuse. It's just that I can't handle the moving target of JavaScript. I'm sure I can figure out esbuild just fine, but in a year or two it could be abandoned in favor of swc or Vite or a Vite-esbuild-swc uber package.
  - colejohnson66 5y ago
    That is a very valid concern
- morelisp 5y ago
  One advantage of autotools is that at least a lot of the skills are transferable. Shell scripts and Makefiles (and OK, M4 isn't so popular these days, but it was for a reasonably long time) are things I can learn and use everywhere, not just this project, not just C projects, not even just development. I don't learn any transferable skills writing Webpack or Babel config. They don't even necessarily transfer to the next generation of the same tool. I would also take a stable autotools over an unstable autotools, and I consider most of JS-land roughly equal in usability to unstable autotools. Autotools was also not that bad on the happy path where you were targeting, say, the top five POSIX systems over ten years - and maybe you didn't even need it at all, if you didn't need the performance from distinguishing each platform's best supported fd polling variant. Vs. JS, which is still bad even if you're only targeting evergreen browsers, because maybe you're stuck trying to integrate CSS modules with TypeScript or something. That kind of problem simply doesn't exist in autotools world.
jashper 5y ago
Hey now, let's leave Richard Stallman alone :D
- akitzmiller 5y ago
  Indeed

deleted 5y ago

[deleted]

rglover 5y ago

esbuild is the gold standard. Its creator has done a phenomenal job (and it's still early in its lifecycle). It's the first time I used a JS build tool and didn't scream at the monitor when dealing with nonsensical APIs and error output. Re-implemented a complex setup using it in an afternoon with very few hiccups: https://github.com/cheatcode/joystick/blob/master/cli/src/functions/start/buildFile.js https://github.com/cheatcode/joystick/blob/master/cli/src/fu....

maxfurman 5y ago
The "early in its lifecycle" part is the source of GP's worry. esbuild _seems_ great now, but based on the history of JS tooling, who knows what will happen in a year or two. Look at the recent example of the JS community's multi-year embrace and then rejection of Webpack. I would be nervous about migrating too.
- rglover 5y ago
  I share a similar fear (generally speaking), but in this particular case I think the risk is worth it because the cost of setup is next to zero and the speed of the thing is unreal. If something catastrophic happens with the project years down the road, at most I'll have spent a few hours getting it wired up (worth it considering the positive impact it's had on my productivity). It's not the usual JS personality screaming "wEbPaCk iS dEaD!!!lol" it's clear the author is thoughtful (observable via the project itself, the docs, and how he interacts with people in Github comments). Restored my faith quite a bit.
  - mst 5y ago
    Plus if the author is keeping to go versioning standards they'll probably also keep to go compatibility aesthetics which bodes well for the future. It's still a risk, but in this case one I suspect I'll also take next time I need to add a build step to a JS project.

modeless 5y ago

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)

ehutch79 5y ago
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 5y ago
  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.
akitzmiller 5y ago
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.
mynegation 5y ago
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.

colejohnson66 5y ago

You'd really take autotools and M4 over some other build system? This honestly reads like a "get off my lawn. The old days were better" post.

akitzmiller 5y ago
You're not totally wrong; I'm getting into that age range. It's not that I prefer those tools; they are really obtuse. It's just that I can't handle the moving target of JavaScript. I'm sure I can figure out esbuild just fine, but in a year or two it could be abandoned in favor of swc or Vite or a Vite-esbuild-swc uber package.
- colejohnson66 5y ago
  That is a very valid concern
morelisp 5y ago
One advantage of autotools is that at least a lot of the skills are transferable. Shell scripts and Makefiles (and OK, M4 isn't so popular these days, but it was for a reasonably long time) are things I can learn and use everywhere, not just this project, not just C projects, not even just development. I don't learn any transferable skills writing Webpack or Babel config. They don't even necessarily transfer to the next generation of the same tool. I would also take a stable autotools over an unstable autotools, and I consider most of JS-land roughly equal in usability to unstable autotools. Autotools was also not that bad on the happy path where you were targeting, say, the top five POSIX systems over ten years - and maybe you didn't even need it at all, if you didn't need the performance from distinguishing each platform's best supported fd polling variant. Vs. JS, which is still bad even if you're only targeting evergreen browsers, because maybe you're stuck trying to integrate CSS modules with TypeScript or something. That kind of problem simply doesn't exist in autotools world.

jashper 5y ago

Hey now, let's leave Richard Stallman alone :D

akitzmiller 5y ago
Indeed