Ten Years of TypeScript
devblogs.microsoft.com
Ten Years of TypeScript
1–10 of 147 posts
Re: Ten Years of TypeScript
#2Also see https://rescript-lang.org/ if you're considering learning Typescript
Looking forward to more great ideas in the future of ways to 'fix' Javascript.
Re: Ten Years of TypeScript
#3Given 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.
Re: Ten Years of TypeScript
#4Given 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.
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?
Re: Ten Years of TypeScript
#5Given 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.
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?
Most likely polyfills because he's targeting some old ES version.
Re: Ten Years of TypeScript
#6We need:
- exact object type
- match expression
flow is still better at:
- OO - nominal typing for classes, conforming to liskov substitution principles
- first class opaque types
- first class exact object types
- better flow based inference
- comment types - no extra dsl, full access to the language, so simple, so powerfull for the times you don't want transpilation phase
- [edit] spread types map to spread in runtime
Re: Ten Years of TypeScript
#7Given 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.
> 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.
Re: Ten Years of TypeScript
#8Given 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.
> 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.
Re: Ten Years of TypeScript
#9Given 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.
> 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.
Ts does produce code, ie. for enums, modules/namespaces.
Re: Ten Years of TypeScript
#10As a web-focused software engineer, I can safely say TypeScript is the best thing that happened to my work in the last decade.
Aside from the known direct benefits of safety and self-documentation, I've found over time that having a pleasant, smooth coding experience and producing elegant code required me to think differently. I work on a project with very complicated and overloaded business logic, but nowadays my code looks very... "algebraic"? state machines within state machines, exhaustive switches everywhere...
Maintaining and modifying such code has been a joy compared to the old ways. Most of the work is just adding a new member to some union or an attribute to a type, following the red trail fixing errors and voilà.