JavaScript, in general, is awful as a language in terms of design, and more astute people have wasted many words on this before me.
It was originally designed for writing throwaway frontend code, but people liked it so much that they started using it to build their system architecture—only to realize it doesn’t work well for anything beyond glorified RPC backends.
The type system is wishy-washy, and TypeScript needs a massive type space to compensate for it. Python is also dynamically typed, but it has a strongly typed system that saves you from runtime blowups. JavaScript doesn’t even properly blow up at runtime—you just get [object Object] or some random undefined error. TypeScript is a fantastic piece of engineering from the C# guy, but even they couldn’t fix all of JavaScript’s language-level blunders.
Few people want to build mission-critical backends on a weakly typed language.
The ecosystem is a mess, and things randomly break after a few days. My Python and Go apps from 2018 still work exactly as they did on day one. Go’s gorm and Python’s SQLAlchemy are the default ORMs that pretty much everyone uses. And how many ORMs does the JS ecosystem have?
And let’s not even start with frontend frameworks—no one loves them two days later.
The Next.js project I built yesterday is already showing 69 vulnerabilities. This sorry excuse of a language, coupled with terrible design and an indecisively childish community, makes it difficult to take seriously.
You're throwing random things but you have failed to explain real world pains.
By the way you can be extremely strict and safe in typescript, it's really up to the team using it, but you can encode virtually everything and have it fully type safe.
Also, there's great tools like effect-ts if you're more functionally leaning.
If you really want to waste time on types, the bolted-on TS is never going to work as well as Golang where they're native. Maybe TS types are better than Python types is all.
To be honest, I don't like the look of Effect for the same reason I don't like error handling in Golang. It's easier to assume anything can fail (which is 99% correct) and use exceptions. But anyway, every language can be extended in many ways, so I can really only compare default vs default.
In common JS or Py use cases, static typing makes your code less safe, because all that extra time you spend on it is less time writing tests. Meanwhile the types won't catch any bugs even the most simple test coverage would.
Sure, JS has some quirks that language design gurus complain about, but nothing that actually matters on the job. Like, == operator is weird, oh well.
Python is rightfully king for certain things like data science, but parallelism and package management are two big messes in it. ||ism is trying to be fixed with asyncio, but it's kinda too late. You know packaging is broken because every Python repo has a Dockerfile, not something you see in JS where npm is solid.
Golang is more for different use cases. Looks good but really should have done error handling like Rust, or used exceptions.
My point is that the JS ecosystem is masqueraded by script kiddies who will throw a hissy fit every time someone criticizes JS, and you just proved that ;)
This is an embarrassing comment, there are few things this world needs less than more smug engineering tribalism. Even weakly typed languages. Typescript has many downsides, as does Python, and if you think the downsides of Python are trivial then I would invite you to take a look at the sea of different competing tools for environment management. I need a python env, now will that be with pyenv or venv or pipenv or pyvenv or virtualenv or poetry?
I’ve been writing JS and then TS on the backend since 2013. Built large apps, startups and while it does the job fine I’d not go with Js on the backend anymore.
We built some stuff with Go and then went with full .Net. Its like fresh air after years of Js.
- Proper static typing. This is not .net specific but bolting types on a dynamicly typed language only works to some degree. It also opens the gate to runtime type intospection such as generating OpenAPI definitions without any other input than the handler signatures themselves etc. This is handled fine by a full stack ts framework like next or nuxt and such but you are still trapped in that implementation.
- Proper multithreading and performance story. Performance itself is not the most important thing when your app mostly waits on IO. However you still get to use thread pooled async in .net or parallel goroutines in go etc and they sometimes make a difference.
- ASP.NET Core is fully feature packed and easy to work with. .net has a more cohesive ecosystem where tools, libraries, and frameworks are designed to work together seamlessly. In js runtimes, you often need to piece together different approaches and deal with compatibility issues.
- Proper standard library. Both node.js stdlib and the js globals are really weak compared to what Go or .NET or Java etc provides you out of the box. I hate dealing with npm dependencies with a passion at this point and you can have minimal dependencies when the standard library is decent. There is also the fact that upgrading an npm package is a dice roll as you need to trust the semver or check update logs etc. At least with a static typed language you get to catch public api changes on your dependencies during compile time, not in runtime.
- Linq is good, Linq expressions are great. I don't really love ORMs but I tend to use Entity Framework Core on top of low level SQL access in .NET. Makes life easier.
I don't hate TypeScript though. I still use it on the frontend obviously and I'm fine with it but given the choices on backend, it does not make much sense for me anymore.
I've been writing backend TypeScript for 8 years and it's more than fine.
It's not my favorite language but it's a great compromise, and I would never choose a Lisp, Haskell, Java or C over it (the other languages I know).