4 ms·

with either TypeScript or Flow, you can't go very far before hitting type definition hell. It just shifts where the hell is. Flow has better types out of the bo

by shados 9y ago

with either TypeScript or Flow, you can't go very far before hitting type definition hell. It just shifts where the hell is. Flow has better types out of the box for the Facebook ecosystem, and the flow-typed types, if they're available, are generally higher quality (unless it's for a lib that was made with TS in mind, like RxJS). TypeScript has massively more typedefs of highly varying quality, and there's more stuff written in TypeScript itself. However, so many of them are broken or are incompatible with strict mode (next person who says TS matches Flow because it has strict null can take the door, thx). Fortunately, TS makes it much easier to override broken type definitions. It's a real toss-up which one is better, but both are filled with tears and pain. That pain can (and is often) worth it, but it's absolutely not the slamdunk people around here make it out to be. Unless you REALLY like abusing the any type, in which case what was the point again?

rtpg 9y ago
I don't mean this dismissively but Typescript's type system is insanely flexible, and _should_ let you do basically anything you want. Especially when you look at union types, sum types, type guards, the `never` type.... As a bonus, if you are willing to generate type definitions from other sources (like your backend code) you can go super far. I do agree that the current `@types` solution without versioning isn't very great. Though I've found that for libraries without good definitions, hacking out a simple interface for the layer you use is good. Just doing interface SomeLib {}; declare var lib:SomeLib; and then filling in the errors can be pretty quick in most projects. It makes sense to use libraries, but writing up an interface definition for a library you use is usually quick enough. I'd love to hear about cases where type definitions really messed you up.
- teniutza 9y ago
  I've had the same experience as you did. When there's no type definition available, starting from an empty object quickly resolves a lot of the issues. But that really depends on the complexity of library you're trying to declare. On the other side, I've also had cases when the type definitions were a pain. We have a web app and use .Net/TypeScript/React. We also use the commercial Kendo UI version. Since there's no versioning available (and the Kendo UI team doesn't seam keen on "type correctness"), we are (almost) always using a type definition file for another (newer) version of Kendo UI. We've had to "patch" the definitions on several occasions.
- shados 9y ago
  Properly type lodash or ramda's curry in TS. All the versions I find basically make 5+ overload and a sloppy fallback. Flow can actually type it correctly but so few people know, even the flow typed version doesn't do it (last I checked). There is also plenty of awkward places. Take the Apollo React HOC which can be used for query or mutations. It only achieve this by giving you an object that can be one or the other but you have to know which one you're getting. Another common example is the redux case. You have the store which is of a type. The HoC gives you a function that takes an argument of that type. Nothing links the two though because it wasn't designed with types in mind, so you have to specify the type yourself (essentially a pinky swear). If it was designed with types in mind, the HOC/connect function would be created from the store, thus providing proper type safety. Examples like this are pervasive. You can "type" most things, but in many cases you have to rely on sloppy methods that look type safe but really aren't. If you write stuff with TS in mind from scratch, and use strict mode, it's another story. The type system is quite good.
mvindahl 9y ago
I really like Typescript. It's really well designed and gets typing right IMHO: Strong enough to help you where it matters, flexible enough to get out of the way where it doesn't. Also, type definition hell is definitely a thing. Trying to match types to code often makes me feel like trying to match subtitles to a movie. Off to podnapisi, pick what looks like the best subtitles, fire up VLC, oh shoot, subtitles are ten seconds off, timeshift subtitles to match, watch movie until we reach the first director's cut scene, now subtitles are off again and wife in open rebellion. Which is probably the main reason that we subscribe to Netflix these days instead of trying to bootleg our way through. I'm digressing. Anyway, it seems to me that after they started adding typescript typings to npm, everything has become more sane. At least for the more popular libraries, I rarely run into typing hell anymore. Less popular libraries, yeah, sometimes there is no typing, or sometimes the typing may still be off, but then I just give up and use "any". And these cases seem increasingly rare.

by shados 9y ago

rtpg 9y ago

I don't mean this dismissively but Typescript's type system is insanely flexible, and _should_ let you do basically anything you want. Especially when you look at union types, sum types, type guards, the `never` type.... As a bonus, if you are willing to generate type definitions from other sources (like your backend code) you can go super far. I do agree that the current `@types` solution without versioning isn't very great. Though I've found that for libraries without good definitions, hacking out a simple interface for the layer you use is good. Just doing interface SomeLib {}; declare var lib:SomeLib; and then filling in the errors can be pretty quick in most projects. It makes sense to use libraries, but writing up an interface definition for a library you use is usually quick enough. I'd love to hear about cases where type definitions really messed you up.

teniutza 9y ago
I've had the same experience as you did. When there's no type definition available, starting from an empty object quickly resolves a lot of the issues. But that really depends on the complexity of library you're trying to declare. On the other side, I've also had cases when the type definitions were a pain. We have a web app and use .Net/TypeScript/React. We also use the commercial Kendo UI version. Since there's no versioning available (and the Kendo UI team doesn't seam keen on "type correctness"), we are (almost) always using a type definition file for another (newer) version of Kendo UI. We've had to "patch" the definitions on several occasions.
shados 9y ago
Properly type lodash or ramda's curry in TS. All the versions I find basically make 5+ overload and a sloppy fallback. Flow can actually type it correctly but so few people know, even the flow typed version doesn't do it (last I checked). There is also plenty of awkward places. Take the Apollo React HOC which can be used for query or mutations. It only achieve this by giving you an object that can be one or the other but you have to know which one you're getting. Another common example is the redux case. You have the store which is of a type. The HoC gives you a function that takes an argument of that type. Nothing links the two though because it wasn't designed with types in mind, so you have to specify the type yourself (essentially a pinky swear). If it was designed with types in mind, the HOC/connect function would be created from the store, thus providing proper type safety. Examples like this are pervasive. You can "type" most things, but in many cases you have to rely on sloppy methods that look type safe but really aren't. If you write stuff with TS in mind from scratch, and use strict mode, it's another story. The type system is quite good.

mvindahl 9y ago

I really like Typescript. It's really well designed and gets typing right IMHO: Strong enough to help you where it matters, flexible enough to get out of the way where it doesn't. Also, type definition hell is definitely a thing. Trying to match types to code often makes me feel like trying to match subtitles to a movie. Off to podnapisi, pick what looks like the best subtitles, fire up VLC, oh shoot, subtitles are ten seconds off, timeshift subtitles to match, watch movie until we reach the first director's cut scene, now subtitles are off again and wife in open rebellion. Which is probably the main reason that we subscribe to Netflix these days instead of trying to bootleg our way through. I'm digressing. Anyway, it seems to me that after they started adding typescript typings to npm, everything has become more sane. At least for the more popular libraries, I rarely run into typing hell anymore. Less popular libraries, yeah, sometimes there is no typing, or sometimes the typing may still be off, but then I just give up and use "any". And these cases seem increasingly rare.