[shadowgovt]

propTypes does runtime type checking, which is a different kettle of fish from static type checking.

The advantage to static type checking is that it removes the performance cost of runtime type checking where it's unnecessary; the language's rules make it impossible to build some constructs where the wrong types get mashed together. The tradeoff is that you have to code so the wrong types don't get mashed together (which is, arguably, your goal in the first place).

You can do everything a statically-typed language does in a non-statically-typed language via best practices, but that's a bit like saying you can do everything a compiled language does in assembly via emulating what the compiler would output. In theory, the compiler is saving you the headache of doing that (but depending on the size of what you're trying to write, sometimes it is simpler to write it in JavaScript and skip the type safety. That code is harder to grow, but not all code grows!).

[nathias]

So the whole baroque arhitecture is there to 'remove performance costs'? That's an even worse reason to use TS than avoiding prop type bugs.

[shadowgovt]

This is a good response to drill down on, because the poster's assessment of the purpose is accurate.

Yes, much of both TypeScript and React are there to minimize performance costs and improve software reliability in tens-of-thousands-of-lines-of-code projects: TypeScript is using static type safety to replace the need for dynamic typechecking (decreasing the expected runtime error rate and the runtime cost of dynamic type analysis; static typing tells you both when you must runtime-coerce types and when such coercion is unnecessary and would waste performance). React is using delta-detection of lighter-weight objects to determine when heavier-weight objects in a declarative user interface API need to be changed, impacting performance (because a handful of equality compares against objects or plain data is a fraction of the cost of repainting every pixel in a table with pixels representing the exact same information as before to the end user).

These are problems people face, but if they are not the problems you're facing, they might not be the tools you need. Not everyone is writing the Facebook UI. There are lighter-weight tools out there that solve similar problems with less complexity (the tradeoff, perhaps, being that if you do find your software needing to scale to handle updates to represent complex, heterogeneous data or infinite streams of information, those tools might not scale easily... But how many people actually have that problem?).

"Use the right tool for the job" is one of the cornerstones of the art of software engineering.

[nathias]

Yes, the right tool for the job, but because TS covers a set of tools its rare that this is exactly the tool you need. I'm sure there are cases but mostly I think people just use it because of the hype/preference and I really hate to make prototypes with TS.

[shadowgovt]

Yeah, prototypes are probably the wrong use case for React or TypeScript because they can crash without causing someone $X million in revenue (by definition; if it can cost someone $X million in revenue, it's no longer a prototype and the team maintaining it probably wants stronger guarantees than what native JavaScript provides for proper use of APIs and data handling if they ever want to sleep at night).