[xodeus]

> TS catches me writing numerous bugs a day

I see this sentiment a lot but I honestly can't think of any non-trivial bugs that TS has caught for me. 99% of the bugs it catches I would see 1 second later when my page hot reloads and crashes.

[fifticon]

well I can, I wrote a year-long js project that I abandoned as refactorings gradually turned into eternal bug-fests. I started from scratch in typescript, and the project is now 3x the dead project, with none of the bugs. and refactorings have become painless, with the compiler tools and editor telling me what I must fix up. There may be a special breed of programmers who need no such help, but I have yet to meet them in my 32+y long professional programming career :-)

[mixmastamyk]

You still have bugs, you just haven't found them yet. When strict typing is not available you adjust and use other tooling and tests.

Of course with a big, venerable project the balance changes drastically. But an experienced single-person project should be doable with javascript for a long while and may even get to MVP faster by focusing on things that are essential.

[CodeWriter23]

I’ve been coding professionally for 39 years. ts seemed very strange to me at first. Only even started using it because I had to do some customization in NetSuite and some third party type and build support in ts made comprehensible the typically-stilted and insane NetSuite js required by SuiteScript.

Now I’m addicted to it. Specifically the lightweight and easy to use _interface_ directive feeds my practice of self-documenting code with good doc and reusable data structures.

[redanddead]

what's your favorite thing about interfaces and why?

[vsnf]

That’s the beauty though, isn’t it. Most bugs are trivial. I appreciate typescript getting the trivial bugs right more often than I’d trust myself to do so.

[dleslie]

Right? The argument that static/strict typing mostly catches trivial bugs isn't an argument against the value of that language, and yet people seem to think it is!

[alrlroipsp]

Let them fight windmills while we have a good time.

[DogLover_]

I have to disagree. Adding the types will increase the number of the characters/lines of code which with a 80-char formatter limit can make functions look almost gibberish at a glance. Do that on a whole codebase and it becomes a mess to look at.

[_0w8t]

The verbosity of TypeScript types can be attributed to poor choice of syntax and names that became obvious retrospectively.

Still even with TypeScript if types makes your functions ugly, then it shows the complexity of the code. Often it also suggests sensible refactoring that without types would not be apparent.

[DogLover_]

Typscript: "function area(left: number, top: number, right: number, bottom: number): number {"

Javascript: "function area(left, top, right, bottom)"

In an editor the typescript function would likely be split into five separate lines.

"function area(

left: number,

top: number,

right: number,

bottom: number)

: number {"

None of the functions are complex but the the typescript function with the formatter creates a lot of noise.

[dleslie]

It's not noise, it's informative content.

It also means it's not going to explode when fed the wrong types, because that's not possible.

[eyelidlessness]

And I have to disagree in turn. Those additional characters and lines of code are documentation, and turn gibberish into not only human-readable clarity about the code you’re reading, but a machine-traversable dependency graph as well.

[hbrn]

The problem is that they are forced documentation. You can't choose to skip it after you became familiar with it.

[eyelidlessness]

That sounds like a VSCode extension I could write on a Saturday morning but whatever.

[dleslie]

Character input time is a vanishingly small concern for overall productivity. If it's a concern then you'll probably catch more bugs by slowing down to think.

[DogLover_]

Typing it is not the problem. It is reading at a glance that becomes much harder since lines oftentimes get split into multilines. I get less of an overview.

[dleslie]

It's all still there, except with even more helpful information.

If there are so many parameters that it falls out of mental context then there's too many parameters.

[davnicwil]

I find it catches a lot of design mistakes for me which I would put in the non-trivial bugs category. Many bugs that result from design mistakes are less immediate, like hard to spot edge cases (a better design makes them impossible) or code that lends itself to becoming messier and more bug prone in the future as it's changed/extended (a better design makes this less likely).

[jshen]

I’ve had the opposite experience with complex type systems. They make it harder to evolve out of bad designs. This is particularly true when a lot of inheritance is used.

[davnicwil]

Interesting. What I've found is that when I come up with some pattern that is hard to type, or I have two parts of a system that need to work together but the interface can't be typed simply or doesn't quite 'fit', it is almost always the case that changing things around until the types do work straightforwardly uncovers a better design.

This is definitely sometimes not easy, and of course it'll get more difficult generally the more code there is or the more complex (usually meaning bad!) the design is, but I'd almost put it the other way round to your perspective - the types are like the signposts in this design evolution and discovery process. They don't make it easier to do the work of refactoring a design, but they do make it much easier to understand when I'm going in a good/bad direction and also when I have succeeded.

[jshen]

You are describing writing code alone. I’m thinking about other peoples code I’ve had to deal with where I didn’t create the types. Not saying I’m great at it, but that you can’t always control the quality of the code you have to work on.

[zarzavat]

That is true for nominal type systems such as Java’s.

However TypeScript’s structural typing is much more flexible, because it is designed to describe the types of all the existing JavaScript code out there (via the DefinitelyTyped project).

This gives the best of both worlds: the freedom to express the architecture you need, plus the freedom to actually refactor an existing code base into that new architecture without introducing many bugs. Dynamically typed languages give you the former but not the latter.

[throwaway0asd]

Exactly, you have to run the code before you realize it’s defective and even then only the defects that execute will get any attention. With TypeScript the defects yell at you before executing the code.

[jshen]

But at what cost? We shouldn’t assume it’s free

[throwaway0asd]

The cost is the compile time. My personal application is about 50k loc so the compile time is about 9 seconds with TSC or 1.5 seconds with SWC.

[jshen]

There are other costs. One study I’ve seen found that writing libraries with typed generic code too longer to write, but we’re slightly faster to use. I’ve found that changing peoples badly typed code is worse than changing similar dynamic code.

In short, there is very little empirical data on this, and it’s almost entirely anecdotal. My gut feeling is that if typing were a huge benefit it wouldn’t be so hard to prove.

[throwaway0asd]

Avoid things like generics. Keep your types as primitive as possible. Strong typing will covert an excellent developer into an amazing developer but won’t do anything for extremely bad developers. Data types are not a solution to people problems.

[jshen]

Agree, but the question for me is whether it is clear that it’s better at organizational scale over decades. I think it is, but not hugely so.

Edit: I should add that I think there are a ton of things that are far more important for a high performing dev team than types.

[jjnoakes]

You get 100% code coverage within 1 second of page load?

[miiiiiike]

Many bugs are trivial until they slip into production.

[hbrn]

Runtime errors are the easiest to catch and fix.

With TS you're paying the full price (in verbosity and complexity) but getting 10% of the value. There probably still are projects where it's a good deal, but my bet is they are the minority.