Nolan LawsonOct 20, 2024
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.
Show threadNolan Lawson

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.

Oct 20, 2024 at 5:21pmWeb
Show threadsnowyfoxOct 20, 2024
.
Show threadDan BurzoOct 20, 2024
@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.
Show threadDominic WhiteOct 20, 2024
@nolan I’m the exact opposite. No idea why some JS Promise is undefined because of the CORS policy. But an improperly linked library I can knee jerk fix.
Show threadWesley MooreOct 21, 2024
@singe @nolan yes I'm the same. Tools that ship binaries mean I don't have to learn an ecosystem's runtime and package management, I can just run it. And if something doesn't work I have more confidence poking around and changing things because the compiler will help me out.
Show threadℹ️❤️🖥 aka Compy-chanOct 20, 2024

@nolan personally, I prefer my tools forcing me to learn a language. That's how I learned JS to begin with. Tho, for terminal stuff, there's more variety of languages than JS, which is rather inconvenient.

And even then, going back to your first post, we still deal with OS issues such as directory conventions, permissions, and environment variables. I understand why you don't want language specific issues on top of all that 

Show threadstubOct 20, 2024

@nolan
> Plus I don't think we've come close to exhausting *all* the ways to optimize JS deps (emphasis mine)

While that is surely true, at some point you are working to have the horse beat the supercar, and at what cost is that? When you could settle for _just_ a car and avoid the time spent beating the dead horse.

Show threadNolan LawsonOct 20, 2024

@stub Sure, I agree that optimal Rust is faster than optimal JS. And idiomatic Rust is faster than idiomatic JS.But the question is: how much faster, and at what cost? It seems to me that a lot of people are jumping from "idiomatic JS" to "optimal Rust" without really trying out "optimal JS" first.

In your analogy, I'd say to try putting some horseshoes on the horse before springing for a sportscar. 🙂

Show threadJuanluOct 21, 2024

@nolan Every ecosystem having this debate apparently :) (Python with uv, ruff)

As a Python person, and as a developer who tries to get things done, I use tools that I never, ever want to debug. That includes git, shell utilities, code formatters, and more.

I want these tools to just work. If they don't, I'll assume there's a 99 % chance it's my fault. I'll open an issue, find a workaround and move on, not waste a weekend tinkering with it.

Abstraction enables productivity and tight feedback.