Hey there, speaking as a champion of the proposal, the TypeScript PM, and a representative in TC39 for 6 years, we're not trying to impose anything or pressure anyone. We hope to present this proposal, and are fully open to discussion and criticism. We are committed to working with other standards representatives, working through the stage process, and not "pushing weight" around here.

I wasn't there for ES4; however, the type semantics of ES4 is a drastically differ from what's being proposed here. There is some information on the FAQ about why runtime types are a non-starter. (https://github.com/giltayar/proposal-types-as-comments/#why-...)

This comment probably won't count for much - actions speak louder than words. Hopefully we can demonstrate that we're being genuine here.

Technically, yes, but we don't expect most users to stumble onto this page unless they're already hitting perf issues.

Haha, good thing it's on HN now then :P

Glad you asked! We're trying to find good ways to help people investigate this. One of my colleagues wrote up on his work on TypeScript 4.1's `--generateTrace` flag: https://github.com/microsoft/TypeScript/wiki/Performance-Tra...

That page can give some guidance on diagnosing what the compiler's time is going into. Most users won't need to do this, but there are plenty of bigger teams/organizations that are really invested into TS and do want to keep their build times lean.

In chatting with users, I've heard the generated types vary in quality by a lot depending on the tool you pick. Supposedly this one is pretty good: https://graphql-code-generator.com/docs/plugins/typescript

Hi all, original author of the wiki page here. Please take the advice with a grain of salt. Specifically

- union types aren't always bad, DON'T avoid them

- DON'T feel the need to annotate every single thing

Please apply a critical lens as you read through this page. The document was meant for users who've hit rough perf issues, and we tried pretty hard to explain the nuances of each piece of advice.

In spite of the HN headline, I'm glad the wiki page doesn't use the word "performant."

However, I was surprised that "performance" refers to compilation/editing speed rather than execution speed.

From someone who is working on a couple of now larger Typescript apps (both frontend and backend) I’ve began noticing compilation take long enough that I have a currently low hanging (but will obviously increase in priority) TODO to go through and refactor to improve compilation speed. I wouldn’t know how to google for this other than using the word “performant”. Although I realize in most cases performance specifically deals with production execution and what end users experience/perceive, I at least believe performance is not incorrect to describe what the author is helping with here.

> TODO to go through and refactor to improve compilation speed. I wouldn’t know how to google for this other than using the word “performant”

But you already used the words naturally in your sentence, "compilation speed". A quick google search brought up lots of useful results with 'typescript compiles slow', 'typescript compile faster', etc.

It makes sense to me since TypeScript compiles but otherwise does not execute. If you want faster execution speed don’t do ridiculous things in your JavaScript.

A personal app I am working on is about 2mb of TypeScript now and takes about 6.5s to compile on my laptop.

I agree compilation speed really only affects the developer in the build chain. Execution speed affects the client and the end user. Seems like the focus should be more on the latter.

Do you have any tips on diagnosing what a problem might be? I don’t know how to interpret the diagnostics flag output to actionable changes to my company’s code, and while I can blindly do what the wiki article suggests (found it a while back when trying to figure out what to do) I would much prefer if I weren’t just trying time consuming changes to our large codebase randomly... been stuck with slow compile performance with typescript for almost a year now and I can’t tell what I’m supposed to do, or if the TypeScript compiler is just too slow.

Thanks for these tips; really interesting. Getting a clearer understanding of the differences between types and interfaces, and got some confirmation of the merits of writing explicit return types.

I was wondering whether any more could be done to improve editing performance when large .d.ts files are included. This is a problem in particular for NativeScript, which has a vast set of large types files to include to express the entirety of the iOS and Android SDKs, e.g.: https://github.com/NativeScript/NativeScript/tree/master/pac...

In fact, the skipLibCheck flag was originally developed to improve NativeScript compile time: https://github.com/microsoft/TypeScript/issues/8521

Unfortunately, editing still feels slow to me when including NativeScript’s iOS/Android types (have to wait 1-2 seconds after any keystroke for any IntelliSense to appear); beyond including fewer of the types files, could editing performance be improved somehow?

Thanks!

TypeScript team member here: the structures are arbitrarily deep and recursive. Also, as explained in a sibling comment, it's not just about type identity, but type assignability.

This comment was quite the roller-coaster for me with that first sentence :D

So glad to hear that you're happy with the release, and thank you for the kind words.

+1 on that roller-coaster ride too

This gets brought up a lot - but I work on both TypeScript and within TC39. Adding a type system needs consensus from the committee, and ideally we would never leave the existing community behind (because that'd be a standardization failure) and at some point someone will need to implement the static type checking portion.

Who would do that apart from existing type-checkers? A team like TypeScript, that's who. :)

VS Code's JS support is actually still powered by TypeScript. I'm not 100% sure exactly what you were experiencing, but it's intentional that VS and VS Code automatically download types when powering JavaScript contexts because we try to make things "just work" for JS users.

I don't think you are saying anything in conflict with me.

VSCode tries to give you type info in contexts where Typescript wouldn't (e.g. importing Javascript files, in a completely non-TS project) so it makes sense that its inference tooltip can be more helpful. You can easily recreate this by importing a fn from a JS module and then hovering it in VSCode (also configured for Typescript): VSCode knows the fn signature but Typescript won't. Both cases show up in the tooltip (though confusingly).

At least, that's my interpretation of this sort of tooltip: https://i.imgur.com/lXS5teK.png

And to be clear, your last sentence was my exact praise for VSCode at the end of my own comment.

> intentional that VS and VS Code automatically download types

Are these coming from DefinitelyTyped?

Indirectly, sometimes. They come from npm, but the largest chunk of type packages for libraries that do not provide their own types on npm are serviced from DefinitelyTyped (via the `@types` organization and its long tail of shadow packages).

Hey all, I work on the TypeScript team. I've been super happy to read some of the posts about the migration on Execute Program. If anyone has any feedback or questions on TS, I can also try to answer them.

Noticing the time when you posted your comment -- how big is the TypeScript team, and how many time zones does it cross?

In total there's roughly 20 people, more or less split between core compiler/language service and VS editing scenarios for JS & TS. We also work pretty closely with the VS Code team on their integration.

> Noticing the time when you posted your comment

Uh, I am just kind of a night owl. Most of our team members work out of Redmond, WA, and our distributed members are either on the East or West coast of the US.