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?
Ten Years of TypeScript
71–80 of 147 posts
Re: Ten Years of TypeScript
#72Re: Ten Years of TypeScript
#73Earlier 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.
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
#74As 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
#75Earlier 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.
Re: Ten Years of TypeScript
#76TypeScript 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.
Re: Ten Years of TypeScript
#77I'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.
Re: Ten Years of TypeScript
#78The 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.
Re: Ten Years of TypeScript
#79Earlier 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...
Re: Ten Years of TypeScript
#80The 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.