11 ms·

I love typescript but its types are becoming so complicated it's turning into a dynamic language... I mean one can't represent the all possibilities of JavaScr

I love typescript but its types are becoming so complicated it's turning into a dynamic language... I mean one can't represent the all possibilities of JavaScript "types" without re-implementing JavaScript itself, only a subset. I wonder where Typescript will stop. I'd like to see Typescript compiling to "native" as well.

wmrowan 6y ago
The vast majority of people using TypeScript in their projects won't run into the deeper complexity of the type system. For the average TS user the only visible impact of features like template literal types and recursive conditional types will be fewer bugs because maintainers of popular libraries used them to provide better types. You don't have to personally understand TS's more complicated features to benefit from using TS in your project. I hope they continue adding richness to the type system so I can eliminate more bugs from my code.
- commentrix 6y ago
  Excellent pro TS propaganda, and apologism for exploding complexity. I love the idea of type checking, but the implementation of it seems buggy. tsc checkJS will make incorrect type inferences and throw errors about situations that won't happen, and it does this inconsistently, seemingly dependent on the syntax, for instance that a new promise's resolve function is possibly undefined.
- lenkite 6y ago
  Typescript is approaching C++ complexity since this is pretty much the same answer that people give when someone complains that C++ is very complex.
  - root_axis 6y ago
    That seems like a pretty superficial connection.
  - mb7733 6y ago
    How could typescript be approaching C++ complexity when it's just JS with types? The advanced typing features don't affect the semantics of programs. They just make the type system more expressive so more things can be validated by the compiler. In other words, typescript doesn't make the language any bigger. If you're struggling to understand typescript code you could just ignore the types, and you're back with regular JS. This is different than the issue some people have with a big language like C++, where the sheer number of features can make it hard to get a grip on unfamiliar codebases.
    - winstonewert 6y ago
      Well, for one thing, I want my code to pass typescripts type checker. So I can't just ignore the types and go back to regular javascript. I've got to understand the sometimes complicated static typing semantics
      - mb7733 6y ago
        The TS devs adding support for more advanced types in tsc doesn't make it any harder for your code to pass type checking. That just depends on (1) how strictly you have configured the type checker and (2) how specific you make your type definitions. The more advanced types just allow more specific type definitions. So if try to you them, and you can't get them to work... you can just avoid the advanced features and leave the type definitions more vague. Just like how if you can't get the basic types to work, you can always use "any".
        winstonewert 6y ago
        And now you are changing your claim, showing, quite frankly, that I was right. Your original claim was bogus. Furthermore, your new claim is also nonsensical. The fact that I don't have to use all the advanced features of my languages doesn't alter the complexity of the language.
        mb7733 6y ago
        I'm not sure what you mean by my claims. I'm just saying there is a big difference between adding features to the language and adding features to the type system.
  - lmm 6y ago
    That's like saying any country that talks about how democratic it is must be like the Soviet Union. Sometimes you have to actually look at the details behind the claims. There are specific problems with C++, and its features are often not orthogonal enough to use independently. That doesn't mean that it's impossible to add orthogonal features that don't complicate a language for people who don't use them, it only means that C++ has failed to.
- holoduke 6y ago
  Always when typescript is is compared with js, people talk about you get less bugs in typescript. I am honestly curious to see some evidence. In my opinion application bugs are usually in the flow itself and have nothing to do with wrong types. I work a lot with both plain and Typescript projects. I used to like Typescript. But not anymore. With typescript applications tend to become bigger and more complex. Most devs using it have never seen vanilla js and are more java minded that prototype minded. IDE code completion works better for typescript. For sure. But is that really essential? Sounds a bit like the typical Java developer who works with giant spring applications containing classes with hundreds of methods spread in many files in a 10 layer deep folder structure.
  - timdaub 6y ago
    As someone that's extensively testing their application, I don't get the bug argument either. Sure some bugs are found during compile time. Actually, it's not bugs the compiler finds. Rather it's inconsitencies between types and the rest of the code. But when testing properly, these should anyways be found later. Or am I missing something?
    - egeozcan 6y ago
      It's a given that you can reduce the number of bugs in your app eventually, with any method/tool you can imagine, given enough time. That'd be still true if you were designing using sticks and stones on sand. Why not use another tool that helps you fix bugs easier, faster and sometimes spare you from writing them at all?
      - timdaub 6y ago
        Why so aggressive? I asked a simple question out of interest. Again, I think there's a difference between bug and a coding error. A bug is a mismatch between a software's function and the user's expectation. And a typed-inferred error during compile time is just a hint that some code is incorrect. It may lead to a bug, but at the point of compilation, it's not a bug.
- motogpjimbo 6y ago
  I've seen the same claim made about the more obscure features found in application frameworks, and in both cases the problem is the same: there will always be that one guy on your team who takes delight in finding a complicated and mentally burdensome solution to an otherwise simple problem, which requires everyone on the team to at least be aware that certain constructs exist. It's great that Typescript is catching on, and we're starting to adopt it in my team, but I hope the TS people don't think they can keep adding new features to it in perpetuity, otherwise it's going to turn into C++.
Analemma_ 6y ago
It's an unfortunate situation, because so long as people are writing popular frameworks/libraries that horribly abuse the dynamic nature of JavaScript, the TypeScript team sort of has no choice but to try and wrestle the language into supporting it. But I agree that this is getting out of hand. I still like TypeScript but with each new release it's getting harder to claim with a straight face that it's "easier" than vanilla JS when you have to grok this increasingly convoluted type system.
- munificent 6y ago
  > horribly abuse the dynamic nature of JavaScript It's not a horrible abuse if you aren't trying to make the framework/library statically typed in the first place. Idiomatic APIs for dynamically typed languages use the flexibility of dynamic types. Idiomatic APIs for statically typed languages use the structure of static types. The problem comes when you try to put one into the other's world. It's like watching a fish flop around on land. There's nothing intrinsically wrong with fish locomotion, it's just not optimized for that environment.
  - ImprobableTruth 6y ago
    >It's not a horrible abuse if you aren't trying to make the framework/library statically typed in the first place. Of course it is, because even if there's no type system the people using the library still have to make sense of the complexity. A function with a dozen, context-sensitive overloads that accepts data without a clear pattern isn't just hard to type, it's also hard to understand for a user. Even with dynamic typing you should be able to clearly state what a function does.
- bobbylarrybobby 6y ago
  Presumably, to work with the original JavaScript, you still had to understand the convoluted type system that you created, or else be ok with not being able to reason about your code. At least with typescript you have the computer helping you reason about it.
  - 6y ago
mslm 6y ago
This is actually why I stopped using it. Forcing types on a dynamic language like this seems to inevitably lead to really, really complex type definitions which just confuse things tremendously. It almost seems easier and better to just straight up use JSDoc with some good standard documentation to back it.
- ht85 6y ago
  Could you give an example? In years of using TS I have had to craft a few exotic generics, but have otherwise never ran into "really complex" types.
  - mslm 6y ago
    My point is obviously subjective, so you may not agree, and we may have different tastes for what simplicity/complexity looks like. https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/lodash https://github.com/DefinitelyTyped/DefinitelyTyped/tree/mast... felt like to me as one popular example for what should be really simple in practice.
    - ht85 6y ago
      > what should be really simple in practice I thought you were talking about types in your own code. Lodash being a large, heavily overloaded and generic library it seems fair that the definitions are complex. When it comes to external code like that, I don't think you can argue against the value of intellisense and safety (especially when upgrading versions). Those are in my opinion the biggest benefits of having strong types.
      - didibus 6y ago
        It could depend on the alternative proposed. Adding types to dynamic languages might actually exhibit this behavior, of inevitably leading to really, really complex type definitions which just confuse things tremendously. In your case, your alternative is back to untyped, unsafe JavaScript. Maybe that's not so much better. Another alternative would be to move to a language designed with types in mind from the get go, say OCaml (with ReScript) or Java (with JSweet), or others. Bottom line, I think that claim is still true: "Forcing types on a dynamic language like this seems to inevitably lead to really, really complex type definitions which just confuse things tremendously" But if that is a good or bad trade off for you to make, I think that's very contextual, it depends. Maybe that's okay for someone, and they'll use TypeScript. Maybe that's not okay, and they'll go back to JavaScript. Maybe they'll instead explore a ground up typed lang like Java.
