Comment by bern4444 | Hacker News Reader

Comment by bern4444 | Hacker News Reader

Parent Full thread

i) TS isn't a framework. And you don't have to use it everywhere in your system. You can decide how heavily to leverage it, developing a 'core' TS subset that powers a broader JS layer (or the opposite, or something different)

ii) Lots of libraries are extremely well documented and typed. This is the same in any language not just for types but also for docs, capability, perf etc. This argument applies to all software everywhere so it doesn't make sense to single out TS

iii) Error messages can sometimes be hard to follow. But you get better at parsing them very quickly when they get gnarly.

iv) Transpilation is nearly always a required step anyway. Adding TS support is minimal. There are plenty of tools that do TS to JS on an order of magnitude of MS.

All decisions are tradeoffs.

What benefits does it bring (ignoring the biggest one of them all)?

TS makes it easier to maintain software across large teams by providing a mechanism to express relationships in a codebase.

They are self documenting and replace a lot of JSDoc needs (letting you focus docs on more useful info like intent, design choices, example usage, etc).

Types can also replace the majority of unit tests validating code is correct saving time on running fewer unit tests and letting devs focus on integration tests.

Lastly, I've never seen or experienced something breaking from upgrading the Typescript version in a project. Even when a TS upgrade has 'breaking changes' they never actually break anything in practice that I've seen.

> ii) Lots of libraries are extremely well documented and typed. This is the same in any language not just for types but also for docs, capability, perf etc. This argument applies to all software everywhere so it doesn't make sense to single out TS

I am singling out TS because although most good libraries have documentation for all of their methods, along with examples, many useful and popular libraries do not include full documentation of their types. Some hardly any at all.

Usage examples are some of the most useful piece of documentation you can have in a library, but many authors choose to show their examples in JS, in order not to be too opinionated. It is the fact that TS is not actually part of the language, and simply an add on, that I believe is the cause of many of these issues.

> What benefits does it bring (ignoring the biggest one of them all)?

I do believe it brings benefits and agree with what you have written, of course my view is that those benefits just aren't worth the effort. In my experience some of the best codebases I interacted with were neatly written and well documented JavaScript codebases - no TypeScript, whereas many of the TypeScript codebases have been very hard to understand and work with. This is by no means due to TypeScript, however it doesn't make me think that it helps in terms of making anything that much better.

I can't even remember many times TypeScript has actually prevented a bug, it's been more useful for documentation. But then I would prefer JSDoc which isn't so difficult to maintain and can still provide autocompletion for you.

> many useful and popular libraries do not include full documentation of their types

> but many authors choose to show their examples in JS, in order not to be too opinionated

This is certainly true sometimes, but I don't see why it's a reason against using TypeScript? If you're calling a TypeScript API, the way you use it should look basically the same as the way you'd use it in JavaScript. You usually don't have to do anything special with the library's types unless you're getting fancy

There are exceptions- I've had a rough time fighting to get code using the styled-components library to fully typecheck, because that library gets super fancy with the way they represent things (I don't like it for that reason personally, but I know others do). But libraries like that are the exception in my experience, and if it's really that big of a drain on productivity, you can always bail out and use `any` types to skip dealing with it

I am thinking of the case where you are passing an object or class to an API that needs to be shaped a certain way. In this case you need to know which type to import/use to pass it through.

For many simple libraries it's not too much of an issue, but for more complex things like Apollo (which also doesn't include much TS in their docs) it's a lot of hit and miss until you get it right.

Sure, that can happen. I guess I feel like if it's that much of a problem for any given library, you always have various ways of disabling checks where you need to and still benefiting from them elsewhere. So it's still a net benefit

I will also say- GraphQL almost by nature is gonna be a really hairy thing to statically type, especially on the server side. We've got an Apollo server at my company and thus far we've pretty much just punted on trying to type that part of things. Which is also more okay than might be for other things, because GQL does its own runtime validation anyway

Reply on news.ycombinator.com