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

i) You could say the same thing for the underlying language: EcmaScript has evolved so much in recent years that new packages may use runtime language features that are not supported by an older interpreter runtime.

ii) You could argue that types themselves can be documentation, if named correctly. A JS library without types but great documentation is vulnerable to implementation changes that are not reflected in the documentation. TypeScript at least binds the internal assumptions on function arguments and object types to how they should be used, with a tool to check that there is a match at the call site. Throw in some runtime parsers (eg: Zod) to enforce correct input data at runtime, and from which types are inferred, and you are golden.

iii) Agreed, 100%. Some people are making tools around that, see Matt Pocock's Total Typescript error explainer extension in VSCode: mattpocock.ts-error-translator

iv) Agreed again. Transpilation itself can be fast with modern tooling such as SWC or esbuild (or derivatives). Type checking is still the main bottleneck, though people like Donny (@kdy1dev) are working on a Rust-based alternative.

https://www.totaltypescript.com/rewriting-typescript-in-rust




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

Search: