12 ms·

> just happens to interop with It does not interop with JavaScript. > and in some scenarios transpile down to JavaScript It always transpiles to JavaScript a

by autora 7y ago

> just happens to interop with 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.

Zarel 7y ago
> It does not interop with JavaScript. 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 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.
- autora 7y ago
 > 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". 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 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.
 - squiggleblaz 7y ago
 > 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 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.
- vimslayer 7y ago
 AssemblyScript is not TypeScript. Especially so if you don't consider TypeScript to be JavaScript; I'd argue that the difference between TypeScript and AssemblyScript is bigger than TypeScript and JavaScript.
KuhlMensch 7y ago
This does not necessarily invalidate your wider points, but just FYI: > 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 https://github.com/denoland/deno
- vimslayer 7y ago
  Can you really consider Deno to be a "TypeScript runtime engine" when it compiles TypeScript to JavaScript and runs it in V8, a JavaScript engine.
- autora 7y ago
  >Not being glib, just a heaps up: https://github.com/denoland/deno 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?
  - eyelidlessness 7y ago
    V8 is a JavaScript runtime that compiles JavaScript on the fly, so it seems reasonable to say that a runtime that compiles TypeScript on the fly is a TypeScript runtime.

by autora 7y ago

Zarel 7y ago

> It does not interop with JavaScript. 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 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.

autora 7y ago
> 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". 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 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.
- squiggleblaz 7y ago
 > 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 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.
vimslayer 7y ago
AssemblyScript is not TypeScript. Especially so if you don't consider TypeScript to be JavaScript; I'd argue that the difference between TypeScript and AssemblyScript is bigger than TypeScript and JavaScript.

KuhlMensch 7y ago

This does not necessarily invalidate your wider points, but just FYI: > 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 https://github.com/denoland/deno

vimslayer 7y ago
Can you really consider Deno to be a "TypeScript runtime engine" when it compiles TypeScript to JavaScript and runs it in V8, a JavaScript engine.
autora 7y ago
>Not being glib, just a heaps up: https://github.com/denoland/deno 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?
- eyelidlessness 7y ago
  V8 is a JavaScript runtime that compiles JavaScript on the fly, so it seems reasonable to say that a runtime that compiles TypeScript on the fly is a TypeScript runtime.