Hacker News new | past | comments | ask | show | jobs | submit login

Let's think about what happens on a team: If a single person goes and reads the source code to learn how the public API works instead of simply using the exported types, that's a wasted thirty minutes instead of two - okay, fine, whatever. If all of my engineers have to do this, suddenly each of them is spending that amount individually; and just like that, we've wasted an entire man-day, for nothing.

As you declared in your own comment, TypeScript is great for reading, hard for writing. I don't know about you, but my code is read several times more often, and by different people, than written. TypeScript is a no-brainer, time-saving wise.




I am a strong believer that every developer on a team should know how the code works. Emphasis on HOW. You only know that if you go to the source of truth. That is how people become proficient with a skill — by doing and re-doing and re-doing things.

I disagree that it's wasted time. The time spent investigating how a piece of code works is time extremely well spent.

If the code is too difficult to understand — of course one can hind behind types.

So, yeah, to sum it up — I think types are an overhead for a well written piece of code.


If the codebase is small and owned by a few people then it might be true. But when the codebase gets large enough and worked on by multiple teams - it is unreasonable to expect that everyone will understand the workings of the whole application.


I don't agree that typescript makes writing code hard. I believe the opposite- it makes writing code easier. Editor integrations are a godsend, even the minor things like auto-imports makes writing code easier.

More functionally, I also find Typescript's type refinement to help make sure I'm properly using the data and understand the state of it after I've done some checks.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: