Comment by drschwabe
1 day ago
Same here, and if you really need its key features just add JSDoc and Zod to any given vanilla JS codebase.
Passing around mixed types is not necessarily an anti-pattern either ie- you can do type-checking at runtime and use them as conditions for branching into different control flow patterns - so I don't see the benefit of universal enforcement; not that most TS codebases do anyway (ironically).
I personally don't have a need for TS which introduces an extra build step, extra ritual when defining functions, and no performance benefit over vanilla JS. If I want stricter coding pattern with performance benefits I will use C/C++ for the job instead.
Basically every JavaScript server runtime and build tool supports TypeScript out of the box these days, so the only situation where it adds an extra build step is if you were previously serving your JavaScript source files directly to browsers. Which is okay at small scale, but if you have a substantial-size app with a real userbase, you're wasting a lot of your users' bandwidth if you do this.
TypeScript and Zod serve complementary, mostly non-overlapping purposes; the former detects bugs in your code, while the latter validates data that comes from outside your program and so can't be trusted. There likewise aren't that many use cases where you can choose between C/C++ and JavaScript/TypeScript based on personal preference; usually only one of the two is suitable.