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

cogman10 · on Nov 24, 2020

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.

not_kurt_godel · on Nov 24, 2020

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.)

tantalor · on Nov 24, 2020

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.

not_kurt_godel · on Nov 24, 2020

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.