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

81–90 of 120 posts

Re: The TypeScript Tax

#81

Post by ericelliott »

brlewis wrote: post #8

One problem with the math for the ROI calculation is that catching a bug with a test is counted the same as catching a bug while you're typing the buggy code. Type checking lets you catch bugs sooner, thus more cheaply. 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 projec…

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.

Re: The TypeScript Tax

#82

Post by ng12 »

ericelliott wrote: post #81
brlewis wrote: post #8

One problem with the math for the ROI calculation is that catching a bug with a test is counted the same as catching a bug while you're typing the buggy code. Type checking lets you catch bugs sooner, thus more cheaply. 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 projec…

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.

Re: The TypeScript Tax

#83

Post by ericelliott »

pgrizzay wrote: post #72
asark wrote: post #14

> Missing Features — HOFs, Composition Uh... I'm pretty sure I've used both in TypeScript projects.

This was the most infuriating part. He either doesn't understand what a hof is, is actively lying, or just hasn't even used typescript long enough to understand this is incorrect.

Please show me the proper typing of the map transducer in TypeScript. I'm willing to learn.

Re: The TypeScript Tax

#84

Post by ericelliott »

Novashi wrote: post #9

I hope I’ve got this right, but if the author is comparing typescript to a modern tooling environment, while there are technical differences, I may not trust those maintainers more than Microsoft at language design and support. 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…

Those tools have a negligable learning curve because once you set them up, you can simply forget about them and write JavaScript code.

Re: The TypeScript Tax

#85

Post by asark »

ericelliott wrote: post #74
asark wrote: post #40

Earlier quoted context omitted.

> Consequently, in his point-based model, he assigned that particular feature of the language +0.1 points. That's because his stupid chart is comparing a bunch of different things to TS instead of just comparing it to JS. In that case he's putting it up against TDD + code reviews, for reasons that I entirely do not understand. His numbers are so wildly incommensurate that they don't even make sense for any sort of in…

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 than you should or you have so few bugs that catching 10-20% of them isn't very valuable. Plus, read the thread. You just ignore all kinds of benefits of TypeScript (mostly benefits of having any, even half-assed, static type system on top of JS, period). If you like something else, propose it and compare TS to that. You're saying it's 1/10 better than vanilla JS with TDD + code review but 30x worse in terms of that benefit than JS when it comes to time spent adding types. 30. Times. That's just one example, the whole chart's a wreck in a similar fashion. Plus I bet if you ask on this thread folks will be happy to suggest + entries you simply omitted. See the ones suggesting (correctly) that static types make both TDD and code review, which you like, a hell of a lot faster.

In the worst case if some little thing you want to do won't work well in TS or is too expensive to type properly, write that piece in JS. Yes, that's terrible. [pause; significant look; raised eyebrows]. But it's not worse than JS. Obviously. And you can do that in TS. It's part of what makes it such an incredibly easy sell.

Re: The TypeScript Tax

#86

Post by asark »

AgentME wrote: post #65
013a wrote: post #58

My experience with TS is totally on the backend. 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 ha…

> 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). Why did you submit the types directly to them rather than to DefinitelyTyped? It's great when libraries maintain their own typings…

> Yeah, this can be a pain. In situations like this, I've defined types like `type RequestWithAuthField = Request & {auth: AuthField};` and then in handlers that I knew came after the auth middleware, I'd immediately cast the request parameter to that type. It is an escape hatch and I'd prefer to not have to do that though.

I find this less than ideal, of course, but still not worse than writing the same in plain JS, since at least this way the next person to come along (or you, a few months later) has clear guidance re: wtf is going on with those weird extra fields on the Request object. It's less effort—for reader and writer—and is more maintainable than expressing the same information as effectively in docs and comments.

Re: The TypeScript Tax

#87

Post by ng12 »

ericelliott wrote: post #83
pgrizzay wrote: post #72

Earlier quoted context omitted.

This was the most infuriating part. He either doesn't understand what a hof is, is actively lying, or just hasn't even used typescript long enough to understand this is incorrect.

Please show me the proper typing of the map transducer in TypeScript. I'm willing to learn.

It would seem that someone's done it already: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...

Re: The TypeScript Tax

#88

Post by fulafel »

This is a good analysis in the "JS or TS" domain, but it's of course seldom the only option to consider. TS competes with languages that compile to JS, so Elm, ClojureScript, Scala.js, Kotlin, etc.

Re: The TypeScript Tax

#89

Post by boubiyeah »

mrspeaker wrote: post #44
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.

The article is correct in that it's important to understand that typing your code has a cost - it's not just all magical benefits. Personally (personally - not for everybody) the cost is that it inhibits my initial experimentation. I don't KNOW what types things should be while I'm faffing around researching and experimenting in a new domain. I'm a huge fan of strongly-typed code, but I like to add the types much lat…

type IJustWantToExperiment = any

You could use the allowJs typescript flag and mostly use JS files at first; perhaps only typing a few models.

Re: The TypeScript Tax

#90

Post by lugg »

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?

Not AP,

But I'm curious, can you Tldr the tax for typescript?

I skimmed half the article but I couldnt actually find what the tax was?

In similar vein to the above above poster, you might find this lecture useful: https://youtube.com/watch?v=vtIzMaLkCaM

Your writing has a very nice cadence to it I'm just not sure you grasp the reason I might want to read it!

Post reply on HN