4 ms·

While I think that TS offers probably the best type system out ther, eg way better than Go's, I'd love to see a more balanced view on TS in discussion threads l

While I think that TS offers probably the best type system out ther, eg way better than Go's, I'd love to see a more balanced view on TS in discussion threads like this one. TS is a must for long-term code which should be maintainable in several years by teams. Any lead engineer with responsibility for some crucial app and dev team not using TS is doing something wrong. But using TS comes at a cost. Even when you are savvy in TS you won't bang out code like with pure JS. But especially in prototyping phases you need this fast-paced coding. And using TS or any type system slows you down, even when you are familiar with typed languages. Often your final code faced many iterations and I sometimes like to introduce TS later, usually at a point where I just need types but not always and as default from the first key press. In early stages I still try to test ideas, algorithms and their general feasibility and a fast 'mind-to-code' interface is crucial and types would stay in the way then. Further, finding the right type can take some time, just google what type a React's children prop should be and find long discussions. Welcome to the TS-what-type-is-actually-xy-rabbit-hole. And declaring everything as any shouldn't be the answer. A big drawback are also TS error messages which are super hard to grasp. You get there and you even find tutorials just for understanding TS error messages but it's unecessarily infuriating. Moreover, VSCode, its TS language server are amazing pieces of tech but here you face also strange behaviours. Types get full Intellisense support while interfaces don't which doesn't make sense. So you need still to go the definition yourself and it's not that IDE-like feeling you hoped for or people told you. In my setups, I use TS instead of Babel but use both JS and TS files in one code base depending on the requirements and situation. So, my message is, yes TS is great, has probably the best type system but the tonality by its community/users needs to be much more balanced and less fanboy-ish. I just can't take devs serious who praise TS to death. This is just not true. More, maintainable code is also not just created by a type system but also sane architectures (eg React) and many other factors. Types won't make bad code maintainable. So, types have their place but not everything in TS-land is shiny.

