Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The TypeScript Tax

medium.com

Post reply on HN
Print view View original

91–100 of 120 posts

Re: The TypeScript Tax

#91

Post by oaiey »

wanted2 wrote: post #61
kardianos wrote: post #3

For any JS that is over 100 lines, I will use Typescript without thinking. 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.

If you write 20% more bugs in pure JS you definitely should re-evaluate your skill. I'd never hire someone saying that to me.

If you write 6 bugs on 1 million locs of vanilla JS and 5 bugs with TS enabled, he can work for me in vanilla JS.

Re: The TypeScript Tax

#92

Post by seanwilson »

ericelliott wrote: post #80
seanwilson wrote: post #7

> Type safety doesn’t seem to make a big difference. TypeScript proponents frequently talk about the benefits of type safety, but there is little evidence that type safety makes a big difference in production bug density. This is important because code review and TDD make a very big difference (40% — 80% for TDD alone)... > TypeScript is only capable of addressing a theoretical maximum of 15% of “public bugs”, where…

The trouble is most projects are NOT employing the other reviews properly. The study made no effort to determine the quality of the test and review process, and instead assumed that they had been done by virtue of the bugs being merged to the master branch. The study then finds that about 80% of the bugs they found were not simply ts-undetectable, but not type errors at all. Instead, they're things like the wrong URL…

> The study made no effort to determine the quality of the test and review process

Assuming you wrote the article, why did you cite that study then?

> That means the maximum effect must be less than 20%

But what effect are you trying to argue? Maximum of what? I feel this is so vague it's not useful.

In my opinion (I'm not going to try to back this up with a study that doesn't measure exactly this), types make an enormous difference while you're in the middle of development before you commit anything: they're capturing cases where you forget a variable could be undefined, when you mix up items and lists, when you want to aggressively refactor, when you forget to pass required parameters etc. Type annotations are rarely required and for the few minutes I take to write them I easily make that time back even in the short term. Only looking at the bugs that get committed (which is super hard to measure) is missing out on a big aspect of the benefits.

You also need to consider that code reviews and writing TDD tests are time consuming to do as well.

Re: The TypeScript Tax

#93

Post by [deleted] »

ng12 wrote: post #82
ericelliott wrote: post #81

Earlier quoted context omitted.

Some good reasons for that: 1. I get type feedback in my browser with inference. 2. I get near real-time feedback from TDD on file save. 3. I get real-time lint feedback, too. The net result is I get several multiples better bug coverage than TypeScript alone can provide at about the same speed -- while writing idiomatic JS.

> TypeScript alone can provide at about the same speed If writing your unit tests contributes less overhead than writing TypeScript types you're doing something horribly wrong.

[deleted]

Re: The TypeScript Tax

#94

Post by uxp »

ericelliott wrote: post #73
uxp wrote: post #69

Earlier quoted context omitted.

I've personally been hired to clean up at least two of his codebases after he finds the next shiny object. Much like his prose, they flow beautifully and end up doing very little substantive work. I'd rather someone that knows that their shit stinks for X number of reasons than one that thought theirs was a work of art. My favorite question to ask a mid to senior interviewee is what do they hate or what would they ch…

Hello. Eric Elliott here. Which codebases were those, exactly?

Hi Dilvie, it's been a while. Mechanized was the first. The second was a job board type application I'm still under NDA for.

Re: The TypeScript Tax

#96

Post by xvilka »

When WebAssembly will be feature-complete and without the need to call JS for every DOM or API access - developers would be able to just use the proper programming languages, like Rust, OCaml, Haskell, etc, instead of relying on buggy JS universe.

Re: The TypeScript Tax

#97

Post by ng12 »

wanted2 wrote: post #62
geist wrote: post #16

Articles like this will certainly bring out the pro-Typescript people, so this got me thinking. I'd like to hear from people who tried Typescript and found they didn't like it for any number of reasons. 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.

