My experience is that it's fine(tm). "JavaScript on server-side" does not bother me; V8 is fine. It's not as fast as HotSpot, but also, I don't care. If I ever wrote something at extragalactic scale, yeah, sure, whatever, I'd rewrite hot paths in something else. But I absolutely don't care about that until then.
None of my debugging output includes JS lines because I pack source maps, which TypeScript happily includes.
Multi-threading isn't complex, because there isn't multi-threading. There's coprocessing via Promises, and there indeed are a lot of Node developers who think you don't need locking functionality because it's not multi-threaded (there was an absolutely bonkers discussion a few years ago where a JS developer insisted you didn't need locks), but whatever, they think that about other languages too, use async-lock or whatever.
"Maturity" is a word that means different things to different people. There is not a consensus-best-choice framework like Spring Boot in Node. Which leads people to doing things like "I'll use Express!" and now they have interesting problems all their own. But the tools are there and they're excellent. Fastify is perhaps The Best web framework I've ever used (other than perhaps Python's FastAPI, which makes me wish I liked Python enough to write it because that seems like a Right Answer in itself), and it has only gotten better with v4 allowing you to engage with type providers to create an end-to-end, automatically typechecked route declaration framework. It lets you do stuff like this, where you specify a request schema as JSON Schema (encoded via typebox) and it'll statically derive the TypeScript type for you whilst also using it for request schema validation:
The tools are there and you do probably want to invest a little time in understanding what they do and what their tradeoffs are. There's value in that, for the way I write code and the stuff I enjoy building.
Overall, I'll trade some compilation niceties and even some (but to be frank, not much) performance for a vastly more productive environment in day-to-day use. I really like the JVM. I've been using it professionally for twelve years. I also like the CLR. I did Google Summer of Code for the Mono Project in 2008, I've been around. But the day-to-day of writing code in the dominant languages on those platforms for things other than CRUD does frustrate me, and the general-purpose languages on the JVM and CLR present difficulties in using the type system to effectively encode intent makes it much harder for me to write software that can guide other people to not misuse it. So for me it's worse both at library-writing and at getting-things-out-the-door. (I still do gamedev experiments in Java or Kotlin, though, because libgdx is seared into my brain.)
None of my debugging output includes JS lines because I pack source maps, which TypeScript happily includes.
Multi-threading isn't complex, because there isn't multi-threading. There's coprocessing via Promises, and there indeed are a lot of Node developers who think you don't need locking functionality because it's not multi-threaded (there was an absolutely bonkers discussion a few years ago where a JS developer insisted you didn't need locks), but whatever, they think that about other languages too, use async-lock or whatever.
"Maturity" is a word that means different things to different people. There is not a consensus-best-choice framework like Spring Boot in Node. Which leads people to doing things like "I'll use Express!" and now they have interesting problems all their own. But the tools are there and they're excellent. Fastify is perhaps The Best web framework I've ever used (other than perhaps Python's FastAPI, which makes me wish I liked Python enough to write it because that seems like a Right Answer in itself), and it has only gotten better with v4 allowing you to engage with type providers to create an end-to-end, automatically typechecked route declaration framework. It lets you do stuff like this, where you specify a request schema as JSON Schema (encoded via typebox) and it'll statically derive the TypeScript type for you whilst also using it for request schema validation:
https://github.com/fastify/fastify-type-provider-typebox#exa...
The tools are there and you do probably want to invest a little time in understanding what they do and what their tradeoffs are. There's value in that, for the way I write code and the stuff I enjoy building.
Overall, I'll trade some compilation niceties and even some (but to be frank, not much) performance for a vastly more productive environment in day-to-day use. I really like the JVM. I've been using it professionally for twelve years. I also like the CLR. I did Google Summer of Code for the Mono Project in 2008, I've been around. But the day-to-day of writing code in the dominant languages on those platforms for things other than CRUD does frustrate me, and the general-purpose languages on the JVM and CLR present difficulties in using the type system to effectively encode intent makes it much harder for me to write software that can guide other people to not misuse it. So for me it's worse both at library-writing and at getting-things-out-the-door. (I still do gamedev experiments in Java or Kotlin, though, because libgdx is seared into my brain.)