I don't hate node, I just realized that on the server-side, by the time I added enough modules to make something work I could get better performance from a Jaka

I don't hate node, I just realized that on the server-side, by the time I added enough modules to make something work I could get better performance from a Jakarta EE application server and write far less code. Go's standard library comes with a lot of the same batteries built in and while I write more code in Go, the compiled binary is small (good for container management) and I use less dependencies. So that last sentence is the key. When I was writing a lot of Java, I learned to curate my dependency graph carefully. When writing in Go, I've become even more careful to only use widely-adopted packages though I'm a bit more lenient with test-only package. I've predominately stopped using Node.js because it's dependency graph is simply unmanageable. Node.js itself provides a facade of multiprocessing as well as other niceties you'd expect to find on the server-side but to do anything substantial you either need to code it yourself or you adopt a huge dependency tree. Downstream security vulnerabilities and bugs mean you're continuously updating versions and it's not always pretty. Now that I've adopted the write a bit more code and use fewer dependencies mentality, perhaps I should try another project in Node.js. I have to admit that Typescript (and even some of the EMCA improvements) also make it more attractive.