It does not interop with JavaScript.
> and in some scenarios transpile down to JavaScript
It always transpiles to JavaScript and always runs as JavaScript. There is no such thing as a TypeScript runtime engine.
TypeScript is a superset of JavaScript. Therefore the OP's point is still valid. Any "mistakes" JavaScript might have made about having null AND undefined are also issues for TypeScript.
I don't know what you mean here, but it is certainly possible for TypeScript code to use JavaScript libraries and vice versa, which is presumably what most people mean by "TypeScript interops with JavaScript".
> It always transpiles to JavaScript and always runs as JavaScript.
Technically false... https://assemblyscript.org
> TypeScript is a superset of JavaScript. Therefore the OP's point is still valid. Any "mistakes" JavaScript might have made about having null AND undefined are also issues for TypeScript.
TypeScript adds type checking to JavaScript. The Million Dollar Mistake is having unchecked nulls; TypeScript supports checked nulls so it's not an issue. TypeScript's nulls are much more similar to Maybe/Option than unchecked nulls.
Ah, I can see what you/they mean by that. The point I was trying to get across was: TypeScript doesn't exist when code is actually executing (which is what I think of as interop - it's happening at execution time.) At execution time - it's all just JavaScript.
I have found (working in a TypeScript team currently) that this fact is ignored, primarily by people who "look down" on JavaScript, but it is a VERY important point to remember when you are writing TypeScript, mostly because it's important to remember there is only compile time type checking not run time.
> Technically false... https://assemblyscript.org
Heh, yes - as soon as I posted I realised that was silly. The word "always" is almost "always" incorrect! I should have said: "It usually transpiles to JavaScript and usually runs as JavaScript"
> The Million Dollar Mistake is having unchecked nulls; TypeScript supports checked nulls so it's not an issue. TypeScript's nulls are much more similar to Maybe/Option than unchecked nulls
Good point in theory but my practical experience hasn't borne this out. That is because TypeScript is an "optionally typed" language and it hasn't been true in practice because of excessive use of explicit or implicit "any"s.
<i>Good point in theory but my practical experience hasn't borne this out. That is because TypeScript is an "optionally typed" language and it hasn't been true in practice because of excessive use of explicit or implicit "any"s. </i>
I think that's a matter of your team's discipline. It's good practice, I think, to enable TypeScript's strict checks, including no-implicit-any, and, to the best of your ability, to keep people who don't understand types ignorant of explicit any and to fail any code that uses it. `any` is basically never necessary even in typing existing code - if you genuinely don't know what the type is at a certain point, you should probably write a type like `unknown`.
If you take any of Typescript's options to "ease the transition" you're taking Typescript's options to continue the difficulties. One moves to typescript because javascript's runtime errors are a problem; so it is natural that you will have novel compile time errors.
> It does not interop with JavaScript.
Hm, this depends on your definition of "interop". My JavaScript and TypeScript are languages that exchange information. The execution model ultimately involves JavaScript when I use tsc, but ultimately it also includes an interpreter. My user-space syntax doesn't care.
> There is no such thing as a TypeScript runtime engine.
Not being glib, just a heaps up: https://github.com/denoland/deno
interesting thanks for the heads up - my assumption is though that this is just a wrapper over a V8 engine with typescript compilation on the fly?
Does that make it a TypeScript runtime or not?