filleduchaos 7y ago
I wouldn't exactly call what TypeScript has the best type system out there. It's deliberately unsound, doesn't enforce full static type-checking, _and_ doesn't provide for runtime checks (there are third-party libraries, but if you're bringing up third parties one might as well argue that JavaScript has a great type system because TypeScript exists). A lot of it is due to the project's overwhelming priority being as easy to interop with JS as possible, but I've found that quite a few of TypeScript's fancier features are sugar that's entirely up to the developer to enforce.
- whsheet 7y ago
  Disagree. TS' type system is fully featured compared to others and what you described as an disadvantage is actually an advantage or TS' killer feature: you can gradually convert a dynamic code base into a static one where needed. IDK of any other language that allows this.
  - filleduchaos 7y ago
    Fully featured compared to what, exactly? If you say Java I might just have to laugh. Obviously the compatibility with JS is TypeScript's "killer feature", but it's a killer feature that has very explicit costs you're ignoring for some reason. You cannot have a truly excellent type system while trying to maintain the level of compatibility with a dynamic, weakly typed language that TypeScript does, something that the language team acknowledges themselves[0]. I don't quite see how one can call a deliberately unsound type system "the best". 0: https://www.typescriptlang.org/docs/handbook/type-compatibility.html https://www.typescriptlang.org/docs/handbook/type-compatibil...
    - whsheet 7y ago
      Not going to discuss this further. You have a dogmatic view on what is an excellent type system.
pas 7y ago
For prototyping using React and TS sounds like a bad idea, because React is not that well supported by the TS community. Whereas if you were to use Angular there the types help you. Or, if you do something in Android with Kotlin, the types are very helpful. Quick auto complete and instant sanity checking of the code. No oops cannot call method on undefined. I found that was what took a lot of time for me when I used plain JS. Furthermore using mixed codebases make things really slow, because then either you need to disable strict mode, or you need to provide typings for at the interface of the TS JS files. Again, this is probably very much path dependent. If you use a lot of strongly typed things for years, then you'll be fast in that. Just two days ago a colleague helped me with some Scala, and we ended up with a few lines of EitherT monad transformers that helped type some code involving Future and HttpResult types. I felt the exact same "figuring out the types takes too long" on my own, so I initially went with less functional Scala. So the same/similar problems (like typing React and Redux) exists in other languages as well, and for some folks it's nothing, because they are very accustomed to that kind of thinking.
- whsheet 7y ago
  > For prototyping using React and TS sounds like a bad idea, because React is not that well supported by the TS community. Not really true and guess you misunderstood me and are not on the latest state of things. You can perfectly use the TS compiler as the compiler for your JSX code. Then you can decide case by case when to use TSX or not. and many major libs (mobx, formik) are written in TS and perfectly support TS. I'd disagree with you statement that long usage of a typed language makes you faster. It is about choosing the right tools and static typing ist not always the right answer. But this is exactly what annoys me: the urge to evangilize everyone with static typing.

filleduchaos 7y ago

I wouldn't exactly call what TypeScript has the best type system out there. It's deliberately unsound, doesn't enforce full static type-checking, _and_ doesn't provide for runtime checks (there are third-party libraries, but if you're bringing up third parties one might as well argue that JavaScript has a great type system because TypeScript exists). A lot of it is due to the project's overwhelming priority being as easy to interop with JS as possible, but I've found that quite a few of TypeScript's fancier features are sugar that's entirely up to the developer to enforce.

whsheet 7y ago
Disagree. TS' type system is fully featured compared to others and what you described as an disadvantage is actually an advantage or TS' killer feature: you can gradually convert a dynamic code base into a static one where needed. IDK of any other language that allows this.
- filleduchaos 7y ago
  Fully featured compared to what, exactly? If you say Java I might just have to laugh. Obviously the compatibility with JS is TypeScript's "killer feature", but it's a killer feature that has very explicit costs you're ignoring for some reason. You cannot have a truly excellent type system while trying to maintain the level of compatibility with a dynamic, weakly typed language that TypeScript does, something that the language team acknowledges themselves[0]. I don't quite see how one can call a deliberately unsound type system "the best". 0: https://www.typescriptlang.org/docs/handbook/type-compatibility.html https://www.typescriptlang.org/docs/handbook/type-compatibil...
  - whsheet 7y ago
    Not going to discuss this further. You have a dogmatic view on what is an excellent type system.

pas 7y ago

For prototyping using React and TS sounds like a bad idea, because React is not that well supported by the TS community. Whereas if you were to use Angular there the types help you. Or, if you do something in Android with Kotlin, the types are very helpful. Quick auto complete and instant sanity checking of the code. No oops cannot call method on undefined. I found that was what took a lot of time for me when I used plain JS. Furthermore using mixed codebases make things really slow, because then either you need to disable strict mode, or you need to provide typings for at the interface of the TS JS files. Again, this is probably very much path dependent. If you use a lot of strongly typed things for years, then you'll be fast in that. Just two days ago a colleague helped me with some Scala, and we ended up with a few lines of EitherT monad transformers that helped type some code involving Future and HttpResult types. I felt the exact same "figuring out the types takes too long" on my own, so I initially went with less functional Scala. So the same/similar problems (like typing React and Redux) exists in other languages as well, and for some folks it's nothing, because they are very accustomed to that kind of thinking.

whsheet 7y ago
> For prototyping using React and TS sounds like a bad idea, because React is not that well supported by the TS community. Not really true and guess you misunderstood me and are not on the latest state of things. You can perfectly use the TS compiler as the compiler for your JSX code. Then you can decide case by case when to use TSX or not. and many major libs (mobx, formik) are written in TS and perfectly support TS. I'd disagree with you statement that long usage of a typed language makes you faster. It is about choosing the right tools and static typing ist not always the right answer. But this is exactly what annoys me: the urge to evangilize everyone with static typing.