DEV Community

Discussion on: Pitch me on TypeScript

Collapse
 
thejaredwilcurt profile image
The Jared Wilcurt

Everything TS is trying to do is done better with eslint-plugin-jsdoc. It lets you document the types, and as you write your code your editor will do the exact same thing it would with TS types. However on hover, it doesn't just tell you the name and type of a variable, it also gives you the context of what it is, and why it exists (the stuff that actually matters).

Cons of TS:

  • SLOW: TS is notoriously slow. On any project of decent size expect to save one file, wait 20s seconds for the entire project to compile, then the page refreshes. It removes you from the flow of coding. Inexcusable experience.
    • JSDocs - No impact on speed, other than the time it takes to lint, which can be done in the background by your editor and highlighted in your code in real-time.
  • Learning curve: Everyone knows JS, only some people know TS.
    • JSDocs - No learning curve just do eslint --fix and it starts writing the comment block for you. You fill in the details, run eslint --fix again and it corrects your formatting and tells you what you missed. Level of enforcement is up to you.
  • per-character annoyance: If you type a single thing wrong, your compiler is mad.
    • JSDocs - per PR annoyance: if you want to wait until the end of your PR to do all the linting before it gets merged, that's fine, it's just linting.

Pros of both:

  • autocomplete (identical)
  • warning of potential errors and mismatches between expected types (identical)
  • code quality enforcement (eslint does a better job)
  • documentation (jsdocs does a better job)
  • being trendy bullshit (actually jsdocs doesn't do this one, hey TS is finally better at something!)

Problems of both:

Editors are using the TS engine to give you hints/warnings, and honestly, it's pretty dumb. Over-reliance on it causes more errors than just not using anything like this at all. I have seen people write up interfaces for 3rd party API's and be done. No safety checks. Like..... they genuinely don't know why that's really bad. There are also "runtime bombs" where your code will break in production and the compile time checks aren't smart enough to figure that out.

Neither of them are good for runtime checking. See: dev.to/thejaredwilcurt/comment/1212g