Typescript projects definitely give me the most pain. You regularly end up to the point you have to resort to 'any' after hours of looking for a stupid type definition. IMAO it's just one big waste of time, just landed a job with a good old JS codebase, what a relief. TS might help for junior and medior developers so they make less mistakes. But I'm pretty sure if you can code Javascript well Typescript only stands i…

> But I'm pretty sure if you can code Javascript well Typescript only stands in your way when you want to create something.

You and the author are both overly concerned about writing code and completely ignoring maintainability. If you write your code once and never touch it again, sure, use plain JS. If you're going to come back in six months month and refactor it or hand it off to a co-worker and expect him to write some code TypeScript is a godsend.

Re: The TypeScript Tax

#98

Post by ericelliott »

asark wrote: post #85
ericelliott wrote: post #74

Earlier quoted context omitted.

The reasons you don't understand are clearly explained in the article (you can't skip them because 80% of bugs are not detectable by TypeScript), and if TypeScript actually could catch 100% of bugs, I'd rate it a perfect 10 on that point and the ROI would be game over. TypeScript would win because you could skip the other quality controls and save a ton of time. I wish.

No, I read it. It's nonsense and your numbers are bad beyond any excuse of napkin-math. They're plain ol' down-home gibberish. [edit] let me demonstrate: the most basic problem is that your numbers in various categories do not measure up to one another in any way that makes sense. -3 for writing typings, +0.1 for catching 10-20% of bugs that would reach production. Either you're having way more trouble writing types…

First of all, you're wildly over-stating the difference. The scale based on percent of time spent or saved. It's impossible on this scale to even say that TypeScript is three times worse than no types, let alone thirty times.

As for the bug reducing benefit, yes it's up to 20% if you do nothing but TypeScript. As explained in the article, 80% of bugs can't be addressed by static types at all, so you can't skip the other measures safely. The zero point includes the other measures, which easily cover 90%+ reductions, combined.

Since other measures catch type errors, too, we apply the TypeScript reduction after discounting the other errors caught. Even with the maximum benefit of the doubt, assuming TypeScript catches 20% of the remainder, it's still a small percent of a small percent. You get exponentially diminishing returns with each bug prevention measure you apply, and TypeScript can't catch the lion's share of bugs, so it's the only one that makes sense to leave out as a quality control measure.

Re: The TypeScript Tax

#99

Post by ericelliott »

seanwilson wrote: post #92
ericelliott wrote: post #80

Earlier quoted context omitted.

The trouble is most projects are NOT employing the other reviews properly. The study made no effort to determine the quality of the test and review process, and instead assumed that they had been done by virtue of the bugs being merged to the master branch. The study then finds that about 80% of the bugs they found were not simply ts-undetectable, but not type errors at all. Instead, they're things like the wrong URL…

> The study made no effort to determine the quality of the test and review process Assuming you wrote the article, why did you cite that study then? > That means the maximum effect must be less than 20% But what effect are you trying to argue? Maximum of what? I feel this is so vague it's not useful. In my opinion (I'm not going to try to back this up with a study that doesn't measure exactly this), types make an eno…

I get the same real-time error detection and refactoring help from type inference, lint, and TDD. Lint and inference gives me real-time editor feedback, TDD runs automatically on file save.

I do consider TDD and code reviews are costly but you can't skip them with TypeScript because at least 80% of bugs are not detectable with TypeScript.

Re: The TypeScript Tax

#100

Post by ericelliott »

ng12 wrote: post #82
ericelliott wrote: post #81

Earlier quoted context omitted.

Some good reasons for that: 1. I get type feedback in my browser with inference. 2. I get near real-time feedback from TDD on file save. 3. I get real-time lint feedback, too. The net result is I get several multiples better bug coverage than TypeScript alone can provide at about the same speed -- while writing idiomatic JS.

> TypeScript alone can provide at about the same speed If writing your unit tests contributes less overhead than writing TypeScript types you're doing something horribly wrong.

It's not less overhead, but you can't skip TDD with TypeScript because at least 80% of bugs are not detectable by TypeScript.
Post reply on HN