3 ms·

You claim its not a real thing, and yet I have many practical experiences of it being a very real thing over the last 15 years of my career. Everything from sim

You claim its not a real thing, and yet I have many practical experiences of it being a very real thing over the last 15 years of my career. Everything from simple tooling headaches in dev, to actual shipped production bugs resultant from the dev toolchain. Pretending like there isn't a real tradeoff here doesn't really help move the needle in my original commentary, that persuasive arguments in the OP article are missing. I also think its interesting that immediately subsequent to your comment about dep bloat not being a real thing, you link to yet another dependency to solve a problem with using TS in node dev. As an aside for what its worth (since you mentioned frontend), all of my commentary assumes node.js dev and not the frontend. The former is what I work in day to day. >Why write assertions when TS can figure them out for you? I could easily just reframe this to say: "why write type annotations when you can write assertions?" — its orthogonal to all my earlier points about the OP's arguments

striking 6y ago
I think if you're of the opinion that installing any toolchain (as opposed to writing files right to disk and having Node read them as-is) is "bloat" then obviously it will be hard for me to convince you it's not. I can say, however, that though your experiences may have been valid even as recently as a few years ago, there are very few bugs in these tools these days. Moreover, TS is not a place where these bugs appear; shipping prod code from TS source is literally just stripping the types as you check them, and whether you webpack/babel/etc. afterwards is up to you. In short, "bloat" could possibly be considered a real thing in other situations, but in the context of TypeScript it certainly isn't. Perhaps your previous experiences with these sorts of tools has affected your view of this one. I respect that. I just don't think it's relevant here. > "why write type annotations when you can write assertions?" Because you don't have to write type annotations most of the time (hence the "figures them out for you" that you omitted). TS infers them, even from things like database or API calls. We're not in Java land, where every type needs to be specified. TS understands what you mean, and will warn you (or configurably, throw an error) if it doesn't. It's a false equivalence.
- spmurrayzzz 6y ago
  These are all great points, thanks for digging in here. It does sound like you give the TS community a lot of credit with respect to toolchain stability and thats nice to hear for someone like me who isn't directly involved in that community apart from browsing the issue tracker every month or so. I'll concede that I do work backwards from the "you don't know what you don't know" bias, and given my previous experience with other type systems, I tend to privilege the status quo (e.g. our software works well, five 9's of uptime, virtually no runtime errors reported via APM, developer productivity is high, business objectives are being met, etc). I need to work on that bias, because it can become an infinitely recursive argument.
  - striking 6y ago
    Definitely, and there's nothing wrong with maintaining the status quo if it's working really well as-is. But I think it can be pretty surprising to folks that haven't had an opportunity to play with TS, just how powerful the tooling is. Perhaps one way to break through that bias is to start up a side project and play with it a little.
    - spmurrayzzz 6y ago
      I actually have done a few projects with TS, but none of them were really put to the full professional SDLC test. e.g. managing upstream dependency changes, lots of developers contributing, business constraints, etc. Personally I am very bullish on Deno, which goes beyond just native type system, but we'll see how that project ultimately plays out.

striking 6y ago

I think if you're of the opinion that installing any toolchain (as opposed to writing files right to disk and having Node read them as-is) is "bloat" then obviously it will be hard for me to convince you it's not. I can say, however, that though your experiences may have been valid even as recently as a few years ago, there are very few bugs in these tools these days. Moreover, TS is not a place where these bugs appear; shipping prod code from TS source is literally just stripping the types as you check them, and whether you webpack/babel/etc. afterwards is up to you. In short, "bloat" could possibly be considered a real thing in other situations, but in the context of TypeScript it certainly isn't. Perhaps your previous experiences with these sorts of tools has affected your view of this one. I respect that. I just don't think it's relevant here. > "why write type annotations when you can write assertions?" Because you don't have to write type annotations most of the time (hence the "figures them out for you" that you omitted). TS infers them, even from things like database or API calls. We're not in Java land, where every type needs to be specified. TS understands what you mean, and will warn you (or configurably, throw an error) if it doesn't. It's a false equivalence.

spmurrayzzz 6y ago
These are all great points, thanks for digging in here. It does sound like you give the TS community a lot of credit with respect to toolchain stability and thats nice to hear for someone like me who isn't directly involved in that community apart from browsing the issue tracker every month or so. I'll concede that I do work backwards from the "you don't know what you don't know" bias, and given my previous experience with other type systems, I tend to privilege the status quo (e.g. our software works well, five 9's of uptime, virtually no runtime errors reported via APM, developer productivity is high, business objectives are being met, etc). I need to work on that bias, because it can become an infinitely recursive argument.
- striking 6y ago
  Definitely, and there's nothing wrong with maintaining the status quo if it's working really well as-is. But I think it can be pretty surprising to folks that haven't had an opportunity to play with TS, just how powerful the tooling is. Perhaps one way to break through that bias is to start up a side project and play with it a little.
  - spmurrayzzz 6y ago
    I actually have done a few projects with TS, but none of them were really put to the full professional SDLC test. e.g. managing upstream dependency changes, lots of developers contributing, business constraints, etc. Personally I am very bullish on Deno, which goes beyond just native type system, but we'll see how that project ultimately plays out.