> In other words, I call bullshit on this entire blog post. Ignore it. Typescript is the correct solution. What is the alternative? Just using JS and letting things break without knowing it?

It seems like you and I read a different article. The post I read did not advocate for going back to JS; rather it advocated for better tooling and documentation (with examples, ideally) for library developers

    Conclusion
    I love typescript and think the team working on it are incredible. Typescript has completely changed the FE landscape and wouldn't want to dismiss its contributions.
    But as a library developer, we need:
    - better documentation,
    - better tooling, and
    - to spend less time making tsc happy.
    I shouldn't have to read the typescript compiler source code in order to figure out why it's resolving a piece of my code to a specific type.

I developed a library used by the React app I work on to cache network results in localstorage (to reduce the number of expensive requests made on page refreshes) and generate React-Query query-functions to read the result from localStorage first before fetching from the network as a fallback (if the data is stale or uncached).

It's not an especially large library, but I felt all of the pain points the author describes. It's great that you didn't with your library (and I'm sure there are large classes of libraries whose authors wouldn't feel these pain points), but it's a very real issue if your dealing heavily with generics, serialization/deserialization, and/or complex type interactions

You answered your own question, learn how typing and generics work and you wouldn’t have had those issues.

The entire article persecuted TS because the author wanted to learn quicker with little effort. Writing TypeScript in a node, app or library makes no difference. It is a language, NOT a framework.

Yes, and a great way to do that is to read documentation, of which Typescript is frequently lacking. For example, I got a suggestion in the discord recently to use "generic parameter defaults" for a problem I was having, which were documented... in the release notes for Typescript 2.3... and no where else: https://www.typescriptlang.org/docs/handbook/release-notes/t...

I love Typescript but I just don’t think this is correct. Look at the Node documentation and then the Typescript documentation. The former tries to describe every behavior, the latter tries to give you a 101 in the feature. This is especially clear when it comes to the Deno and SWC teams’ attempts to reimplement tsc in a faster language - typescript doesn’t have a spec so they’re stuck looking at the tsc codebase to infer behavior.

I think you intended this as a reply to someone else. Or at least, it sounds like you're agreeing with me.

> Yes, and a great way to do that is to read documentation, of which Typescript is frequently lacking.

I completely disagree, and I was surprised by this sort of comment.

Find me a single programming language whose docs are as good as TypeScript's docs and reference. I'd be surprised if you could come up with a single example.

I think others have covered it here, but I want to point out that I actually think Typescript's docs are quite good for end-users! But, like the article here points out, lacking, for library authors.

There are lots of ways to do things that you kind of just have to learn from reading blog posts, or reading code and then asking in the discord when you see something undocumented (because have you tried googling "what does <T=...> in Typescript mean"?).

Ideally, at the very least, all syntactic features and keywords of the language should be documented, but it's more than that; Typescript is a metalanguage, and authors of many libraries have also developed patterns which are essential for describing complex types. Some of these patterns are documented (for example, discriminating union), and some are not (for example, opaque types). And some features which are documented could do with a lot more exposition and functional examples ("as const"), or notes on when to avoid (enum).

First hit for "Typescript equals in generic" is https://stackoverflow.com/questions/56843790/typescript-gene... which explains it. No search results in the docs, sure, but the very first hit for the first query I tried gave me the answer.

Whilst that's good, the TS documents should document this. Google searching and stackoverflow is not a valid replacement for actual documentation, IMO.

Certainly they should document it, but as an answer to "(because have you tried googling "what does <T=...> in Typescript mean"?)", I think it seems pretty conclusive :P

> because have you tried googling "what does <T=...> in Typescript mean"?

Search “typescript generics syntax” and you get the excellent TypeScript docs on generics as the first result. It covers generic constraints.

> It covers generic constraints.

Indeed, but I'm not sure how that's relevant since it doesn't cover generic parameter defaults.

C#, C++, Java (actually I am betting no one can beat that one)

I think you dismissed the actual issue he faced- gen type defaults, which I just looked is still not actually documented, it's just in the release notes.

Don't get me wrong, TS is my favorite language, but let's not gloss over things.

My career has been 95% c#.

Recently learning rust (spare time) and c++ for work. The documentation for these 2 are awesome!

PostgreSQL has great docs too

I think we are better at writing docs for programming languages than we are at libraries and frameworks. Maybe because languages are more ‘fixed’ and less likely to change so over time they just get better and better.

You picked two of the best documented projects around in Rust and PostgreSQL. I don't think that inferior documentation for libraries is a foregone conclusion. Rust's serde library is exceptionally well documented IMO.

It's a matter of having the skill and the will though, and I feel like a lot of projects simply don't emphasize documentation. Even so, not everyone's going to be a good technical writer.

What I mean is I think in general languages tend to have better docs.

Vue has excellent docs imo.

But in terms of technical writing being a skill. I agree. I appreciate the effort people put into docs. I try my best but I’m not very good. So I have a lot of respect for anyone who can sit and write excellent docs.

It's been a long time since I've dug for C++ docs but in general I found Qt to be well documented (if a bit disorganized with the newer stuff). STL documentation always seemed inaccessible to me, but then again I'm working off of some pretty hazy memories.

Commercially supported software Qt (and in the parent post, Vue) tend to have good docs. It makes sense: supporting developers is their business model. Likewise tools with ecosystems of companies (postgresql) tend to get good docs over time. The bigger pain points are tools supported by a major company ... but that used by the business rather than sold. There probably are _some_ good docs - especially at the project launch or major milestones - but they aren't as actively curated.

> Find me a single programming language whose docs are as good as TypeScript's docs and reference.

This is a non sequitur. Typescript can be bad even if other languages are worse.

The argument being made in the article and this discussion isn't "use X instead of Typescript" it's "Typescript should be improved".

Is the argument "Typescript should be improved" or "We should allocate enough time/money from other things to improve Typescript"?

The former is vacuously true once you know it is an option. Everything would be better if it could be improved.

The latter is subject to questions about cost. If Typescript had best in its class docs, that would imply that other communities had failed to find or execute a practical option to turn time/money into docs improvements. That would be moderately persuasive evidence that Typescript's resources are better spent elsewhere.

---------

On an object level: Django and the python community tend to have great docs.

It could also be about refocusing within the Typescript project.

Golang has https://pkg.go.dev. Rust has https://docs.rs

Golang entire standard library is documented. Plus with how the language is designed docs don’t need to change with new versions. Just with new functions.

More importantly, golang has https://go.dev/ref/spec — most of the time I wished for better TypeScript documentation it's about syntax (though I did need to go read the default bundled libraries a couple times for details, that's rarer).

PHP used to have amazing documentation back in the days.

Everything spelled out. No "you must read the whole thing or have worked with it for years to understand page 5".

Plenty of inline examples and even more user submitted ones (although as with all user generated content, some caution should be used when reading those).

Have we used the same PHP? IME it's usually necessary to read the comments on the documentation for important information, which is frequently totally absent in the actual documentation.

Haven't used PHP seriously for a decade I think so I might have a bit of rose tinted glasses.

But I am fairly certain that like the Perl documentation and unlike Java and Spring docs none of them was infuriating.

JavaScript

Do you have an example? I've seen TypeScript handle crazy nested types (and generics) with ease.

Perhaps the React-Query source itself is a good example of when "simple" is still not "easy to read/write":

I picked out this file pretty arbitrarily: https://github.com/TanStack/query/blob/main/packages/react-q...

The author of react-query seems to be very clear at communicating how the library works and the library itself provides a great developer experience, but it's also an example of how much work can go into correct typing in library code.

I recently typed my state for zustand (react library for managing state) and it was a horrible experience.

An example from the docs with middleware:

https://docs.pmnd.rs/zustand/typescript#middleware-that-chan...

If anyone calls this “easy, just learn generics” I won’t believe them further.

Honestly, if that's what it takes to make something work with Typescript I'm surprised anyone uses it. I thought Scala/Cats was the only language/cult that indulged typism to this extent. **d save us from the static typing Spanish Inquisition and bring back dynamic languages.

Seeing one the worst implementation of static typing and then blaming static typing as a whole is unfair. gradual typing is just an abomination in practice as can be seen in both TS and Python. Maybe a language that's build from the start with gradual typing in mind can make it good but I doubt it. Static and dynamic typing are just at odds in general.

The types in Typescript are amazing. I believe they’re turing complete? The problem is that this allows people to do many really complicated things that’d just be avoided or impossible in other languages.

