Skip to content

JSDoc vs. TypeScript: When is it time to switch?

Does every single project actually need the complexity of a strict typing system? Sometimes, I find myself tempted to just go back to raw JavaScript, using JSD…

2 min read
JSDoc
TypeScript
Migration
JavaScript
checkJs

Does every single project actually need the complexity of a strict typing system? Sometimes, I find myself tempted to just go back to raw JavaScript, using JSDoc patterns and turning on // @ts-check. Technically, it gives you much of the same protection because the IDE will still flag type mismatches.

There is no absolute right answer here. JSDoc wins if you want your runtime artifacts to remain plain JavaScript files. For example, if you're writing a small CLI script or a simple Node.js automation that doesn't need a long build process. It allows for a progressive enrichment of legacy code without a total structural overhaul. You can just blast ahead with the coding without the heavy overhead of tsc right out of the gate.

However, TypeScript has an edge that’s hard to beat once a project grows. When you need shared domain types used across various packages, or when you have to perform a massive refactor on complex business logic, TypeScript is the winner. Even using deep generics feels much more natural and powerful there.

Problems arise if you try to force JSDoc into a large-scale project. Those JSDoc annotations eventually turn into a wall of asterisks—so much noise that they actually make the code harder to read. TypeScript stays much cleaner once the scope of your data types starts expanding significantly.

Of course, TypeScript isn't perfect. There is the extra time and effort spent on configuration and wrestling with type errors that can sometimes feel a bit too pedantic. It’s not really about which one is "correct" technically; it’s more about resource management and the overall cost.

My usual strategy is to just start coding with raw JavaScript so the mental flow isn't interrupted by strict compilation. But I’m always watching for when the system starts to feel unsafe. If managing types manually starts to feel overwhelming, that’s the signal to transition to TypeScript.

Not everything needs TypeScript from the very first line of code. Sometimes simplicity is the key, provided you know exactly when to add that extra layer of safety.