4 ms·

"JS _is_ a very dynamic language, library design reflects that" I would argue it should not. If your API cannot be well expressed in the Typescript type system

"JS _is_ a very dynamic language, library design reflects that" I would argue it should not. If your API cannot be well expressed in the Typescript type system, it is your API that should change.

cogman10 4y ago
Yup. Especially since types are documentation. If you are using some meta dynamic type garbage, then I as a user of the API am left to wonder "Ok, this takes <U, K extends keyof U>... WTF is it expecting?" This isn't to say that sort of thing is ALWAYS wrong, but rather it should be the exception and not the rule. You do types because constraints make code clearer. By having a BF compiler in the middle of your template definition, you've defeated the types and you might as well put an `any` there with docs that say "here there be dragons!"
hmsimha 4y ago
This is all well and good until you have to deal with other code and other APIs in your library (results from network requests, localstorage, untyped javascript libraries, etc.)
naet 4y ago
I'd rather not warp my whole project around a typing system if I don't need to. I also might not be the owner of every API I need to consume... I think TS is great in certain cases- I love being able to get intellisense info from TS. When I download a new library and I get those helpful hints built right in from the libraries TS adoption, I love it. Typescript in this instance is reducing friction in my development workflow. In my day job I work at an agency where we rapidly deliver a lot of new web properties. I have used Typescript on projects when it was a client requirement, but in our environment using Typescript generally feels like it overall adds friction and time to the project. Some team member inevitably gets stuck spending a bunch of extra time working with TS stuff: setting up the project with proper rules, writing some complex interface to deal with some random API we are either consuming or creating ourselves (in which case it is usually under rapid prototype development and needs to be updated constantly), etc. I'm sure it is very helpful when working at scale with tons of developers on a highly stable and established project, but in my opinion it isn't generally applicable to every web property that it would be better on Typescript; it really depends on the scale of the project and the scale of the team maintaining it.
- crabmusket 4y ago
  > I'd rather not warp my whole project around a typing system if I don't need to. This sounds to me like MongoDB advocates like "psh! who needs a schema! don't slow me down, I'll just dump JSON into the database however I like." The types exist whether you write them down or not. I agree with you that TS might not be great for everyone and every use case. But maybe you should just use `any` some more!
  - jd_mongodb 4y ago
    Every field in a MongoDB document (we encoded documents in BSON at the driver level) is typed and you can apply a schema to any collection if you choose to do so.
deleted 4y ago
[deleted]

"JS _is_ a very dynamic language, library design reflects that" I would argue it should not. If your API cannot be well expressed in the Typescript type system, it is your API that should change.

cogman10 4y ago

Yup. Especially since types are documentation. If you are using some meta dynamic type garbage, then I as a user of the API am left to wonder "Ok, this takes <U, K extends keyof U>... WTF is it expecting?" This isn't to say that sort of thing is ALWAYS wrong, but rather it should be the exception and not the rule. You do types because constraints make code clearer. By having a BF compiler in the middle of your template definition, you've defeated the types and you might as well put an `any` there with docs that say "here there be dragons!"

hmsimha 4y ago

This is all well and good until you have to deal with other code and other APIs in your library (results from network requests, localstorage, untyped javascript libraries, etc.)

naet 4y ago

I'd rather not warp my whole project around a typing system if I don't need to. I also might not be the owner of every API I need to consume... I think TS is great in certain cases- I love being able to get intellisense info from TS. When I download a new library and I get those helpful hints built right in from the libraries TS adoption, I love it. Typescript in this instance is reducing friction in my development workflow. In my day job I work at an agency where we rapidly deliver a lot of new web properties. I have used Typescript on projects when it was a client requirement, but in our environment using Typescript generally feels like it overall adds friction and time to the project. Some team member inevitably gets stuck spending a bunch of extra time working with TS stuff: setting up the project with proper rules, writing some complex interface to deal with some random API we are either consuming or creating ourselves (in which case it is usually under rapid prototype development and needs to be updated constantly), etc. I'm sure it is very helpful when working at scale with tons of developers on a highly stable and established project, but in my opinion it isn't generally applicable to every web property that it would be better on Typescript; it really depends on the scale of the project and the scale of the team maintaining it.

crabmusket 4y ago
> I'd rather not warp my whole project around a typing system if I don't need to. This sounds to me like MongoDB advocates like "psh! who needs a schema! don't slow me down, I'll just dump JSON into the database however I like." The types exist whether you write them down or not. I agree with you that TS might not be great for everyone and every use case. But maybe you should just use `any` some more!
- jd_mongodb 4y ago
  Every field in a MongoDB document (we encoded documents in BSON at the driver level) is typed and you can apply a schema to any collection if you choose to do so.

deleted 4y ago

[deleted]