Comment by tovej

I'm using bash for simple build problems like building dynamic component lists, when bash gets too unwieldy I switch to python. If the build process is stable enough and the scripts are beginning to get long, I'll rewrite the script as a CLI tool in a typed and compiled language.

Rinse and repeat.

The only thing that's really missing to me is bundling, which feels like a bit too big of a project to tackle on my own. But my current projects aren't big enough to need that, I'll pass that hurdle when it comes. And I may have to run webpack as a separate build process through node, but luckily I can do that in a CI container, and keep my dev machine clean.

> the event loop of JS performs very well as well

that's the very opposite of my experience! Or rather it does perform, in the sense that I don't think there's much margin for improvement, but the very concept of single-threaded server that switches context on IO is so flawed and painful.

    - Any vaguely CPU-intensive operation is a risk for latency to shoot up across every request.
    - You can never trust your monitoring: if I see that latency for an endpoint spiked, is it because something did happen to this endpoint OR an unrelated request hogged the CPU OR because the metric collection itself was CPU-starved
    - CPU profiling of a request is near-impossible because all requests are handling in a single thread
    - It doesn't play nicely _at all_ with k8s CPU resource management

I spent many hours looking at various dashboards, trying to guess whether what I was looking at was a cause or a symptom or just noise. Any hypothesis of what is going wrong needs to take into account the weirdness and side-effects of the event loop. As much as I love the Typescript language, operating Node is a nightmare.