Hacker News Reader

Comment by mirekrusin | Hacker News Reader

Ts does produce code, ie. for enums, modules/namespaces.

Const enums get completely erased by the compiler, and modules are a native js feature.

Non-const enums and namespaces are probably the only aspects of typescript that actually have any significance at runtime, but they get compiled into simple objects. The compiler output is very close to what you'd write by hand. Take a look at this compiler output here [1].

Unless you're constantly recreating enums and namespaces inside of a loop (which you'd never do in real life code), I can't imagine there'd be any performance penalty.

[1] https://www.typescriptlang.org/play?target=99#code/HYQwtgpgz...

So ts does produce code.

It can (depending on which features you're using), but the comment that started this thread claimed that the produced code was much slower than handwritten js. I was just pointing out that the examples you gave (enums and namespaces), don't change the performance of your code.

Yes, that part was nonsense. Typescript maps one to one for supported features. However there was comment there that ts doesn't generate code by itself unless downgrading to historic versions, which is not true.

It would be nice if not only type system but all ts would be erasable, ie. so you can write ts to js transpiler by replacing ts code by spaces and the remaining part would be valid, runnable js.

With enums, modules/namespaces it's violated. And if it's violated already then they should just go ahead and support things like match expressions and move statements to expressions coffeescript style. Because you have insight into types, performance would not suffer - you'd pay overhead of expression-instead-of-statement if you'd actually mean to use it, which is great tradeoff.

I agree that the typescript team should consider using the compiler to extend javascript rather than just supplement it with types. Like you said, there are technically parts of typescript that don't have a direct corollary in js (enums/namespaces), so why not take it a step further and add some of the features that js is missing? The only example where they've really taken that next step is with experimental decorators.

I think in general the js/ts community is starting to realize that if we're going to have all of these build tools, we might as well use them to do more than just format, transpile, and bundle. Svelte has sort of pushed this idea with its abuse of the js label feature (it can detect when a variable is reassigned if you prefix it with the dollar sign label, which is technically not possible with js, even with proxies). There's also React Forget, which is promising to completely rewrite components at compile-time to avoid all of the gotchas that hooks have (and improve performance) [1].

In terms of making all of ts erasable, you can technically just write all your type definitions using js-doc comments, in which case the compiler can just be run with the --noEmit flag, and then the code is fully valid js without any modifications.

[1] https://www.youtube.com/watch?v=lGEMwh32soc

The article explains their stance on adding runtime features.

I read it, and I empathize with their stance. I'm actually torn between wanting Typescript to be as compatible with Javascript as possible, and wishing we didn't have to wait for TC39's process to play out before using new features (which I've written about before on hn[1]). Given their design goals though, the Typescript team has done a great job.

[1] https://news.ycombinator.com/item?id=32188944

AFAIK, enums and namespaces are considered past mistakes that won't be repeated again.

You're kind of stretching the definition of "code production" and including effectively-deprecated features: https://www.typescriptlang.org/docs/handbook/enums.html#obje...

Turning `export function a(){}` into `exports.a = function a(){}` hardly qualifies as generated code, much less "slower than hand-written"

Reply on news.ycombinator.com