Typescript is a horrible as you make it.

Yeah, this is the sentiment I keep feeling looking at most of the examples being provided in this thread and the article. A lot of the things people are doing here aren't even possible in most static typed object oriented languages or are hard to do and generally discouraged, and violate things like the Liskov Substitution Principle and Open/Closed Principle (especially the Open/Closed Principle; many of these examples are redux adjacent and a lot of them require modifying existing State object instances rather than extending them at a class level per the principle).

Many of these things are easy to do in JS because JS wasn't built to be static typed object oriented language. Many of these are hard to type because the underlying language is so permissive.

As library authors the desire is to be as permissive as possible, to use the "simplicity" of the untyped JS language to express an API surface that accepts any combination of possible inputs and does the greatest amount of work with that. There are many "JS native" libraries that do that, including JQuery's $ "operator" that was a swiss army knife of a million different tasks all using a single constructor which created object instances that any number of plugins mutated over time. As a JQuery user that was a very easy experience to work with, it's permissivity felt like simplicity and easy-to-learn. As someone who briefly spent time debugging JQuery types definitions in Typescript, that was an incredible nightmare. (That was also many, many versions of Typescript back with fewer typing tools, many of which would have helped a lot, but also made everything even more complex than it was at the time.)

I do feel like a lot of library authors sometimes need to ask themselves as types grow more complicated in their libraries if the trade-offs are worth it. That "simple" API they are trying to give their users, is there a more "complicated" API with simpler types to use instead? Sometimes that's actually the simpler API to use understand too, but many of your end users see your types indirectly and simpler types in the API are simpler experiences of those types.

The article mentions needing to add lots of overloads and that's specifically something I'm thinking about there. Another example in this thread included a function that could take a set of arguments as either an object ({ a?: thing, b?: someOtherThing, c?: thirdThing }) or tuple ([a, b, c]: [thing, someOtherThing?, thirdThing?]) and in both cases many of the parts were optional, complicated further by the thing type being generic itself and the tuple accepting different orders of parameters. Can you just pick one, object or tuple for your API? Users have "less freedom" to do as they wish and the result seems less "simple", but you can eliminate so much complexity in your types. If you do still need both ways, maybe it's reasonable to split from "overloads" to different functions setThingsObject(things: { a?: thing, b?: someOtherThing, c?: thirdThing }) versus setThingsQuickly(things: [thing?, someOtherThing?, thirdThing? ]).

It's easy to armchair quarterback refactor other people's APIs, of course, but it's certainly a factor when I'm building my own APIs: These types are starting to get complicated here, should I refactor to simpler types? Should this API be split into two different/distinct endpoints to simplify the type signature? And so forth.

Some complexity is unavoidable, of course, but sometimes it is worth trading "simple, permissive JS with incredibly complex types" for "tedious explosion of JS that looks complex at first glance with incredibly simple types". It's a deep trade-off space to explore and what's right for any individual project is deeply personal opinion.

We use Rematch/Redux for state management and typing it[1] was pretty easy.

I think it really depends.

[1] https://rematchjs.org/docs/getting-started/typescript

That is terrible. Good luck onboarding new developers or junior team members into your project.

I get playing with technology for side projects, but for something commercial there is no way I would sign off on including that package into a project.

Did you miss this example from the linked post about redux-toolkit? https://github.com/reduxjs/redux-toolkit/blob/4ab8c42cb20ae1...

This is what types look like when you're on the library side. The post made very clear they aren't talking about the app dev side. The library types are complex like this so that the app devs have a smoother experience.

Might help understanding if the author used ‘meaningful’ variable names…

It would be more understandable if you didn’t use single letter type names (someone posted an example from react-query elsewhere)

Those are some huge ternary ifs

I really wish Typescript had a great pattern matching system. It would be very nice indeed for structural typing, everything would be easier to read, probably some ways to add more power/expressivity, etc.

eg

    type GetOptions<T> =
      // Part 1: responsible for applying explicit type parameter to function arguments, if object { queryFnData: TQueryFnData, error: TError, data: TData }
      T extends {
        queryFnData: infer TQueryFnData
        error?: infer TError
        data: infer TData
      }
        ? UseQueryOptionsForUseQueries<TQueryFnData, TError, TData>
        : T extends { queryFnData: infer TQueryFnData; error?: infer TError }
        ? UseQueryOptionsForUseQueries<TQueryFnData, TError>
        : T extends { data: infer TData; error?: infer TError }
        ? UseQueryOptionsForUseQueries<unknown, TError, TData>
        : // Part 2: responsible for applying explicit type parameter to function arguments, if tuple [TQueryFnData, TError, TData]
        T extends [infer TQueryFnData, infer TError, infer TData]
        // ...

becomes

    type GetOptions<T> =
      // Part 1: responsible for applying explicit type parameter to function arguments, if object { queryFnData: TQueryFnData, error: TError, data: TData }
      T extends match { 
          { queryFnData: infer TQueryFnData, error?: infer TError, data: infer TData } => UseQueryOptionsForUseQueries<TQueryFnData, TError, TData>
          { queryFnData: infer TQueryFnData; error?: infer TError } => UseQueryOptionsForUseQueries<TQueryFnData, TError>,
          { data: infer TData; error?: infer TError }               => UseQueryOptionsForUseQueries<unknown, TError, TData>,
          [infer TQueryFnData, infer TError, infer TData]           => UseQueryOptionsForUseQueries<TQueryFnData, TError, TData>
          [infer TQueryFnData, infer TError]                        => UseQueryOptionsForUseQueries<TQueryFnData, TError>
          // ...
      }

or even, to make the top level way easy to understand in this case:

    type GetOptions<T> =
      T extends match { 
          Part1 => Part1Match
          Part2 => Part2Match
          Part3 => Part3Match
      }

where Part1Match etc are themselves pattern matches, so you can compose them like functions.

IME it's precisely the expressivity of nested types and generics and variations thereof that makes it hard for the library author.

The expressivity makes it possible for library authors have IntelliSense give more useful suggestions to the consumer, make automatic inference work in more places for the consumer, and make more illegal usage be impossible, at the expense of complicated type constructs. But of course all these is somewhat optional.

What library is this I was looking for a good cache to store network results quite recently?

It's not open-source or really polished for consumption. I did get permission to open-source it, but unfortunately didn't have the time to improve it to the point where it would be broadly useful.

In fact, now that https://tanstack.com/query/v4/docs/plugins/persistQueryClien... appears to be stable I'm thinking it might even be good to migrate to this (though it appears to require multiple queryclients if you want different cache parameters)

> Typescript is the correct solution. What is the alternative? Just using JS and letting things break without knowing it? Come on.

Surely that's not the only alternative.

Here's a few off the top of my head:

- Being able to write complex types in a syntax that more closely resembles JavaScript. Using Array length for counting or nested ternaries for if logic gets old fast.

- Being able to debug types, not console output, a real debugger. See: https://twitter.com/MarcJSchmidt/status/1539787500788613120

- More comprehensive documentation on writing advanced types

- A typescript specification

> Being able to write complex types in a syntax that more closely resembles JavaScript

Yikes. This is how you end up in preprocessor hell. Macros are generally not a good thing. (Fyi: TS types are already Turing-complete which is arguably a mistake.)

> Being able to debug types, not console output

Eh. It's not like Java has a "type debugger." Why is this needed? Why are your types so complex? Weird ask.

> More comprehensive documentation on writing advanced types

Really beating the same drum here.

> A typescript specification

What does this mean? We have a pretty clear typescript spec[1].

[1] https://github.com/microsoft/TypeScript/blob/main/doc/spec-A...

> Yikes. This is how you end up in preprocessor hell. Macros are generally not a good thing.

Not suggesting macros, rather an alternative way to define types. A function that accepts and returns types. Seeing as typescript has a JavaScript interpreter I thought it might be feasible but I'm just spitballing it.

> Eh. It's not like Java has a "type debugger." Why is this needed? Why are your types so complex? Weird ask.

I don't buy this argument. Writing any type of complex types with recursion, arrays or ternaries sucks and it will take more than "this is how Java does it" to convince me otherwise. I like to debug with a debugger, not my head.

Take a look at the examples in the article to see some complex types and read some tweets from library authors complaining on twitter. I can find some examples if you're interested.

> We have a pretty clear typescript spec

I hadn't actually seen this and it looks interesting but seems pretty out of date, Typescript 1.8?

> Why are your types so complex?

The article (and ensuing discussion) are about _library_ code, which necessarily has types that are orders of magnitude more complex than application code (source: see some of the links in the article).

The reason this isn't a problem in Java, C# etc is that the things these libraries do simply _aren't possible_ in the Java type system, so no one does them, and users end up with (usually) clunkier libraries.

React has its roots in StandardML and it's showing them here. Java, C# (and ma y other languages) barely scrape the surface of what you can do with a type system.

Now there's definitely a question of when you start hitting diminishing returns but you can definitely do so much with and extract confidence from very strongly typed languages.

> React has its roots in StandardML

Really? This is fascinating, is there anywhere with more on this?

> The article (and ensuing discussion) are about _library_ code, which necessarily has types that are orders of magnitude more complex than application code (source: see some of the links in the article).

Are you somehow implying that C++ or Java don't have libraries? As a sidenote, React (and that entire ecosystem) is an architectural hellscape (see Vue for much more streamlined & cleaner code).

No, I'm just saying the libraries in those languages tend to be designed differently, to accommodate the more limited type systems (but I don't use C++, so I'm sure templates can do a lot of things I'm not aware of).

I'm also not necessarily saying this is a good or bad thing overall, since it can so easily lead to extra complexity.

FWIW, I'd choose C#/Rust/Kotlin/etc over TS 100% of the time for projects that don't need to run in a browser.

> - Being able to debug types, not console output, a real debugger. See: https://twitter.com/MarcJSchmidt/status/1539787500788613120

That is really nice. I'd love to see that live.

Good for you. I was somewhat disappointed with TypeScript in the beginning, because I tried to use the type system like I would use it in Swift or Scala. That's not really a good idea. If instead, you view TypeScript as a smoother implementation of JavaScript + JSDoc, then it becomes a really powerful tool, which I like more and more!

> I call bullshit on this entire blog post.

How? None of what you are talking about directly relates to the article. It feels like you are just reacting to the title and not the contents.

For instance, you say:

> I call bullshit on this entire blog post. Ignore it. Typescript is the correct solution. What is the alternative? Just using JS and letting things break without knowing it? Come on.

But the article says:

> I love typescript and think the team working on it are incredible. Typescript has completely changed the FE landscape and wouldn't want to dismiss its contributions.

> But as a library developer, we need:

> - better documentation,

> - better tooling, and

> - to spend less time making tsc happy.

This is not an article advocating for “just using JS and letting things break”, so why are you reacting as if it is?

> This is not an article advocating for “just using JS and letting things break”, so why are you reacting as if it is?

Because the tone of the article seems to be that Typescript is horrible, and the tenor seems to be that the author is blaming his own incompetence on the language.

He has a point hidden in there somewhere, but I needed the HN comments to point it out to me.

That's... not at _all_ what the author said.

Summarizing the sections:

- Documentation: there's docs on how to use the language as a whole, but nothing focused on writing libraries (how to build/publish, type tricks that libraries may need that apps don't, etc)

- Debugging: debugging types is a nightmare - you basically have to hover over temp variables to see what intermediate values are

- Complexity: TS types for real-world lib code can get complicated

- Testing: testing types is necessary, and the community has had to invent tools to help with that

- Maintenance: maintaining types and responding to issues takes up time

None of those are comments that "TS is horrible". Those are all straightforward concerns with the experience of writing and maintaining a TS-typed library, and as a Redux maintainer I can back up every single one of those. I actually did a talk on "Lessons from Maintaining TS Libraries" a few months ago, and I hit all of those points myself:

https://blog.isquaredsoftware.com/2022/05/presentations-ts-l...

To go through them point by point:

> Documentation: there's docs on how to use the language as a whole, but nothing focused on writing libraries (how to build/publish, type tricks that libraries may need that apps don't, etc)

Why would there be? Building and publishing libraries is a npm thing, and has nothing whatsoever to do with Typescript. Type tricks that libraries may need? If you are going to write a section like that it’s pointless to write it about libraries in specific. There is nothing about building libraries in specific because Typescript isn’t about building libraries.

> Debugging: debugging types is a nightmare - you basically have to hover over temp variables to see what intermediate values are

Sort of, if you’ve managed to make your types complex enough that you cannot reason about them. But then again, I don’t know of any other language that feels the need to provide a type debugger. The fact that people working with Typescript think they need it is either testament to their competence, or the ridiculous constructions they make.

> Complexity: TS types for real-world lib code can get complicated

Well, yeah. But it’s exactly as complicated as you make it.

> Testing: testing types is necessary, and the community has had to invent tools to help with that

I don’t know of any other language that thinks testing types is necessary. The big issue in Typescript is that types don’t guarantee anything about runtime behavior.

> Maintenance: maintaining types and responding to issues takes up time

Well yes. Maintaining any library in any language takes time. Do people think this is unique to Typescript?

I guess my own point mainly comes down to no other language having any of these things, and the OP’s idea that it’s on the TS authors to provide it feels misplaced. It’s not core to the language, and a lot of the problems are self inflicted.

The blog post/slides were interesting though :)

I'm afraid I'll have to disagree with all of the above, especially the part about building libs.

Per the OP's article and my slides, there _are_ many aspects of maintaining a lib that are unique to TS above and beyond a plain JS lib, and it would be really helpful to have additional docs and tools available to help with our use cases.

I agree so much with you.

I would even say: most libraries used for just about anything, are written in C/C++/Java, all of which are typed languages.

The post's author simply lacks the education and experience to actually have a valid opinion on this topic.

You've both missed the point of the article. The author isn't saying TS (or typed languages in general) are bad, just that the tooling and documentation for _library authors_ could be better.

The things the author talks about aren't even remotely possible in the type systems of pretty much any other mainstream language, so I don't know how you could interpret this as a "TS bad" post if you read past the headline.

> The post's author simply lacks the education and experience to actually have a valid opinion

Besides your take being just outrageously exclusionary – the author is Eric Bower, a principal engineer who's also a Redux Saga maintainer. They're more than qualified to weigh in on this.

And their opinion is to push the complexities further up the ladder onto the makers of the tooling.

I’ve seen some crazy assed stuff they do with C++ templates and my reaction isn’t that they need to be spending their time on writing blog posts to explain the dark mysteries to me but that maybe I’m not the one who should be trying to write a library without spending a massive amount of time learning how this stuff works.

Sure, I can beat a template into submission using the famously helpful error messages the compiler provides and some random blog posts by people who actually understand what’s going on and I’m very thankful that they spent the time explaining it. Even having 1000 line long error messages helps once you learn what it is really complaining about. And this isn’t even my literal job, just something I do because I enjoy it.

This is yet another comment indicating the author lacks enough knowledge to even talk about this. Why is this the default response from HN on matters like these?

Might have something to how the author chose to express his opinions. FWIW, I got the same impression from the article, but did not bother to write a comment until now.

IMO, the author could have done better by providing more concrete examples for the points of criticism, and understating the conclusion or moving it to the end or dropping it entirely, as I think it's better to give the reader the choice to make up his own mind, given the facts and evidence.

What?

Just because I disagree with their premise (tool writers need to take responsibility for my lack of knowledge) doesn’t mean I think they can’t talk about it.

I mean, if they weren’t talking about it I’d have nothing to disagree with and have to do something productive.

And, you know, appeal to authority isn’t a valid counter argument…

> Just using JS and letting things break without knowing it?

And if types change, and it still works, it's basically working by accident.

> And if types change, and it still works, it's basically working by accident.

So the Liskov substitution principle now passes off as "working by accident"?

That’s a pretty underspecified comment for a static typing enthusiast. You’re referring to polymorphism.

And to be completely clear: you can have safe polymorphism without type hierarchies via things like type inference.

If types change, it doesn't compile and I can't do a release in CI.

I don't consider that working.

I'm agreeing with you here. If you use plain JS and change the underlying types that are being passed around, but things are still working, you're basically getting lucky.

Ok, got it. Apologies.

If you write comprehensive unit tests for your javascript, that should effectively also work too... this is what ruby developers pretty much had to do.

We can see that over time based on the decline of ruby popularity in general, that fell out of style though. It is too easy to make a mistake and everyone was just duplicating what a compiler does for us.

I can't tell you how many hours I would sit there pair programming with other ruby developers just trying to figure out what 'type' an object is. Mind boggling, but it was good to get those high paid consulting hours.

RubyMine to the rescue.

We were using that and it is indeed excellent (along with most of JetBrains IDE products). It starts to fall down on all the meta programming we were dealing with. With a dynamic meta programmed DSL, there is only so much RM can deal with.

Maybe you missed the point here.

"Lean how to use my types!"

Any given project uses a large number of libraries.

The point of a library is that it's 'useful'.

When a large number of libraries use vague and differing typings, it becomes impossible to manage.

The fragmentation created by the agile nature of Typescript is, predictably, a giant problem.

Anyone can write bad software with terrible APIs. That isn't the problem of the language and certainly doesn't make it 'terrible for library developers'.

My point is that I've written a library that gets a lot of use. It has decent enough APIs. Nobody is writing blog posts like this about my stuff.

What package do you publish? https://github.com/lookfirst/mui-rff?

Do you get paid for any of this?

Not directly. I've been developing open source for almost 30 years now (I co-founded Apache Java/Jakarta). I consider that the experience gained from developing extra curricular projects pays for itself in other ways. For example, I've never had to interview or even look for a job and I've never been laid off.

I really wish I could work in OSS more. Have contributed to several libraries intermittently. How do you find time to do both OSS work and your day job? does your employer allow your OSS contributions to count as work there? I wish I could find the key to that balance.

Whenever I find those guys on Github with several maintained multi-thousand star projects, I wonder "how do they do it?" (fund themselves + work on OSS). I am always curious about the underlying life stuff

Thanks in advance!

The way that I look at it is that the vast majority of developers depend on some open source project. This means that we find bugs or missing features in other peoples code in our day to day coding. That's a perfect excuse to contribute upstream. If your company has legal policies against that, then honestly... there are other jobs out there. I know that sounds kind of blunt, but I've always made it clear to my employers before I start, that I'm going to contribute to the greater good as part of my work.

In this case, I needed the code for an internal project and decided that the company would benefit the most from making it a library and getting outside help on it. It was an itch that I knew many other people needed scratched because there was a competing project that had gone silent and was incomplete/poor quality. That justified my time spent... I had to write the code either way, might as well make it open.

When I look for people to hire, and I've done a lot of hiring over the years, I primarily look for people like myself who put that extra effort in. Either in their own personal projects or by at least contributing to something upstream. Even just simple documentation changes is something I'd hire over. I fully understand that people have lives outside of work, but honestly... if you're going to be a top developer, you've got to put in a top level of effort, because other people around you are.

> you've got to put in a top level of effort, because other people around you are

In my experience, only about 20% are.

Invest in yourself and you'll never work a day in your life.

> TypeScript is terrible for library developers

That's the title. That's the whole premise of the post.

> his primary gripe specifically as a library developer - is that the knowledge base for library developers is very sparse.

No, it isn't.

It's the first of his 5 gripes. There's only 5 of them and they're titled. A few of the other gripes also mention the lack of documentation, so it definitely appears to be his main gripe.

I agree with GP, you don't seem to have read his article and knee jerked a reply.

And all you have to do to prove your point is to link some great documentation explaining how to make complex types for libraries and how to test them.

Which you haven't.

What I said is that I call bullshit on his 5 points. None of them are valid and they are just opinions of a developer who hasn't put the effort in and isn't providing concrete examples of what is actually wrong. I actually find it difficult to understand why this is even on the front page of HN, maybe it is a slow news day?

I feel that my point is proven with a successful multiple year open source Typescript library.

Great documentation? That's subjective. I'd start with a deep reading of the official docs as they are quite good: https://www.typescriptlang.org/docs/

> I feel that my point is proven with a successful multiple year open source Typescript library.

That only proves that it's possible to do, not that the language facilitates it or that certain modifications to the language/ecosystem wouldn't greatly improve the process. The point of the article is the latter, not the former.

> What I said is that I call bullshit on his 5 points.

No. What you said was:

> In other words, I call bullshit on this entire blog post. Ignore it.

True, I paraphrased what I said so that matt could hopefully understand a bit better that I did indeed read the blog post. I want my 10 minutes back please.

to be fair to me, i did read them....i just don't care that much.

There should be another guideline about commenting on whether someone read the guidelines.

Yes, probably. Then again there is already a downvote for comments that "don't contribute to the discussion", so that probably covers it.

I expected to be downvoted with the rest of the thread, but somehow got flagged. That's a first.