- 491comments
- 710comments
- 36comments
- 26comments
- 346comments
- 142comments
- 15comments
- 47comments
- 52comments
- 66comments
- 10comments
- 53comments
- 22comments
- 22comments
- 176comments
- 31comments
- 5comments
- 32comments
- 31comments
- 50comments
- 8comments
- —discuss
- 5comments
- 26comments
- 13comments
- 142comments
- 52comments
- 413comments
- 102comments
- 19comments
Alternatively, there's a pool of JS developers who shouldn't be maintaining critical infrastructure to begin with.
It's not a black box, those codebases are usually open and the only thing holding you or anyone back is learning anything outside of a small pond of JavaScript.
Write non-browser-things in fast languages. It is not a complicated concept - even less so in an era where stuff is getting written for you.
Absolutely agree. If a JS developer doesn't know Rust, Go, Zig, or something, then they probably aren't going to do a good job at maintaining critical infrastructure, even if it were written in JS.
Why are people writing "critical" infrastructure in JS anyway, it is the wrong tool for the job.
Found it.
Large parts of the JavaScript application space too.
Language consistency, ergonomics, standard library and performance matters, and JS has major warts here. I bet when these languages are 30+ years old like JS is, the software landscape isn't dominated nearly as much by JS.
These days I intentionally start all projects with as little JS as possible, opting for Go and HTMX instead. Removing the layers of JS inconsistency and build tools makes my and my agents lives better.
More thoughts on my JS-less stack here: https://housecat.com/blog/the-hugs-stack-hypermedia-unix-go-...
tldr: interpreted languages are still slower than compiled languages, surprising no one