We spend a disproportionate amount of time on types

Hacker News is a community-driven platform for sharing and discussing technology news, startups, and programming-related topics. Through user submissions and comments, Hacker News offers insights into emerging technology trends, industry developments, and entrepreneurial ventures. Readers can participate in discussions, share their insights, and stay informed about the latest advancements in technology and innovation.

Hacker News

library developers are shifting complexity from end-developers to library developers. As a library developer, typescript sucks for library developers, but at the end of the day it reduces developer productivity. The only tool that I know library developers use is the Typescript playground so they can isolate discrete parts of their type logic to figure.

Typescipt is terrible for library developers

I feel like I disagree with this. Adding strong type checking to your library (where possible) should be your goal. Typescript helps you write better javascript code.

Here’s my annoyed take. Having written both, I don’t see a difference between developing a library vs. writing frontend code. TS is equally great and terrible (mostly great and borderline required) for both.
I have a feeling the author simply never had the opportunity to work on and maintain a complex web app and might have a simplistic view of what a web app (not just a simple react SPA) is.
If you’re just using popular frameworks and libraries to build simple frontends, then everything is there for you on a silver platter - docs, patterns, examples, DOs and DONTs included. You don’t need to put much effort into getting to know TS inside out. But stray off that well-beaten path and you actually get to deal with writing stuff yourself. And in turn you get to deal with TS quirks. But guess what, those quirks are not specific to library code. It’s just that if you’re using someone else’s library, then that someone else has probably already put the effort to make sure that as a consumer you don’t have to deal with most of them.
And common, the author says he’s helping to maintain redux-saga (oh microsoft, will you ever make generators usable), he should know better.

For library users, it feels like a boon, for library developers, like a burden. However, as a developer on both sides, I still prefer typescript, even if it adds to my work, because I want to deliver an optimal developer experience (which is why I also add elaborate JSDoc comments to have helpful tooltips for my APIs).

<blockquote>
In effect, we are shifting complexity from end-developers to library developers. This places a huge burden on us to be experts with how typescript works.
</blockquote>
I disagree with this description of the relationship between library developers and end-developers. Shouldn’t a library (in a broad sense) introduce an abstraction that reduces complexity for end developers?

Great point, and I’m totally agree. Even when working on some tiny private packages I felt that Typescript is different for them and I need much more understanding of it in comparison to TS that I use for regular frontend projects