I assumed it was going to be about compilation as the subject is TypeScript, which feels like a safe assumption. I suppose there could actually be runtime consequences of TypeScript too, as you’re still writing runtime code, just through a game of telephone with TypeScript :p
> I suppose there could actually be runtime consequences of TypeScript too, as you’re still writing runtime code, just through a game of telephone with TypeScript :p
Right. One of the first things you learn while doing TypeScript is that interfaces don't exist after compile time. So in general, it's better to write interfaces and use plain-old-objects than to use `class`, which generates real JavaScript code.
Within reason, of course. Classes are still useful. But it's not necessarily the first thing to reach for.
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 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.
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++ 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.
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".
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)
In practice I don't think there are, but it's not inconceivable that there could be performance considerations specific to how TypeScript generates JavaScript.
faster compilations and editing experiences
i.e. not runtime perf.