Typescript adds expressive compile time type info. typeof doesn't compare. I think the main point was that the extra safety from types made the other refactoring possible. That's not surprising since types are basically a kind of formal proof of program code.
I hear this from the first time I ever coded and still, I have never seen a study/scientific proof of that being true. Most of the time it is just gut feeling.
The example in the code was about how == and === works in JS and that '1' === 1 is not good.
In all of that discussion what people tend to forget: In the end, it is Javascript that runs.
To say typeof doesn't compare is absurd. Compile-time type-checking definitely has its uses; but people seem to forget that (unless I am very much mistaken) no type checking is being carried by the compiled code at run time. In which case you absolutely must do type-checking on data coming from sources outside your application. Typescript is not a replacement for proper data validation for which typeof is pretty much essential.
You are correct - TypeScript's checks are entirely at the transpilation level. You do occasionally need to do some checking at some boundaries, but things inside of your systems can generally be trusted to be properly typed if you have proper validation at the boundaries and rely on tsc to catch the other issues.
Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata.
The nesting on comments maybe isn't clear - but I think only one of my comments was directed specifically to you ;)
edit: And just to be clear: I thought your article was interesting; but the focus on TS as the solution to the problems you described could be inferred by some to mean that JS was the cause of those problems.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Typescript adds expressive compile time type info.
typeofdoesn't compare. I think the main point was that the extra safety from types made the other refactoring possible. That's not surprising since types are basically a kind of formal proof of program code.I hear this from the first time I ever coded and still, I have never seen a study/scientific proof of that being true. Most of the time it is just gut feeling.
The example in the code was about how
==and===works in JS and that'1' === 1is not good.In all of that discussion what people tend to forget: In the end, it is Javascript that runs.
To say
typeofdoesn't compare is absurd. Compile-time type-checking definitely has its uses; but people seem to forget that (unless I am very much mistaken) no type checking is being carried by the compiled code at run time. In which case you absolutely must do type-checking on data coming from sources outside your application. Typescript is not a replacement for proper data validation for whichtypeofis pretty much essential.You are correct - TypeScript's checks are entirely at the transpilation level. You do occasionally need to do some checking at some boundaries, but things inside of your systems can generally be trusted to be properly typed if you have proper validation at the boundaries and rely on
tscto catch the other issues.I am not mistaken. From Typescript design goals:
I feel like you're really wanting to talk.
Is that a problem?
The nesting on comments maybe isn't clear - but I think only one of my comments was directed specifically to you ;)
edit: And just to be clear: I thought your article was interesting; but the focus on TS as the solution to the problems you described could be inferred by some to mean that JS was the cause of those problems.