The TypeScript Tax (opens in new tab)

I strongly disagree. You can start using typescript without thinking for a second about what parts of it will be beneficial.

Initially you can just run javascript through the typescript compiler and let type inference find some bugs. You can start adding types in places where you want autocomplete to work better. You can ratchet up the strictness if you start to find bugs that stricter type checking would have caught. If you've read any typescript discussions on HN you already know this.

On the flip side, obvious once you think about it, the option is always there to ratchet down strictness if for your codebase the requirements turn out to be too heavy, i.e. slowing feature development down more than the bug reduction warrants. But you don't have to think deeply about it in advance. Just write your code, and every so often take a step back and look at how well things are working. Then adjust based on actual benefits and costs, not some premature estimate of them.

Note I'm not pro or anti myself, I've only just begun playing with it, but would like to hear from all kinds of people.

Yeah, obviously. Think about it -- when you write the code you still think about the "types", you're just not writing them down.

Typescript's virtues are completely related to developer productivity. Documenting your code with types, better autocompletion, catching silly mistakes before needing to run it in a browser, getting new people up to speed, etc.

> TypeScript is only capable of addressing a theoretical maximum of 15% of “public bugs”, where public means that the bugs survived past the implementation phase and got committed to the public repository, according to Zheng Gao and Earl T. Barr from University College London, and Christian Bird from Microsoft Research.

The devil's in the details for studies like this and people ignore this to make it look like their opinion is backed up by science when it isn't. Measuring what percent help type safety gives in general is an impossibly vague concept while also very difficult to test, especially when making comparisons between numbers.

From the second study for example right in the abstract:

> Evaluating static type systems against public bugs, which have survived testing and review, is conservative: it understates their effectiveness at detecting bugs during private development, not to mention their other benefits such as facilitating code search/completion and serving as documentation. Despite this uneven playing field, our central finding is that both static type systems find an important percentage of public bugs: both Flow 0.30 and TypeScript 2.0 successfully detect 15%!

15% is a minimum from that study then and it isn't counting bugs that were caught from manual testing or otherwise before making a commit, or how much time was saved.

Quoting the study in this way is incredibly misleading in my opinion.

But when I actually had to use it in a project, I instantly fell in love with it. Not only does it force me to think about the proper scope and type of a function or variable, it also helps refactoring and reading undocumented code.

Yes, sometimes it can be frustrating (meh: no typings for a legacy project, build-toolchains have to handle another layer of abstraction, etc.). But this really is peanuts compared to the hoops we had go through before.

TS has been the best thing that has happened to JS-development in the last decade.

Uh... I'm pretty sure I've used both in TypeScript projects.

If you agree with the premise that static typing is a waste of time, you'll probably agree with the rest, but then you're likely not using TS in the first place. If you don't agree, the article is just wrong.

[1] https://twitter.com/Hillelogram/status/1084991487702691840

Another problem is that it focuses on bugs that make it out to production. Maybe for some projects production bugs are so costly that pre-production bugs are relatively negligible, but for most projects you can't treat pre-production bugs as 0 cost.

This is 20% for bugs, and 80% for sanity in long term maintenance. Refactoring is so much better / safer when you have a compilation process and at a minimum, types.

I just wish I could use Typescript without npm.

The biggest issue with typescript, and the reason I'll probably never reach for it for another large project despite having used it for a 50k line+ project, is that it's still, at its core, javascript. We've experienced a tremendous amount of pain because of this.

- We've needed libraries which don't provide typescript typings. Like a good little typescript user, we have strict mode enabled, which means we have to build our own typings when we encounter this. We've had library maintainers reject our typings we provide back to the community. We've had library maintainers say they have no desire to provide any support to typescript users because "its a fad" and "ts is just js, you don't need types, live with it" (not joking, not exaggerating).

- All of the good high-level JS frameworks and architectural libraries are built for, well, JS. So, you want to adapt them for TS, but the JS idioms are so core to their design that you throw away any benefit TS gives you. Express is a good example; you might have middleware which parses a bearer token and attaches it to the request. When the request hits the next middleware or request handler, its just a normal request. There's no way to assert at compile time that "this middleware came before, the request is now a new type with this extra field". Express, Apollo, the list goes on.

