[JackMorgan]

Some people also hate parking between the lines and returning shopping carts at the grocery store. Those are similar in that they have negative value to the individual but help the community around them.

TS often can interrupt an individual's flow, so feels like a negative value. It's only when the whole team is using it on a bigger codebase with lots of changes that the benefits start to manifest.

[jazzsouff]

Not just with teams, going back to a solo project after some time is so much more of a hassle if you don't have any types to guide you.

[DanHulton]

A million times this. Many a time I have done something "clever" to elegantly solve a problem in Javascript, only to come back to it a year later and not understand what the hell I did. The context for the problem wasn't fresh, so I didn't understand why I was doing that "cleverness", nor what restrictions there were on that solution, etc.

I rewrote one of those projects in Typescript a while back, and came across a similar "clever" solution (mainly having to do with dates having potentially multiple sources, so being in potentially multiple formats), and it made the code _infinitely_ easier to understand. So much so that when I came back to it recently, one quick glance at the types for that section of code gave me all the information I needed to confidently extend that code without worrying about bizarre runtime errors.

People forget that even in single-person teams, you're actually working with many different "people" over the lifetime of the project, given how different you and your understanding of the context of your code will be over time.

[criley2]

Imagine you come from a small town where there are no parking lines at all, and everyone efficiently parks on unmarked blacktop in a respectful way.

Now imagine you go to a big city where they have a bunch of lines in the parking lot and people only half use them correctly, parking over the lines, diagonal, etc.

The existence of lines doesn't guarantee good behavior. The absence of lines doesn't guarantee bad behavior.

This is the argument I see for javascript-only folks who don't necessary enjoy using "the worlds most bloated javascript linter"

For the record, I am a Typescript enjoyer and I use it in my personal projects as well as professionally, but even I can admit that it's not automatically superior to javascript and it has a number of really frustrating and time-consuming downsides.

It's very easy to type the args and returns of a function and protect callers, but it's much more challenging to work with types between libraries and APIs all together. Lots of `as unknown as Type` or even the dreaded `any` to try and cobble the stack together.

[gibbitz]

100%. Great to have type consistency. Terrible to deal with similar conflicting extended types in the enterprise codebase that make minor changes because someone couldn't figure out a compiler issue 5 years ago.

For the record I don't like the syntax either. Combining ES type spreading with TS type annotation makes for difficult reading in my opinion. Why settle for this bastardized language and not just compile something made to be strongly typed into js?

[DanHulton]

That's apples and oranges, though. Sure, if you have a dev team that "parks via the shuffle algorithm", sure, painting lines isn't going to help.

But if you have a dev team that is taking the time to efficiently park in a respectful way, if you paint lines, _you're going to make that parking job a hell of a lot easier to do!_ And THAT's the big win of Typescript.

[vouwfietsman]

> the dreaded `any`

You're dreading javascript