[dynamite-ready]

Given the number of codebases littered with 'any', and the fact that TS is known to produce app bundles that perform slower than handwritten JS code, I'm in two minds about celebrating those ten years... But it is strange to think it's been ten years.

[mumphster]

Do you have examples of slower code generated by typescript? TS is a superset of JS so it changing anything that has a large performance impact seems odd, but maybe I’m missing something here. The types aren’t even available at runtime, what’s the biggest slow down you’ve seen?

[redox99]

Most likely polyfills because he's targeting some old ES version.

[dynamite-ready]

https://thenewstack.io/which-programming-languages-use-the-l...

[int_19h]

This claims that TypeScript is an order of magnitude slower than JavaScript, which is obvious nonsense if you know how TypeScript works, unless they counted transpiling in execution time.

[jmull]

> TS is known to produce app bundles that perform slower than handwritten JS code

I’m curious about this, and runs counter to my understanding of typescript. Do you have any sources on this?

I’m googling a bit but not really finding anything.

[laundermaf]

> TS is known to produce app bundles that perform slower than handwritten JS code

Wrong. TS doesn’t bundle files. TS doesn’t produce code unless you target an earlier ES version than what you write, in which case there’s no way around it: native for-of loops and await/async will always be faster regardless of what you use to transpile it.

I think you’re confusing the tool with something else.

[mirekrusin]

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

[ksbrooksjr]

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

[mirekrusin]

So ts does produce code.

[ksbrooksjr]

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.

[mirekrusin]

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.

[laundermaf]

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"