Live data from Hacker News

Ten Years of TypeScript

devblogs.microsoft.com

71–80 of 147 posts

Re: Ten Years of TypeScript

#71
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?

They map onto same type as runtime spread, ie. order matters last one overwrites.

Re: Ten Years of TypeScript

#72
Typescript as a language isn't too bad but the ecosystem is an absolute dumpster fire. NPM is terribly fragmented, costs a fortune in effort to maintain dependencies, security updates etc... Every Typescript/JS project I work on is full of a dangerous amount of third party dependencies - it can be hundreds if not thousands in a single repo - many of them fragile in their own special way. Language packages management is hard - but it seems especially hard with TS/JS.

Re: Ten Years of TypeScript

#73
post #30

Earlier quoted context omitted.

The idea is that two types with the same structure aren't always the same thing. This is easily solved by a tagged type in TS [1], though a bit of syntactic sugar over it would be nice. [1]: https://kubyshkin.name/posts/newtype-in-typescript/

In practice I’m very happy with structural types. It provides all the safety I could wish for and slots in well with the underlying language and broader ecosystem. Though I do miss an easy way to create something like a type Email of string, as it conforms to a set of rules. But that’s a small price to pay.

Flow has structural typing on types and nominal on classes with correct inheritance semantics, which simply makes sense.

For making Email type distinct from string, you want opaque type (first class in flow) which you can emulate as tagged type in ts.

Re: Ten Years of TypeScript

#74
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.

Wow! `satisfies` solves a problem I was working on yesterday. Remarkably, it's not the first time a new TS feature immediately makes way into my code.

Re: Ten Years of TypeScript

#75
post #74

Earlier quoted context omitted.

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.

Wow! `satisfies` solves a problem I was working on yesterday . Remarkably, it's not the first time a new TS feature immediately makes way into my code.

It's such a powerful complement to the "no rules" JS when you layer it on top. You really get to have your cake and eat it, too. I feel like there's another huge step to take in "layering" invariant checking on top of TS for QA/test systems... Imagine like "in all 500 of my tests, make sure this variable is an integer greater than 10 at all times no matter what". I'm waiting for this to show up

Re: Ten Years of TypeScript

#76

TypeScript is the best thing to happen to web dev, and it keeps getting better. My only gripe is that sometimes in a codebase that is heavy on inferred types I need to restart the TS server occasionally. Nonetheless, unless there is a specific requirement that TS isn't the right choice for, it's the language I reach to for everything.

Do you have interests beyond the JS world? TypeScript being the best thing to happen to web dev sounds a bit hyperbolic.

Re: Ten Years of TypeScript

#77
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.

You're describing issues with the underlying JS ecosystem. TS builds on that, and while it can paper over the language deficiencies, the libraries and frameworks are down to the larger community with its culture of constant churn.

Re: Ten Years of TypeScript

#78

The way TS stuck such an expressive type system in top of such a dynamic and somewhat clumsy language is nothing short of witchcraft. And as a dev it all feels so effortless.

IMO, it feels more like witchcraft lang for clumsy developers

Re: Ten Years of TypeScript

#79

Earlier quoted context omitted.

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?

https://thenewstack.io/which-programming-languages-use-the-l...

This claims that TypeScript is an order of magnitude slower than JavaScript, which is obvious nonsense if you know how TypeScript works, unless they counted transpiling in execution time.

Re: Ten Years of TypeScript

#80
TypeScript has lots of great features and a few bizarrely bad ones. It’s great in spite of itself.

The main misfeature is their dogmatic refusal to rewrite import paths (citing the “Preserve runtime behavior of all JavaScript code” principle mentioned in this article). Here’s a good summary of the problems this causes: https://github.com/microsoft/TypeScript/issues/42151

I’m curious, how many people are using TSC only for type-checking, and a different system (eg esbuild or ts-node) to actually compile/bundle/execute their code?

I think TypeScript would be even stronger if they focused fully on type-checking, and relaxed some of those dogmatic restrictions (and the many, many confusing config options) imposed by the JS code generator.

Post reply on HN