munificent 6y ago
Stage 0: JavaScript without types is too hard to maintain. Stage 1: Put types into JavaScript. Stage 2: TypeScript types are not expressive enough. Stage 3: Put JavaScript into types. I'm looking forward to stage 4 where the expressions inside TypeScript type annotations get so complex and hard to maintain that someone creates TypeTypeScript that lets you put type annotations inside the code inside type annotations.
- trevyn 6y ago
  So, generics?
- jaequery 6y ago
  And 10 years later, someone will eventually bring back dynamic typing and every one will go monkeys
  - recursive 6y ago
    It's still there. `any`.
    - baq 6y ago
      but you don't have to type it now! it's literally a revolution in developer efficiency! ...and all the older folks just keep pointing at lisp and shaking their heads.
      - cryptica 6y ago
        That is ingenious! That would get me excited about TypeScript! Dynamic typing, no cumbersome transpilation step, no source mapping, 100% backward compatibility with JavaScript. That would be a dream come true. We need a way to go back to JS without hurting the egos of TS community. It will require a massive marketing innovation to achieve this.
        recursive 6y ago
trevyn 6y ago
What? It only turns back into a dynamic language if you give up and start using “any”. The more detailed your type system, the more distinctions you can represent in it, and the more unintended behavior you can catch early. It can become more challenging to work with, but you’ll get end results that are more robust, which is one of the goals of strong typing.
Xavdidtheshadow 6y ago
I watched a great talk at TSConf about playing Tic-Tac-Toe using the type system. Not TS itself, purely using the type system. https://blog.joshuakgoldberg.com/type-system-game-engines/ https://blog.joshuakgoldberg.com/type-system-game-engines/
- pookeh 6y ago
  Lots of other great examples here: https://github.com/ronami/meta-typing https://github.com/ronami/meta-typing
- Kinrany 6y ago
  Type-level SQL interpreter: https://github.com/codemix/ts-sql https://github.com/codemix/ts-sql
xiphias2 6y ago
With C++ the usual solution is to use only a defined subset of it and make sure that lint checker is used in presubmit checks. Exceptions to other types should be allowed, but strongly discouraged when working in a team (which TypeScript is used for)
root_axis 6y ago
I don't understand this type of cynical criticism. You don't have to use features you believe are "so complicated". Just don't use them. You said you love typescript, and everything you love about typescript remains intact to your satisfaction. It's not as if these features emerge spontaneously from a vacuum, the typescript team is working with the community to address specific needs. You didn't even offer any specific criticisms, just a vague dismissal. Just don't use it.
- throw_m239339 6y ago
  > I don't understand this type of cynical criticism. I don't think my comment sounds cynical. > You don't have to use features you believe are "so complicated". One has to be fluent with reading type definitions thus have good understanding of the type syntax. I must admit, from time to time I could not make sense of them easily when reading declaration files from third parties.
  - root_axis 6y ago
    You don't typically need to examine 3rd party types, consuming them requires little cognitive effort because the IDE/typechecker will generally tell you everything you need to know at the consumption site. If you ever do have to dig into a really complex type, that might be painful, but keep in mind that the reason we have more sophisticated types is so that we can maximize correctness and reduce the chance of bugs, the fact that you're getting a type error at all means whatever you wanted to do is definitionally unsafe, so it's good that typescript is empowered to tell you not to do this, even if you don't immediately understand why.
    - throw_m239339 6y ago
      > You don't typically need to examine 3rd party types, consuming them requires little cognitive effort because the IDE/typechecker will generally tell you everything you need to know at the consumption site. Yes you do, you need to be able to read complex type signatures in order to know what a function or a method accepts, and for that you need to understand Typescript's type syntax, it what it is all about at first place. In case you have a compiler error you need to understand how the type system works to make sense of an error. You can't deny that simple fact, that's the whole point of typescript.
