Hacker News new | ask | show | jobs
by x0x0 97 days ago
I found it not just to lead to embellishment, but (1) the problems it did flag mostly would be caught by minimal testing; whereas (2) it regularly missed deeper problems. For an example of the latter: using TanStack (React Query) api caching, you have different data shapes for infinite scroll vs non infinite scroll. There were circumstances were an app confused them. Typescript had nothing to say. Nominal typing easily handles these cases and, ime, caught more actual problems.
2 comments

> the problems it did flag mostly would be caught by minimal testing

Testing is more expensive up front and in maintenance than type annotations. A test suite comprehensive enough to replace type annotations would have an ass load of assertions that just asserted variable type; if you were involved in early pre-TS Node, you remember those test suites and how they basically made code immutable.

> (2) it regularly missed deeper problems

This is a skill issue. If your types do not match runtime behavior and you choose to blame the programming language rather than your usage of it, that's on you. There are a lot of unsafe edges to TS, but a diligent and disciplined engineer can keep them isolated and wrapped in safe blocks. Turn off `any`, turn on all the maximal strictness checks, and see if your code still passes, because if what you said about infinite scroll is true, it won't.

> here are a lot of unsafe edges to TS

And one of its many problems is that it tries quite hard to pass itself off as not having those unsafe edges which, ironically, makes it easier to get tripped up by them.

> the problems it did flag mostly would be caught by minimal testing

Yeah, I agree, and the thing is, you're going to write automated tests whether you're developing in JavaScript or TypeScript so the extra cruft of TypeScript seems even less worthwhile.

The argument I've heard people put forward is that JS is fine for small projects or a couple of developers but doesn't scale to large projects or teams. I don't know how large large is, but I've worked on a project with around 30 devs where the front-end was all JavaScript and everyone was touching it and, sure, that project had some problems, but the root cause of those problems wasn't using JavaScript.