Every time I mess around with sysadmin stuff, I'm always flummoxed by dumb things like "what is the difference between /usr/bin and /usr/local/bin, what the heck is an LD_LIBRARY_PATH, should I use sudo for this build tool or not," etc.). I guess this is how backend devs feel when they have to tweak a Webpack config.

Maybe this is why I'm a little skeptical of the whole "move everything to Rust/Zig/Go/etc" movement in the JS ecosystem. I like JavaScript, I understand JavaScript. If I have to debug some JS tool, I'm well-equipped. Whereas if I have to dip down into some weird error like "libfoo.so.42: cannot open shared object file" then I know I'm gonna get lost.

Plus I don't think we've come close to exhausting all the ways to optimize JS deps: https://marvinh.dev/blog/speeding-up-javascript-ecosystem/

Speeding up the JavaScript ecosystem - one library at a time

Most popular libraries can be sped up by avoiding unnecessary type conversions or by avoiding creating functions inside functions.

@nolan that was my experience maintaining a Hugo website. I appreciated the speed but the Go ecosystem, lack of skills to debug issues, and limited ability to go off-script with things meant things took way longer than they needed to. That being said, esbuild has been a boon and due to its narrow scope I rarely have anything to address.