3 ms·
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 obvio
by 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 agoThese 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 agoDefinitely, 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 agoI 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.