After shipping two game projects — one in vanilla JS and one in TypeScript — here's my honest comparison:
My current approach: start prototypes in JS, port to TS once the architecture stabilizes. Best of both worlds.
Interesting approach! I've gone full TypeScript from the start on my last few projects and I'd push back slightly on the "prototyping friction" point.
If you use any liberally during prototyping and then tighten types later, you get the speed of JS with a path to strictness. The // @ts-ignore comment is your friend during rapid iteration.
But I agree the ECS + generics combo is painful. I ended up writing a code generator for my component types.
Mostly agree, but I want to flag one area where TypeScript caused us real friction in a game project: highly dynamic component data. We had an entity system where components were keyed by string and values could be numbers, vectors, or arrays depending on context. TypeScript's type system kept pushing us toward either massive union types or any escapes, and the resulting type spaghetti was harder to read than the equivalent JS would have been.
The fix was to model component data more strictly from the start — which forced better architecture — but it cost us real time mid-project during a refactor. So I'd add to the tradeoffs list: TS rewards you for having a clear data model upfront, but it charges you for exploratory, prototype-phase coding where the shape of things is still evolving.
My current approach: start new systems in a .ts file with explicit any and // TODO: type this comments, then tighten types once the design stabilizes. Gives you the JS flexibility during discovery without abandoning the TS endgame.