bichiliad 6y ago
I think a lot of the complexities of the type system come from the fact that types have to describe complex behavior in a static way, while still being useful (you could type everything in your code as `any`[0], but that wouldn't be very useful). JavaScript is complex, so statically describing its behaviors is also complex. At the same time, most of the complex types are types you never have to see or use, unless you're the maintainer of a complex library and you want to provide really useful types. [0]:https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/jquery/v1/index.d.ts#L380 https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...
benawad 6y ago
I'll take 70% type safety over 0% any day
orta 6y ago
There are research teams at Microsoft exploring a native form of TypeScript ( https://www.microsoft.com/en-us/research/publication/static-typescript/ https://www.microsoft.com/en-us/research/publication/static-... ) but the TypeScript team will never probably look at native support given the goal is to explicitly be JavaScript + Types, and that domain helps balance well with all the other ecosystem players ( https://www.youtube.com/watch?v=8qm49TyMUPI https://www.youtube.com/watch?v=8qm49TyMUPI )
- lioeters 6y ago
  Fascinating - thanks for mentioning this work at Microsoft Research. > [A Static TypeScript] program is compiled to machine code in the browser and linked against a precompiled C++ runtime, producing an executable that is more efficient than the prevalent embedded interpreter approach, extending battery life and making it possible to run on devices with as little as 16 kB of RAM (such as the BBC micro:bit).
eyelidlessness 6y ago
> I love typescript but its types are becoming so complicated it's turning into a dynamic language... Except all of it can be tested and validated at compile time so... not dynamic?
jhanschoo 6y ago
The expressiveness of the type system far outweighs its complexity, imo. To give a commonly-encountered example, rather than the easily-introspectable options object whose schema is specified by a zero-runtime-cost TS interface, in a traditional OOP language like Java you would write an XOptions / XOptionsBuilder class to maintain type safety, which is at once more opaque, with less predictable behavior.
scotty79 6y ago
I love how TypeScript makes the rich semantics of JavaScript visible. When some programmers favored dynamic languages over the statically typed others looked at them like at mad. The thing is that dynamic languages fans just wanted to have semantics as rich as this one and were willing to sacrifice even type checking altogether for it because no statically typed language was willing to deliver this semantic in any reasonable manner.
7331 6y ago
> I'd like to see Typescript compiling to "native" as well. Yeah I'd love something that just compiles .ts to a binary. But I can already hear the cries of "embrace, extend extinguish" if that happened.

wmrowan 6y ago

The vast majority of people using TypeScript in their projects won't run into the deeper complexity of the type system. For the average TS user the only visible impact of features like template literal types and recursive conditional types will be fewer bugs because maintainers of popular libraries used them to provide better types. You don't have to personally understand TS's more complicated features to benefit from using TS in your project. I hope they continue adding richness to the type system so I can eliminate more bugs from my code.

commentrix 6y ago
Excellent pro TS propaganda, and apologism for exploding complexity. I love the idea of type checking, but the implementation of it seems buggy. tsc checkJS will make incorrect type inferences and throw errors about situations that won't happen, and it does this inconsistently, seemingly dependent on the syntax, for instance that a new promise's resolve function is possibly undefined.
lenkite 6y ago
Typescript is approaching C++ complexity since this is pretty much the same answer that people give when someone complains that C++ is very complex.
- root_axis 6y ago
  That seems like a pretty superficial connection.
- mb7733 6y ago
  How could typescript be approaching C++ complexity when it's just JS with types? The advanced typing features don't affect the semantics of programs. They just make the type system more expressive so more things can be validated by the compiler. In other words, typescript doesn't make the language any bigger. If you're struggling to understand typescript code you could just ignore the types, and you're back with regular JS. This is different than the issue some people have with a big language like C++, where the sheer number of features can make it hard to get a grip on unfamiliar codebases.
  - winstonewert 6y ago
    Well, for one thing, I want my code to pass typescripts type checker. So I can't just ignore the types and go back to regular javascript. I've got to understand the sometimes complicated static typing semantics
    - mb7733 6y ago
      The TS devs adding support for more advanced types in tsc doesn't make it any harder for your code to pass type checking. That just depends on (1) how strictly you have configured the type checker and (2) how specific you make your type definitions. The more advanced types just allow more specific type definitions. So if try to you them, and you can't get them to work... you can just avoid the advanced features and leave the type definitions more vague. Just like how if you can't get the basic types to work, you can always use "any".
      - winstonewert 6y ago
        And now you are changing your claim, showing, quite frankly, that I was right. Your original claim was bogus. Furthermore, your new claim is also nonsensical. The fact that I don't have to use all the advanced features of my languages doesn't alter the complexity of the language.
        mb7733 6y ago
        I'm not sure what you mean by my claims. I'm just saying there is a big difference between adding features to the language and adding features to the type system.
- lmm 6y ago
  That's like saying any country that talks about how democratic it is must be like the Soviet Union. Sometimes you have to actually look at the details behind the claims. There are specific problems with C++, and its features are often not orthogonal enough to use independently. That doesn't mean that it's impossible to add orthogonal features that don't complicate a language for people who don't use them, it only means that C++ has failed to.
holoduke 6y ago
Always when typescript is is compared with js, people talk about you get less bugs in typescript. I am honestly curious to see some evidence. In my opinion application bugs are usually in the flow itself and have nothing to do with wrong types. I work a lot with both plain and Typescript projects. I used to like Typescript. But not anymore. With typescript applications tend to become bigger and more complex. Most devs using it have never seen vanilla js and are more java minded that prototype minded. IDE code completion works better for typescript. For sure. But is that really essential? Sounds a bit like the typical Java developer who works with giant spring applications containing classes with hundreds of methods spread in many files in a 10 layer deep folder structure.
- timdaub 6y ago
  As someone that's extensively testing their application, I don't get the bug argument either. Sure some bugs are found during compile time. Actually, it's not bugs the compiler finds. Rather it's inconsitencies between types and the rest of the code. But when testing properly, these should anyways be found later. Or am I missing something?
  - egeozcan 6y ago
    It's a given that you can reduce the number of bugs in your app eventually, with any method/tool you can imagine, given enough time. That'd be still true if you were designing using sticks and stones on sand. Why not use another tool that helps you fix bugs easier, faster and sometimes spare you from writing them at all?
    - timdaub 6y ago
      Why so aggressive? I asked a simple question out of interest. Again, I think there's a difference between bug and a coding error. A bug is a mismatch between a software's function and the user's expectation. And a typed-inferred error during compile time is just a hint that some code is incorrect. It may lead to a bug, but at the point of compilation, it's not a bug.
motogpjimbo 6y ago
I've seen the same claim made about the more obscure features found in application frameworks, and in both cases the problem is the same: there will always be that one guy on your team who takes delight in finding a complicated and mentally burdensome solution to an otherwise simple problem, which requires everyone on the team to at least be aware that certain constructs exist. It's great that Typescript is catching on, and we're starting to adopt it in my team, but I hope the TS people don't think they can keep adding new features to it in perpetuity, otherwise it's going to turn into C++.

Analemma_ 6y ago

It's an unfortunate situation, because so long as people are writing popular frameworks/libraries that horribly abuse the dynamic nature of JavaScript, the TypeScript team sort of has no choice but to try and wrestle the language into supporting it. But I agree that this is getting out of hand. I still like TypeScript but with each new release it's getting harder to claim with a straight face that it's "easier" than vanilla JS when you have to grok this increasingly convoluted type system.

munificent 6y ago
> horribly abuse the dynamic nature of JavaScript It's not a horrible abuse if you aren't trying to make the framework/library statically typed in the first place. Idiomatic APIs for dynamically typed languages use the flexibility of dynamic types. Idiomatic APIs for statically typed languages use the structure of static types. The problem comes when you try to put one into the other's world. It's like watching a fish flop around on land. There's nothing intrinsically wrong with fish locomotion, it's just not optimized for that environment.
- ImprobableTruth 6y ago
  >It's not a horrible abuse if you aren't trying to make the framework/library statically typed in the first place. Of course it is, because even if there's no type system the people using the library still have to make sense of the complexity. A function with a dozen, context-sensitive overloads that accepts data without a clear pattern isn't just hard to type, it's also hard to understand for a user. Even with dynamic typing you should be able to clearly state what a function does.
bobbylarrybobby 6y ago
Presumably, to work with the original JavaScript, you still had to understand the convoluted type system that you created, or else be ok with not being able to reason about your code. At least with typescript you have the computer helping you reason about it.
- 6y ago

mslm 6y ago

This is actually why I stopped using it. Forcing types on a dynamic language like this seems to inevitably lead to really, really complex type definitions which just confuse things tremendously. It almost seems easier and better to just straight up use JSDoc with some good standard documentation to back it.

ht85 6y ago
Could you give an example? In years of using TS I have had to craft a few exotic generics, but have otherwise never ran into "really complex" types.
- mslm 6y ago
  My point is obviously subjective, so you may not agree, and we may have different tastes for what simplicity/complexity looks like. https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/lodash https://github.com/DefinitelyTyped/DefinitelyTyped/tree/mast... felt like to me as one popular example for what should be really simple in practice.
  - ht85 6y ago
    > what should be really simple in practice I thought you were talking about types in your own code. Lodash being a large, heavily overloaded and generic library it seems fair that the definitions are complex. When it comes to external code like that, I don't think you can argue against the value of intellisense and safety (especially when upgrading versions). Those are in my opinion the biggest benefits of having strong types.
    - didibus 6y ago
      It could depend on the alternative proposed. Adding types to dynamic languages might actually exhibit this behavior, of inevitably leading to really, really complex type definitions which just confuse things tremendously. In your case, your alternative is back to untyped, unsafe JavaScript. Maybe that's not so much better. Another alternative would be to move to a language designed with types in mind from the get go, say OCaml (with ReScript) or Java (with JSweet), or others. Bottom line, I think that claim is still true: "Forcing types on a dynamic language like this seems to inevitably lead to really, really complex type definitions which just confuse things tremendously" But if that is a good or bad trade off for you to make, I think that's very contextual, it depends. Maybe that's okay for someone, and they'll use TypeScript. Maybe that's not okay, and they'll go back to JavaScript. Maybe they'll instead explore a ground up typed lang like Java.

munificent 6y ago

Stage 0: JavaScript without types is too hard to maintain. Stage 1: Put types into JavaScript. Stage 2: TypeScript types are not expressive enough. Stage 3: Put JavaScript into types. I'm looking forward to stage 4 where the expressions inside TypeScript type annotations get so complex and hard to maintain that someone creates TypeTypeScript that lets you put type annotations inside the code inside type annotations.

trevyn 6y ago
So, generics?
jaequery 6y ago
And 10 years later, someone will eventually bring back dynamic typing and every one will go monkeys
- recursive 6y ago
  It's still there. `any`.
  - baq 6y ago
    but you don't have to type it now! it's literally a revolution in developer efficiency! ...and all the older folks just keep pointing at lisp and shaking their heads.
    - cryptica 6y ago
      That is ingenious! That would get me excited about TypeScript! Dynamic typing, no cumbersome transpilation step, no source mapping, 100% backward compatibility with JavaScript. That would be a dream come true. We need a way to go back to JS without hurting the egos of TS community. It will require a massive marketing innovation to achieve this.
      - recursive 6y ago

trevyn 6y ago

What? It only turns back into a dynamic language if you give up and start using “any”. The more detailed your type system, the more distinctions you can represent in it, and the more unintended behavior you can catch early. It can become more challenging to work with, but you’ll get end results that are more robust, which is one of the goals of strong typing.

Xavdidtheshadow 6y ago

I watched a great talk at TSConf about playing Tic-Tac-Toe using the type system. Not TS itself, purely using the type system. https://blog.joshuakgoldberg.com/type-system-game-engines/ https://blog.joshuakgoldberg.com/type-system-game-engines/

pookeh 6y ago
Lots of other great examples here: https://github.com/ronami/meta-typing https://github.com/ronami/meta-typing
Kinrany 6y ago
Type-level SQL interpreter: https://github.com/codemix/ts-sql https://github.com/codemix/ts-sql

xiphias2 6y ago

With C++ the usual solution is to use only a defined subset of it and make sure that lint checker is used in presubmit checks. Exceptions to other types should be allowed, but strongly discouraged when working in a team (which TypeScript is used for)

root_axis 6y ago

I don't understand this type of cynical criticism. You don't have to use features you believe are "so complicated". Just don't use them. You said you love typescript, and everything you love about typescript remains intact to your satisfaction. It's not as if these features emerge spontaneously from a vacuum, the typescript team is working with the community to address specific needs. You didn't even offer any specific criticisms, just a vague dismissal. Just don't use it.

throw_m239339 6y ago
> I don't understand this type of cynical criticism. I don't think my comment sounds cynical. > You don't have to use features you believe are "so complicated". One has to be fluent with reading type definitions thus have good understanding of the type syntax. I must admit, from time to time I could not make sense of them easily when reading declaration files from third parties.
- root_axis 6y ago
  You don't typically need to examine 3rd party types, consuming them requires little cognitive effort because the IDE/typechecker will generally tell you everything you need to know at the consumption site. If you ever do have to dig into a really complex type, that might be painful, but keep in mind that the reason we have more sophisticated types is so that we can maximize correctness and reduce the chance of bugs, the fact that you're getting a type error at all means whatever you wanted to do is definitionally unsafe, so it's good that typescript is empowered to tell you not to do this, even if you don't immediately understand why.
  - throw_m239339 6y ago
    > You don't typically need to examine 3rd party types, consuming them requires little cognitive effort because the IDE/typechecker will generally tell you everything you need to know at the consumption site. Yes you do, you need to be able to read complex type signatures in order to know what a function or a method accepts, and for that you need to understand Typescript's type syntax, it what it is all about at first place. In case you have a compiler error you need to understand how the type system works to make sense of an error. You can't deny that simple fact, that's the whole point of typescript.

bichiliad 6y ago

I think a lot of the complexities of the type system come from the fact that types have to describe complex behavior in a static way, while still being useful (you could type everything in your code as `any`[0], but that wouldn't be very useful). JavaScript is complex, so statically describing its behaviors is also complex. At the same time, most of the complex types are types you never have to see or use, unless you're the maintainer of a complex library and you want to provide really useful types. [0]:https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/jquery/v1/index.d.ts#L380 https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...

benawad 6y ago

I'll take 70% type safety over 0% any day

orta 6y ago

There are research teams at Microsoft exploring a native form of TypeScript ( https://www.microsoft.com/en-us/research/publication/static-typescript/ https://www.microsoft.com/en-us/research/publication/static-... ) but the TypeScript team will never probably look at native support given the goal is to explicitly be JavaScript + Types, and that domain helps balance well with all the other ecosystem players ( https://www.youtube.com/watch?v=8qm49TyMUPI https://www.youtube.com/watch?v=8qm49TyMUPI )

lioeters 6y ago
Fascinating - thanks for mentioning this work at Microsoft Research. > [A Static TypeScript] program is compiled to machine code in the browser and linked against a precompiled C++ runtime, producing an executable that is more efficient than the prevalent embedded interpreter approach, extending battery life and making it possible to run on devices with as little as 16 kB of RAM (such as the BBC micro:bit).

eyelidlessness 6y ago

> I love typescript but its types are becoming so complicated it's turning into a dynamic language... Except all of it can be tested and validated at compile time so... not dynamic?

jhanschoo 6y ago

The expressiveness of the type system far outweighs its complexity, imo. To give a commonly-encountered example, rather than the easily-introspectable options object whose schema is specified by a zero-runtime-cost TS interface, in a traditional OOP language like Java you would write an XOptions / XOptionsBuilder class to maintain type safety, which is at once more opaque, with less predictable behavior.

scotty79 6y ago

I love how TypeScript makes the rich semantics of JavaScript visible. When some programmers favored dynamic languages over the statically typed others looked at them like at mad. The thing is that dynamic languages fans just wanted to have semantics as rich as this one and were willing to sacrifice even type checking altogether for it because no statically typed language was willing to deliver this semantic in any reasonable manner.

7331 6y ago

> I'd like to see Typescript compiling to "native" as well. Yeah I'd love something that just compiles .ts to a binary. But I can already hear the cries of "embrace, extend extinguish" if that happened.