Javascript already has standard serialization and deserialization tools.

The problem is that the deserialization is untyped. It's just a Javascript object. Usually, the first thing you'll do is to cast it to a typed Typescript definition, but there's no way to guarantee that it actually fits that definition. No type information exists at runtime. It's used solely to check the code itself during compilation.

So any time you get data from outside of your program (over the network, from a database, out of a config file, etc.) you just have to hope that it actually fits the type. You can write code to check it... but you have to write that code yourself.

There are libraries you can use. For example, you can use a Data Description Language with a simpler type system, which usually suffices for the kind of data you want to serialize. Then you can use that to generate both a Typescript definition and a runtime type checker. But that's inelegant, and not standard, so every project is different despite it being something everybody needs.

It's basically the same for typed languages. If you want to map JSON to a typed data structure, you need a serialization library to do that.

JavaScript has a very simple built-in json reader/writer that does no type checking and returns some nested dictionaries or arrays. If you want more, you need a library (for example zod). Or you just trust the data to have the right shape.

Java has runtime type definitions, which you can use to automatically type check deserialized objects. With reflection you can write that in ordinary Java.

I imagine C# and other Java-esque languages have something similar. But Typescript deliberately avoids that, and it would be difficult to get it to do so.

There is currently no good way to automatically validate the object input to a typescript API. In the way that you can simply specify the class of a POST body to a spring boot controller or Asp.Net controller, every class in typescript requires you write the type information twice: once for the typescript compiler, and once again for the runtime deserializer, in the form of decorators. Having to write extra code to make up for a deficiency in your framework, runtime, or language is the definition of code smell. As such: all typescript backends which attempt to properly validate user input are guilty of egregious codesmell.

Additionally, because it is impossible to emit these types to the runtime, even in the form of a string naming the type, you cannot validate input to an API using generics. If you have, say, a class which will run a query for a record based on the keys in that record:

    class Query<T>{
        filter: Array<keyof T>
    };

The typescript compiler can validate if a string in "filter" is, in fact, a key of the class T. However, you cannot write any decorator on this class to make the information of what keys exist on T available at runtime. Therefore, to write such a query interface and validate it at runtime, every record which can be queried with this object must have its own specific "[Record]Query" class written with its own decorators to validate every possible input, usually with the valid keys hardcoded into the decorator.

Because there is no real relationship between the class and the runtime validators, this makes validation more error prone, because it relies on either human beings to consistently remember to add new fields to the relevant decorators, or a custom linting tool to be written which basically pre-processes the typescript source using the typescript API. This is, again, writing code to account for the lack of features in the framework.

WHY do we put up with this crap? We have had Java and C# for a long time, and they solved these problems a long time ago. Why are we writing Typescript on the backend?

The simple answer; it is easier to find javascript developers than it is to find java developers. Bootcamps don't teach Java or C# because there's more react jobs out there. Bootcamp grads are not generally coding enthusiasts and so re-tooling is difficult for them and they don't generally do it for fun. So, we decided to write our backend in Javascript (or Typescript) as a labor decision, not a technology decision.

My experience is the opposite of yours. With typescript I use an openapi spec to validate and generate types. For other entry points I use typebox to create validators and generate types. It requires a bit of work, but it adds a lot of capability even beyond basic deserialization.

With c# I've seen openapi interface generators that don't validate properly, only basic deserialization. I've seen dto's that are deserialized wrong due to lacking null checking attributes. I've seen the way put requests are misused due to how difficult it is to separate null and undefined in patch requests. I've seen dto's with all nullables due to the lack of union types. Maybe I've yet to see a good c# codebase, but I certainly prefer typescript over the above.

My preference is to have my types defined in code first, rather than in markup language files which generate the code. Having to rely on 3rd party code generation tools because your language lacks a feature is, as I see it, code smell. I'm not sure how to handle the scenario of undefined fields in a PATCH, but I also don't tend to write APIs that way