Live data from Hacker News

Ten Years of TypeScript

devblogs.microsoft.com

61–70 of 147 posts

Re: Ten Years of TypeScript

#61
post #58

I've spent the last two years working with TypeScript solely. Coming from ~20 years with PHP and using Kotlin and Dart for some years as well, I feel that I'm doing something wrong. I absolutely loathe working with TypeScript. The community is the most fragmented I've ever experienced, the silly amount of package managers, builders... TypeScript just doesn't fit with me.

Typescript itself is fine. But yes, if you are using 3rd party libraries and frameworks with typescript, you might wonder if it's too late to change career and become a monk.

Re: Ten Years of TypeScript

#62

Earlier quoted context omitted.

When you can write a busy beaver machine in the type system, LOC ceases to be a good indicator or how long something should take to typecheck, imo. If you're frustrated with your build, you should use the trace tools on the TS wiki[1] to track down what types are slow to check, so you can attribute the slowness to the appropriate library authors/yourself and decide for yourself if the speed/correctness tradeoff they'…

My code is straightforward and doesn’t do advanced type operations.

Check your libraries. Some are really trash and mess with Typescript's speed. Material UI comes to mind.

Re: Ten Years of TypeScript

#63

Earlier quoted context omitted.

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.

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, m…

AFAIK, enums and namespaces are considered past mistakes that won't be repeated again.

Re: Ten Years of TypeScript

#64
I've always been a big proponent of TypeScript, but does anyone else feel like the type system has gotten a bit too flexible? I recently had to fix some errors when upgrading packages on an old project, and it was not at all clear what was wrong by just reading the compiler output. For some errors, there were like 5-10 lines of confusing info/context, it felt like trying to understand the errors reported in template-heavy C++.

Re: Ten Years of TypeScript

#65
post #47

Generally a huge positive. With tools like swc, there's really fast compilation & typechecking now. With --watch, the DX is pretty good but yeah sometes has to be restarted anyways. A couple not so greats: Typescript has added a lot fo confusion & chaos to the ESM transition. A lot of typescript code is in ESM style, byt if you pull the package, it outputs cjs or what not. TypeScript 4.8- very recent- is the first to…

I thought swc still doesn’t do type checking and just strips the type annotations?

Hrrmmm. I've been using the newer Jest testing library releases & they are supposedly powered by SWC. I definitely see some typechecking errors, & assumed this was also swc. But I see little evident in the swc project they've made headway here.

Im not sure what Im experiencing in jest. It's definitely not the same level of typechecking. But there's definitely something there & it's definitely much faster start time. Thanks for writing; Im curious too.

Re: Ten Years of TypeScript

#66
> "Align with current and future ECMAScript proposals."

But they admitted namespaces, enums, and interfaces into the language (the latter becoming more and more confusing as type aliases got more expressive),

> "Avoid adding expression-level syntax."

Is "as", "is", or "satisfies" expression-level?

> "Use a consistent, fully erasable, structural type system."

But the enums!

Re: Ten Years of TypeScript

#67
post #20

This seems like a great time to announce my successor to CoffeeScript: Civet, a language that transpiles to TypeScript. https://github.com/DanielXMoore/Civet

Oh, I like this. A pure syntactic sugar over a language that otherwise preserves semantics is neat. Nice work on documenting what was kept/changed/removed too. Really easy to see at a glance what the project is all about.

Love that there's an online playground, LSP, and VSCode extension along with it.

Re: Ten Years of TypeScript

#68
post #10

As 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 co…

The real genius of it is that it's really not a "type" system at all: it's a contract system. The nearest thing like it was Eiffel. The new "satisfies" feature in 4.9 makes this even more clear. Honestly there's so much space to cover here, I think it's just going to keep getting better and better.

Re: Ten Years of TypeScript

#69
post #67
post #20

This seems like a great time to announce my successor to CoffeeScript: Civet, a language that transpiles to TypeScript. https://github.com/DanielXMoore/Civet

Oh, I like this. A pure syntactic sugar over a language that otherwise preserves semantics is neat. Nice work on documenting what was kept/changed/removed too. Really easy to see at a glance what the project is all about. Love that there's an online playground, LSP, and VSCode extension along with it.

Thanks! It's still a work in progress (especially the LSP) but it is usable in its current state and is getting better all the time.

Re: Ten Years of TypeScript

#70
post #36

Earlier quoted context omitted.

Flow feels almost like the Betamax to Typescript's VHS - Flow is better technically in many ways (in addition to the things you mention, I miss being able to spread the properties of one type into another, rather than having to inherit from an interface), but in practice, in terms of engineering cost, it's so much more expensive that it's hard to justify using it. Flow's team have made it clear [0] that they don't ca…

>I miss being able to spread the properties of one type into another, rather than having to inherit from an interface) What would that achieve that intersection types don't already?

Spreads are ordered, and try to match the semantics of object spreads at runtime. Intersection types don't do that, they express that the type is both things at the same time. It is most obvious when dealing with types that have overlapping properties: [typescript with intersections](https://www.typescriptlang.org/play?#code/C4TwDgpgBAglC8UDeA...) [flow with spreads](https://flow.org/try/#0C4TwDgpgBAglC8UDeAfAUFTUBmB7XAXFAHYCu...).
Post reply on HN