Earlier quoted context omitted.
As others have pointed out, they're not really "strings" per se, or at least can be a lot stricter than a string might seem when used right. We use that constantly for useful things. The bigger reason why it is this way is to ensure you can write type annotations for stringly-typed Javascript. While Typescript is it's own thing really at this point, it still is very focused on making it possible to type-annotate JS c…
In a similar case TypeScript even knows the signature of the event handler for addEventListener, and what type of Element document.createElement('div') returns. Someone even built typings for querySelector that parse the selector and returns the correct element type. In general, however, I still think APIs written in TypeScript first are a lot cleaner type-wise than typings retrofitted onto a JS API. And having TypeS…
Oh absolutely. Writing JS-first just seems like a lost cause. But there are still enough internal libraries and such written in very JS JS floating around that I come across at work that we need to interface with that I appreciate how much effort the TS team still puts into making sure I can drag those libs kicking and screaming into 2022.