I've been a big TypeScript hater in the past, but I have to admit it works well when JavaScript is the _only_ language you're dealing with. You get to just turn off your brain and let the type checker find all the undefineds, nulls, etc. But as soon as you have to convert to and from HTML/CSS/SQL it definitely becomes a big pain.
Discussion
Loading...
Discussion
I've been a big TypeScript hater in the past, but I have to admit it works well when JavaScript is the _only_ language you're dealing with. You get to just turn off your brain and let the type checker find all the undefineds, nulls, etc. But as soon as you have to convert to and from HTML/CSS/SQL it definitely becomes a big pain.
@nolan Hello my friend please help me share and donate if you can please read my posts,🙏🤍
@nolan Hello my friend please read my posts please share and donate Im really need your support🙏💔🥺
@nolan Not a problem if you're just writing JSX.
@nolan even the DOM isn't too bad if you have #TypeScript 's `lib` set as expected: https://www.typescriptlang.org/tsconfig/#lib
The default annotations for `JSON.parse()`, `fetch()` say they return `any`, and really any place marked as `any` (or using human-thinks-they-know-best `as MyType` coercions) tends to me what trips me up in practice
I'd love a "greenfield" setting that removes `any` and untyped JavaScript support from TypeScript completely, forcing me to do runtime type-checks instead of making false assumptions
bonfire.cafe
A space for Bonfire maintainers and contributors to communicate
Automatic federation enabled