5 ms·

Yeah guess this is where Typescript comes in

_nub3 5y ago
TypeScript wont magically fix type errors. It is not that hard, to sanitize any expected parameter for functions and their output, typescript wont do that for you. So if you typecheck i/o values per se, using typescript only slows down dev process, as this can be easily done in vanilla javascript. no need for more bloat, but only for some defensive programming.
- applecrazy 5y ago
  > no need for more bloat What bloat are you referring to? TS compiles down to plain JS.
  - blacktriangle 5y ago
    Toolchain bloat is still bloat.
    - nawgz 5y ago
      To call TypeScript, a very strong type system which compiles down to terse JS with no extra JS for even complex types, and thus accordingly removes the need for all sorts of tests, "toolchain bloat" is a fairly one-dimensional view of things Edit: I accept the downvotes for my tone and have updated it. However, I do feel that by the exact same argument "toolchain bloat" exists, surely one could seamlessly argue "testing bloat" exists, and it should be transparent from the popularity of TypeScript that it's a good tradeoff
- nawgz 5y ago
  TypeScript "magically" fixes the need for defensive programming by ensuring you won't write unsanitary code or invoke functions with possibly null&undefined values by accident. So then clearly the defensive programming is the bloat, because you could avoid it entirely by putting a type system in place to prevent you ever putting yourself in a situation where null&undefined get passed to functions you don't want it to be.
  - sli 5y ago
    This falls apart the moment you're pulling remote data at runtime. You're right back to defensive programming since there's no more type system to help you at that point.
    - nawgz 5y ago
      That's nowhere near "falling apart". That's just the simple fact there's no silver bullet. Someone arguing a little defensive programming is equivalently strong to a type system is clearly unaware just how much work a good type system does for you. I of course agree with you: when you're fetching data that you don't know the type of, recklessly casting it to some type is going to cause issues. This is true in every language that has ever existed. It's also why tools like IO-TS[0] exist, and of course you can enforce this with JSON Schema techniques or custom validators or a million other options. Edit: in case the ultimate point of this comment is not clear, by using a type system and some type validator on your fetches, you are able to reduce the need for defensive programming exclusively to your fetch points. Clearly, defensive programming at the fetch points was already needed, so this is why I do not agree with the claim TypeScript's value add disappears from remote fetches. [0]: https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts
    - ranguna 5y ago
      So you are saying that because we need to do validation in a very specific case, we should just throw the towel and do validations every time? The IO entry point of your code will always be unknown no matter what programming language you are using. In typescript, you do validations in these cases to make sure outside data fits into your type system, from then on (probably about 99% of the rest of the code) won't need any validation whatsoever because the compiler is already doing it for you. Bloat is the amount of time you lose doing code review to check if things are possibly null or doing null checks on stuff that is never null or a bunch of other stuff that the compiler will do for you just by writing some minimal types. The compiler does this stuff automatically without getting tired, can't say the same thing for humans.
      - 5y ago

TypeScript wont magically fix type errors. It is not that hard, to sanitize any expected parameter for functions and their output, typescript wont do that for you. So if you typecheck i/o values per se, using typescript only slows down dev process, as this can be easily done in vanilla javascript. no need for more bloat, but only for some defensive programming.

applecrazy 5y ago
> no need for more bloat What bloat are you referring to? TS compiles down to plain JS.
- blacktriangle 5y ago
  Toolchain bloat is still bloat.
  - nawgz 5y ago
    To call TypeScript, a very strong type system which compiles down to terse JS with no extra JS for even complex types, and thus accordingly removes the need for all sorts of tests, "toolchain bloat" is a fairly one-dimensional view of things Edit: I accept the downvotes for my tone and have updated it. However, I do feel that by the exact same argument "toolchain bloat" exists, surely one could seamlessly argue "testing bloat" exists, and it should be transparent from the popularity of TypeScript that it's a good tradeoff
nawgz 5y ago
TypeScript "magically" fixes the need for defensive programming by ensuring you won't write unsanitary code or invoke functions with possibly null&undefined values by accident. So then clearly the defensive programming is the bloat, because you could avoid it entirely by putting a type system in place to prevent you ever putting yourself in a situation where null&undefined get passed to functions you don't want it to be.
- sli 5y ago
  This falls apart the moment you're pulling remote data at runtime. You're right back to defensive programming since there's no more type system to help you at that point.
  - nawgz 5y ago
    That's nowhere near "falling apart". That's just the simple fact there's no silver bullet. Someone arguing a little defensive programming is equivalently strong to a type system is clearly unaware just how much work a good type system does for you. I of course agree with you: when you're fetching data that you don't know the type of, recklessly casting it to some type is going to cause issues. This is true in every language that has ever existed. It's also why tools like IO-TS[0] exist, and of course you can enforce this with JSON Schema techniques or custom validators or a million other options. Edit: in case the ultimate point of this comment is not clear, by using a type system and some type validator on your fetches, you are able to reduce the need for defensive programming exclusively to your fetch points. Clearly, defensive programming at the fetch points was already needed, so this is why I do not agree with the claim TypeScript's value add disappears from remote fetches. [0]: https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts
  - ranguna 5y ago
    So you are saying that because we need to do validation in a very specific case, we should just throw the towel and do validations every time? The IO entry point of your code will always be unknown no matter what programming language you are using. In typescript, you do validations in these cases to make sure outside data fits into your type system, from then on (probably about 99% of the rest of the code) won't need any validation whatsoever because the compiler is already doing it for you. Bloat is the amount of time you lose doing code review to check if things are possibly null or doing null checks on stuff that is never null or a bunch of other stuff that the compiler will do for you just by writing some minimal types. The compiler does this stuff automatically without getting tired, can't say the same thing for humans.
    - 5y ago