The biggest use of types, for me, is being able to read code more easily. Right now, I'm elbow deep in some old PHP code, and it is painful trying to trace the flow of data through a system.

What is $item? What does it contain? I have no idea, and to find out, I have to dig through at least five files (so far) to figure out how it's put together.

nothing is better than vanilla javascript "props" object with no documentation, several non-consistent key calls and spaghetti code.

and some `...rest` spread that could be anything anytime in the future.

Came here to say basically the same thing. Reducing runtime errors is not the only benefit of types, or sometimes investing in complex types.

Ease of reading, code navigation, refactoring, producing documentation, code generation, etc... there are myriad benefits.

As you would expect from something that fundamentally helps computers (and humans) understand and verify the intent and structure of code better.

> Is the time you’re spending on implementing the type-safe solution paying off in bug reduction and other benefits?

As someone working on a team with a large monorepo with strict type requirements, I will say my life is a lot easier with types than without. Types are documentation plain and simple, they require devs to state their intentions in code which is extremely valuable for other devs on the project.

More importantly, they’re documentation which is guaranteed to be correct.

Yup. The more detail you can put in the code itself the better.

I think not getting hung up on a method to solving a problem is a great message to remember. You should be open to switch to a different method if it solves the problem better.

Type safety is just one such method. The actual problem is making code easier to maintain for humans. Type safety is not always the best means to that end. Our brains perceive information in a complicated way. Sometimes too much information can overwhelm us and obfuscate something simple. Sometimes too much detail about each value can make us lose the overall flow of the program.

My advice: (aside from reading other people's code) try to read what you wrote, and have others read what you wrote in code reviews. Do you and your colleagues understand it? Make it as brief and simple as possible without losing that understanding. Address any "how" questions by rewriting the code clearer, "what" questions by improving naming, and "why" questions by adding comments. These are your code's 3 primary objectives: explaining how, what, and why to your colleagues. I once wrote a post about it.[1]

[1]: https://max.engineer/maintainable-code

The React example given at the end misses out on one issue where even linters can't help: fetching data and accessing its contents. Setting aside error handling (fetch call fails), the response data could have a different schema than what the code expects.

This is what parsers are for (in TS: zod, valibot, joi, yup et al). Preferably those that can express type definitions for their output that matches the runtime validation.

You can't have type-safety without untrusted input parsing.

The funny thing is that this example would be much better with a type system that properly modeled state and effects.

>What I mean is that, on its own, type safety is not important. It’s only useful because of what it accomplishes: moving errors from runtime to compile time.

Air doesn't matter! It's only useful because of what our bodies do with it

Good luck working with some nested structures.

Edit: I'm a bit triggered. I don't get how this trivial example showcases anything. You always use types. They are either written down or in your mind. Unfortunately, collaboration happens, and I'm not in your mind.

I understand how you feel, I can't possibly imagine a scenario where you don't want to document types unless you're working on a project that you expect to not work on ever again in a month