No--but certain constructs could translate to slower than expected execution speed.

That's something that needs proof from a profiler. Intuition on what's "slower" is really awful, particularly for JITed languages.

I don't think you could give general advice on what is slower as that's a constantly moving target.

If TS could compile to asm.js you certainly could. (The fact that it can't is a big reason why I believe it's a fundamentally bad solution to writing JS scaleably.)

I think you mean Wasm; asm.js is dead.

Looks like assemblyscript compiles "a strict variant of TypeScript" directly to Wasm:

https://github.com/AssemblyScript/assemblyscript

This is pretty close to "running" TypeScript.

I tend to refer to asm.js and wasm interchangeably, but yes, wasm would be the technically preferable term.

Never heard of AssemblyScript, but yeah, it or a statically typed language like it is where frontend development needs to go. In concordance with my point about TS being fundamentally unsuitable, the AssemblyScript docs (https://www.assemblyscript.org/basics.html#strictness) say:

> WebAssembly is fundamentally different from JavaScript, ultimately enabling entirely new use cases not only on the web. Consequently, AssemblyScript is much more similar to a static compiler than it is to a JavaScript VM. One can think of it as if TypeScript and C had a somewhat special child.

> Unlike TypeScript, which targets a JavaScript environment with all of its dynamic features, AssemblyScript targets WebAssembly with all of its static guarantees, hence intentionally avoids the dynamicness of JavaScript where it cannot be compiled ahead of time efficiently.

You can't "run" C, or Go, or Javascript, etc.

I think the parent comment meant that typescript is a static checker, which means it's not exercised at run time but in a prior step. Therefore "performant typescript" means to shorten the time it takes to perform these static checks, not the time it takes to run your code. In contrast, when people talk about optimizing C code they most often (but not always, of course) mean to write code that runs fast.

I find the mentality around TypeScript to be bizarre.

"It's just a type checker for JavaScript" - not really. It's a language that transpiles to JavaScript and it happens to be a superset of JavaScript (namespaces and enums, anyone?).

But saying that it's just a layer on top of JavaScript sounds like saying C++ is just a layer on top of C.

> C++ is just a layer on top of C

C++ used to be just a layer on top of C, but not anymore. If it still was, it wouldn't be a bad thing to say.

Type checks that run during compilation/transpilation/typechecking do not "run" as the code is executed. This is what happens with Typescript, and that's what the original commenter was saying.

I'm not sure I understand your point. Typescript is a language with a type checker and compiler. It's the same thing with C. Typescript has to be compiled to run. C has to be compiled to run. When I think of language performance I always default to thinking about runtime performance.

> I'm not sure I understand your point.

When people talk about C performance, they mean the performance of the code written in C and (ultimately) compiled to machine language. Very seldom they mean the speed of compilation (though they sometimes do, in which case they almost always explicitly mention "compilation").

When people talk about Typescript performance, they either mean Javascript performance or, more likely, the speed with which Typescript type-checks their code; the latter doesn't happen in run time. That's what the original commenter meant when they said "you cannot run Typescript". It's also what TFA means by "performant".

Deno[0] supports running TypeScript without needing to compile it to JS.

[0] -- https://deno.land/

Deno still compiles it to JS. It just does it for you.

Which at one point gets compiled to machine code. At one point, you have to stop and say, "Yeah, this does effectively runs TypeScript", otherwise as I said, you'll end up saying nothing gets run but machine code. While that's correct, not very useful.

I think the key point in this case is that the performance characteristics of Deno don't significantly differ from TypeScript independently transpiled to JavaScript and run in Node because the compilation pipeline is more or less the same (Deno is using tsc and v8 internally)

I think the distinction will hold when you can access type information at runtime

Why? Haskell doesn't even have runtime type information. So what would you call the stuff that runs after I compile my Haskell code? Not-Haskell?