Typescript doesn't necessarily make your code any more stable than equivalent vanilla JavaScript that validates function arguments properly. However, it does make the code more terse and the types more apparent. It adds some build time complexity and also requires (depending on how you configure it) that you define types for every little thing (e.g. argument objects passed into functions). In IDEs, you tend to get better autocomplete on Typescript than JavaScript. That said, I still prefer JavaScript.
vanilla JavaScript that validates function arguments properly
Validating perfectly at run time is exceedingly difficult and tedious. Does anyone actually write defensive code like this?:
function sum(arr) {
if (!Array.isArray(arr))
throw "Invalid type";
let result = 0;
for (const val of arr) {
if (typeof val != "number")
throw "Invalid type";
result += val;
}
return result;
}
By contrast, the TypeScript code is reasonable:
function sum(arr: Array<number>) {
let result: number = 0;
for (const val of arr)
result += val;
return result;
}
> it does make the code more terse
No, TypeScript code with explicit type annotations is less terse than the typical unsafe JavaScript code that lacks type checks.
It requires that you define types for every little thing
No, the TypeScript compiler has type inference. It can assign types based on how values are passed between known functions. While it's a good idea to explicitly type all function signatures in TypeScript, it's not mandatory unlike Rust.
The thing is, though, that Typescript is not solving runtime type checks. Typescript is declarative, it does not check at runtime and if you have any code interacting with third-party data sources and you do not check there, things will explode down the line.
I half agree with your response. It's true that third-party data sources need to be validated using runtime type checks, whether in explicit custom code or through some schema validator framework. But TypeScript is very helpful in the common case where the caller is fully typed, so the callee doesn't need to do all the needless defensive checking.
Additionally, TS allows the team to be more confident in refactoring, or updating dependency versions, where the interfaces and argument types may change (because obviously, semver is not ubiquitous, and also not fool proof).
The incompatible changes are more likely caught at compile time, and far less likely to become apparent only when deployed.
That said, also TS itself is not fool proof - there are times where the config in use (strict vs. non strict null checks) and other factors (e.g. de-serialising JSON) can mean that your data does not in fact match the expected types.
Typescript doesn't necessarily make your code any more stable than equivalent vanilla JavaScript that validates function arguments properly
You're confusing runtime checks with compile time checks. If you mess types while developing, you will know instantly with TypeScript but you'll find out during testing with JavaScript (or in production)
Typescript doesn't necessarily make your code any more stable than equivalent vanilla JavaScript that validates function arguments properly
I don't agree. 99% of javascript/typescript programs will be dealing with data that is potentially null and without strict compile time type checking that typescript affords writing correct javascript programs is almost impossible.
I think it is very possible. There's a simple technique for that: check everything, all the time. As I said, it's tedious but it's far from impossible. You can probably optimise it by checking less things in practice.
Comments
Typescript doesn't necessarily make your code any more stable than equivalent vanilla JavaScript that validates function arguments properly. However, it does make the code more terse and the types more apparent. It adds some build time complexity and also requires (depending on how you configure it) that you define types for every little thing (e.g. argument objects passed into functions). In IDEs, you tend to get better autocomplete on Typescript than JavaScript. That said, I still prefer JavaScript.
Validating perfectly at run time is exceedingly difficult and tedious. Does anyone actually write defensive code like this?:
By contrast, the TypeScript code is reasonable: > it does make the code more terseNo, TypeScript code with explicit type annotations is less terse than the typical unsafe JavaScript code that lacks type checks.
No, the TypeScript compiler has type inference. It can assign types based on how values are passed between known functions. While it's a good idea to explicitly type all function signatures in TypeScript, it's not mandatory unlike Rust.
The thing is, though, that Typescript is not solving runtime type checks. Typescript is declarative, it does not check at runtime and if you have any code interacting with third-party data sources and you do not check there, things will explode down the line.
You would have to check your third party data sources anyway? I fail to see how this is a knock against typescript.
Setting the type of unknown data to `unknown` forces you to validate it.
I half agree with your response. It's true that third-party data sources need to be validated using runtime type checks, whether in explicit custom code or through some schema validator framework. But TypeScript is very helpful in the common case where the caller is fully typed, so the callee doesn't need to do all the needless defensive checking.
Oddly enough, Typescript would be more useful if the type checks transpire to explicit defensive code. Otherwise, it’s just, eh.
Additionally, TS allows the team to be more confident in refactoring, or updating dependency versions, where the interfaces and argument types may change (because obviously, semver is not ubiquitous, and also not fool proof).
The incompatible changes are more likely caught at compile time, and far less likely to become apparent only when deployed.
That said, also TS itself is not fool proof - there are times where the config in use (strict vs. non strict null checks) and other factors (e.g. de-serialising JSON) can mean that your data does not in fact match the expected types.
You're confusing runtime checks with compile time checks. If you mess types while developing, you will know instantly with TypeScript but you'll find out during testing with JavaScript (or in production)
I don't agree. 99% of javascript/typescript programs will be dealing with data that is potentially null and without strict compile time type checking that typescript affords writing correct javascript programs is almost impossible.
It's tedious but it's far from impossible.
Without an automated system telling you where to add checks for possible undefined values I think it's actually impossible in practice.
I think it is very possible. There's a simple technique for that: check everything, all the time. As I said, it's tedious but it's far from impossible. You can probably optimise it by checking less things in practice.