DEV Community

Discussion on: The reasons I don't use Typescript

Collapse
jonosellier profile image
jonosellier

I'm not entirely sure why you hate TypeScript so much as all JavaScript is valid TypeScript. I will admit some exceptions apply with common JavaScript like document.querySelector('a.link').style.color throwing an error but this is actually just JavaScript bullshitery that we have all gotten away with since querySelector does not actually return an HTMLElement, it returns an Element but most of the time, we can get away with this kind of jank. The correct way to assert that the element returned is an HTMLElement is simply using as HTMLElement. It's clear to the compiler, other developers, and yourself that you are not manipulating an SVGElement which will have different props.

Can you provide me some code you had to tell TypeScript it was wrong about? If it's a type issue, assert the intended type with as.

Collapse
jfbrennan profile image
Jordan Brennan Author • Edited on

I wouldn't say I hate TS, I'm just not a fan for the reasons I shared and other minor points. I do kind of hate Java though!

The last thing I remember telling TS it was wrong about was an object I added to window that contained some core data bootstrapped from the server. I like to avoid extra API calls on page load when it's possible to grab that same data cached server-side, bootstrap it, and then read that into my app when it initializes. TS was complaining and so I ts-ignore'd. Shortly after that I removed TS from the codebase and moved on with life. The only prod bug since has been a goofed up sorting algo, which of course TS would not have helped with.

Collapse
jonosellier profile image
jonosellier • Edited on

Okay that's fair that TypeScript would throw an error, however. I am not saying that you were wrong to ts-ignore but that is never the right* way to do something. In TS, you can extend an object by doing the following:

interface Window {
  prop: any
} 
Enter fullscreen mode Exit fullscreen mode

EDIT:

  • Right as in the way TS intended, there is no objective right way to write something in general.
Thread Thread
jfbrennan profile image
Jordan Brennan Author

True enough, but that’s also an example of my “TypeScript begets TypeScript” complaint.

Thread Thread
jonosellier profile image
jonosellier

The whole point is type-safety which means you have to be explicit. That being said, I fully understand the frustration that you can't just drop in some TS while leaving other parts as just JS. Thanks for taking the time to explain your views, it's always interesting to hear why people make the choices they make, even if I do not fully agree with them (but I develop Angular for a living so I am well-acquainted with TS and have learned to love it).

Collapse
borobudur01 profile image
borobudur01

"I'm not entirely sure why you hate TypeScript so much as all JavaScript is valid TypeScript",.. "The correct way is"..., "Can you provide me some code you had to tell TypeScript it was wrong"...
You really can't see the point of this article.

Collapse
jonosellier profile image
jonosellier

Addressing "You really can't see the point of this article":

I definitely can, he chooses to not use TypeScript and made some examples that seemed like a simple fix based on what he said. I'd go on and explain the reason why tonnes of people choose it over JS but we already know them. Whether or not he chooses to fully embrace typescript is fine but it comes down to a personal choice and like/dislike. Every issue he mentioned can be easily solved with more TS (Which he does not want to write, because personal choice), eg:

The issue where an optional prop was not being passed to the application but the application thought it existed: The fix? Slap a ? on optional props and use ?. to access them with some fallback. In JS the outcome would be the same (assuming babel) except they wouldn't have relied on the type checking to do their dirty work and they might have caught it earlier. Or they might not have... But it's not fair to say TS caused this when the object was improperly defined.

Addressing "The correct way is..." snark

"This hammer is useless"
I make this in jest, relax
If you're unaware of how you can elegantly solve an issue (trivially too, IMO) then the language will feel janky.

Addressing "Can you provide me some code you had to tell TypeScript it was wrong"

Genuine curiosity. I was expecting a language bug or some edge case I would keep an eye out for as a developer. It's just as important to know what something can't do well as it is to know what it can do well.