- Further, the community around creating Typescript-native libraries is exceedingly small and, as far as I can tell, dying. I'm talking libraries that are made for typescript and make use of the true end-to-end compile-time verification typescript gives you. TypeStack is probably the leading organization (on GitHub) which builds (amazing!) projects like this, and their velocity is slowing down. TypeDI hasn't seen an update in nine months. Vesper was an incredible web framework that hasn't been touched in a while. There's nothing available for MongoDB if you use that. Basically, you're stuck with JS native projects 90% of the time, and about 10% of those don't have typings available.

- We've had NPM libraries redefine the Error global. This isn't caught at compile-time, obviously, and totally borked the error responses our API sends.

- It's a constant uphill battle with the `as` keyword. I wish there was a way to easily ban it globally. You can essentially assert Anything As Anything, and if its not caught in review you'll end up with incredibly hard to trace behavior because "the compiler says this field should be there, why am I getting undefined"... well, its because sixteen layers down someone asserted a type without verifying its accuracy at runtime, and in 5% of situations its incorrect, and it missed review.

- It's a constant uphill battle with lodash. We have developers on some teams that swear by it, and will scatter `_.get`s all over the codebase, then be startled when things break in unexpected ways. Typescript added the `!` operator, which is basically just an escape hatch, and it took us a long time to get everyone educated that this is, without a doubt, the dumbest thing Microsoft has added to the language because it doesn't actually do anything at runtime, it just suppresses a potentially useful compiler error.

In summary, don't pick Typescript for the backend. It's an obvious improvement over JS, but you'll still be left wishing you hadn't.

But I also don't know what the better option is for a high-velocity organization. Go and Rust are too unproductive. Ruby and Python aren't performant and aren't strongly typed. JVM languages are a pain. Elixir shows a lot of promise but the lack of typing concerns me.

I discovered that in contrast to Flow, TypeScript has horrible errors. Often I ran into errors that would not give much more information than "error" -- no line information, no file information, nothing. One of the causes of such opaque errors was empty Flow-style typecasts, so they were pervasive throughout a large project.

In contrast, Flow has beautiful error messages.

I thought that was literally the reason TypeScript came to be. Microsoft were having lots trouble wrangling Bing web app and internal MS devs wanted a tool to help catch the bugs!

I would say, if you are embarking on a large scale app, you most definitely want to include TypeScript from the start. It will pay dividends in the end.

I don’t think you can write off the cost of learning all of those different tools in the non-Typescript environment. Typescript at least centralizes everything and I trust Microsoft to do good language development because of C#’s legacy alone.

I shipped an app about 90 days ago based on Typescript.

https://getpolarized.io/

It's basically a document manager which supports annotations, comments and keeping your documents in the cloud.

Typescript was a MASSIVE win. If you're on a simple code base doing a refactor is easy. Anything significant and it's a nightmare.

If you change an object method JS won't complain.

With Typescript and IntelliJ or VS Code it's just a simple refactoring and your code just works.

I would have probably given up on the project had it not been for TS.

Would I use Typescript for my own production use? Likely not. My perception is that it is yet another layer of complexity added to front-end development that, ultimately, does not need to be there.

Another very useful part is that refactoring becomes much easier, as you can simply follow the errors when you break an interface other parts of your code are relying on.

Typescript forces me to be more disciplined when coding, and that is clearly a good thing in my opinion. There are probably cases where you don't want that, e.g. rapid prototyping, but otherwise it's very useful.

This seems to imply that for whatever reason, TS may not be suitable in larger projects, but both Vue.js and Visual Studio Code are full TypeScript projects.

> ... but conscientious developers will be interested in doing things right. They’ll spend hours Googling for examples, trying to learn how to type things that TypeScript simply can’t type properly.

> ... if you only need to hire one or two developers, using TypeScript may make your opening more attractive to almost half the candidate pool.

On the other hand, it seems that the author worked on a few medium-size projects and then moved on:

> All projects for which impact was judged were >50k LOC with several collaborators working over several months.

So I wonder if he was able to evaluate the impacts from a longer term perspective, which shall include refactoring experience, iteration speed, developer morale, etc.

Going beyond just adding annotations is not what the references study attempted to do.

That said, Sucrase has a number of issues still. Nothing that can't be resolved, but enough to prevent me from using it in a few projects.