Hacker News new | past | comments | ask | show | jobs | submit login

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?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact