6 ms·

I think valid points are bad about typescript being bad, like without a real debugger it's going to be hard to debug anything. But I firmly disagree with how t

I think valid points are bad about typescript being bad, like without a real debugger it's going to be hard to debug anything. But I firmly disagree with how the article begins. > In effect, we are shifting complexity from end-developers to library developers. That is the whole point in creating a library. To hide complexity in a nice easy to use interface/API.

Smaug123 4y ago
Yeah, the author appears to be complaining that Typescript is forcing them to stay honest even while they perform Mad Shenanigans like dynamically constructing types :/ if TS didn't check it, it would be down to your users to report the bugs in production!
- franciscop 4y ago
  I don't think it's very fair. As a library developer myself, you try to make you user lives easier, which implies being flexible in what you accept when possible. A couple of examples I struggled with recently: Documenting https://umbrellajs.com/documentation#addclass https://umbrellajs.com/documentation#addclass. The way I documented it is by opening with a code snippet with many of the possible options (which can also be combined!): .addClass('name1') .addClass('name1 name2 nameN') .addClass('name1,name2,nameN') .addClass('name1', 'name2', 'nameN') .addClass(['name1', 'name2', 'nameN']) .addClass(['name1', 'name2'], ['name3'], ['nameN']) .addClass(function(node, i){ return 'name1'; }) .addClass(function(){ return 'name1'; }, function(){ return 'name2'; }) This is pretty easy to do in plain JS, and of course if you are writing code and using it you just read the first 1-4 lines and know what to do for 99% of the cases, while also noticing there's few "advanced/flexible" ways of using it. How would you even do that in TS? Then there's a classic initializer in JS that works like this: function myLibrary(arg) { if (!(this instanceof myLibrary)) { return new myLibrary(arg); } ... } This is very useful to create a library like jquery that you can initialize straight away without needing (but also being able to use) the `new` keyword, just calling it like a function and always ensures it returns an instance. To this day I haven't found a way of doing this in TS.
  - LelouBil 4y ago
    A lot of times making the user's life easier is about having a single correct way to do something.
    - dogweather 4y ago
      It's true. A type specification also has the role of documentation, quickly telling the user how to use the thing. A ridiculous typespec - to support an "easier" API - has the effect of making it impenetrable.
  - Smaug123 4y ago
    There's "be flexible in what you accept", and then there's… "take a comma-separated string which you could parse into your arguments" :)
    - vbezhenar 4y ago
      May be I want to pass JS string to be eval-ed. Flexible, huh.
  - HideousKojima 4y ago
    >To this day I haven't found a way of doing this in TS. Just make a static method that does initialization if needed and returns a new instance? https://www.typescripttutorial.net/typescript-tutorial/typescript-static-methods-and-properties/ https://www.typescripttutorial.net/typescript-tutorial/types... I'm trying to not be too hard on people as I read this thread, but it's baffling to me that web devs are getting filtered by features that have been in other languages since the 80's and 90's.
  - phailhaus 4y ago
    declare function addClass(...classes: (string | string[] | (() => string))[]): void; It's pretty straightforward in Typescript. And when you go to implement it, tsc will make sure you cover all the types your function claims to support. > This is very useful to create a library like jquery that you can initialize straight away without needing (but also being able to use) the `new` keyword, just calling it like a function and always ensures it returns an instance. Avoiding having to type "new" is not a very compelling reason to avoid Typescript, especially because Typescript won't let you make the mistake of calling the function without it. It's just not a problem.
qudat 4y ago
Thanks for reading the article! > That is the whole point in creating a library. To hide complexity in a nice easy to use interface/API. I think that's a fair point, but generating types that satisfy all use cases is very challenging to get right -- disproportionately so. I could see a world where -- without proper tooling and growing complexity -- typescript libraries becomes so difficult to maintain that people give up or burn out. Maybe that's a pessimistic outlook but I already feel that way some days.
- Chabsff 4y ago
  In strongly-typed programming languages, which includes Typescript, figuring out the types *of the interface* is not something that's done after the fact. `@types/*` is an exceptional project meant to back-port JS libraries to TypeScript, but that's the exception, not the rule. If you write a library in TypeScript, determining what types are present as part of the interface is one of the very first thing that should be done.
  - mrkeen 4y ago
    > In strongly-typed programming languages, which includes Typescript, figuring out the types is not something that's done after the fact. Too broad a statement. There's loads of value in having a compiler figure out types for you after/when you write the code.
    - Chabsff 4y ago
      Hard disagree as far as the portions of it that are part of the user-facing public interface are concerned. But granted, as a general rule you are correct. I was referring specifically to API interfaces.
    - overgard 4y ago
      If you're talking about type-inference, sure, I guess it's fine. If you're talking about figuring out what types you're going to accept, you should absolutely be defining that on your own up-front. If you don't even know what your types are how is an end user going to figure it out?
heisenbit 4y ago
Often libraries are bootstrapped from application code. Having a step function in complexity is not helpful in fostering an ecosystem with a broad range of maturity.
johnfn 4y ago
> That is the whole point in creating a library. To hide complexity in a nice easy to use interface/API. Totally agree. Minor ergonomic changes in a library have a wildly disproportionate impact on developers. If I save a developer 5 seconds with a better type, and I have 1000 developers using my library, that's 5,000 seconds I just saved - and that's assuming they only ever use my type a single time! With this in mind, I'm totally OK paying a tax on making libraries a bit harder to write, if it means that the benefits of stronger types fan out. After all, writing that type could take 4,995 seconds for me to write and still be a net positive. And honestly, 5 seconds isn't even close to accurate. Good type definitions have saved me hours.

Smaug123 4y ago

Yeah, the author appears to be complaining that Typescript is forcing them to stay honest even while they perform Mad Shenanigans like dynamically constructing types :/ if TS didn't check it, it would be down to your users to report the bugs in production!

franciscop 4y ago
I don't think it's very fair. As a library developer myself, you try to make you user lives easier, which implies being flexible in what you accept when possible. A couple of examples I struggled with recently: Documenting https://umbrellajs.com/documentation#addclass https://umbrellajs.com/documentation#addclass. The way I documented it is by opening with a code snippet with many of the possible options (which can also be combined!): .addClass('name1') .addClass('name1 name2 nameN') .addClass('name1,name2,nameN') .addClass('name1', 'name2', 'nameN') .addClass(['name1', 'name2', 'nameN']) .addClass(['name1', 'name2'], ['name3'], ['nameN']) .addClass(function(node, i){ return 'name1'; }) .addClass(function(){ return 'name1'; }, function(){ return 'name2'; }) This is pretty easy to do in plain JS, and of course if you are writing code and using it you just read the first 1-4 lines and know what to do for 99% of the cases, while also noticing there's few "advanced/flexible" ways of using it. How would you even do that in TS? Then there's a classic initializer in JS that works like this: function myLibrary(arg) { if (!(this instanceof myLibrary)) { return new myLibrary(arg); } ... } This is very useful to create a library like jquery that you can initialize straight away without needing (but also being able to use) the `new` keyword, just calling it like a function and always ensures it returns an instance. To this day I haven't found a way of doing this in TS.
- LelouBil 4y ago
  A lot of times making the user's life easier is about having a single correct way to do something.
  - dogweather 4y ago
    It's true. A type specification also has the role of documentation, quickly telling the user how to use the thing. A ridiculous typespec - to support an "easier" API - has the effect of making it impenetrable.
- Smaug123 4y ago
  There's "be flexible in what you accept", and then there's… "take a comma-separated string which you could parse into your arguments" :)
  - vbezhenar 4y ago
    May be I want to pass JS string to be eval-ed. Flexible, huh.
- HideousKojima 4y ago
  >To this day I haven't found a way of doing this in TS. Just make a static method that does initialization if needed and returns a new instance? https://www.typescripttutorial.net/typescript-tutorial/typescript-static-methods-and-properties/ https://www.typescripttutorial.net/typescript-tutorial/types... I'm trying to not be too hard on people as I read this thread, but it's baffling to me that web devs are getting filtered by features that have been in other languages since the 80's and 90's.
- phailhaus 4y ago
  declare function addClass(...classes: (string | string[] | (() => string))[]): void; It's pretty straightforward in Typescript. And when you go to implement it, tsc will make sure you cover all the types your function claims to support. > This is very useful to create a library like jquery that you can initialize straight away without needing (but also being able to use) the `new` keyword, just calling it like a function and always ensures it returns an instance. Avoiding having to type "new" is not a very compelling reason to avoid Typescript, especially because Typescript won't let you make the mistake of calling the function without it. It's just not a problem.

qudat 4y ago

Thanks for reading the article! > That is the whole point in creating a library. To hide complexity in a nice easy to use interface/API. I think that's a fair point, but generating types that satisfy all use cases is very challenging to get right -- disproportionately so. I could see a world where -- without proper tooling and growing complexity -- typescript libraries becomes so difficult to maintain that people give up or burn out. Maybe that's a pessimistic outlook but I already feel that way some days.

Chabsff 4y ago
In strongly-typed programming languages, which includes Typescript, figuring out the types *of the interface* is not something that's done after the fact. `@types/*` is an exceptional project meant to back-port JS libraries to TypeScript, but that's the exception, not the rule. If you write a library in TypeScript, determining what types are present as part of the interface is one of the very first thing that should be done.
- mrkeen 4y ago
  > In strongly-typed programming languages, which includes Typescript, figuring out the types is not something that's done after the fact. Too broad a statement. There's loads of value in having a compiler figure out types for you after/when you write the code.
  - Chabsff 4y ago
    Hard disagree as far as the portions of it that are part of the user-facing public interface are concerned. But granted, as a general rule you are correct. I was referring specifically to API interfaces.
  - overgard 4y ago
    If you're talking about type-inference, sure, I guess it's fine. If you're talking about figuring out what types you're going to accept, you should absolutely be defining that on your own up-front. If you don't even know what your types are how is an end user going to figure it out?

heisenbit 4y ago

Often libraries are bootstrapped from application code. Having a step function in complexity is not helpful in fostering an ecosystem with a broad range of maturity.

johnfn 4y ago

> That is the whole point in creating a library. To hide complexity in a nice easy to use interface/API. Totally agree. Minor ergonomic changes in a library have a wildly disproportionate impact on developers. If I save a developer 5 seconds with a better type, and I have 1000 developers using my library, that's 5,000 seconds I just saved - and that's assuming they only ever use my type a single time! With this in mind, I'm totally OK paying a tax on making libraries a bit harder to write, if it means that the benefits of stronger types fan out. After all, writing that type could take 4,995 seconds for me to write and still be a net positive. And honestly, 5 seconds isn't even close to accurate. Good type definitions have saved me hours.