[keawade]

I disagree that TypeScript comes with only a marginal upside. In my experience TypeScript projects are much more approachable for contributors.

For example, I once was debugging an issue in a JS framework and while I knew what was wrong and where I could fix it I didn’t have any idea what existing tools I had available in that context to fix it. Having type definitions would have made that work much simpler by increasing the accessibility of the code base.

It’s experiences like this that have convinced me that if I’m writing code that any one will possibly read or need to modify later (including if it is just me) then I should be writing TypeScript instead of JavaScript. Or, more generally, that it should be typed.

[datavirtue]

Raw JavaScript in any production app is an abomination. Constant issues because one of the variables had a errant character. Countless bugs because of the same or it not being defined. On top of all that how in the hell am I supposed to know what a parameter or return value is supposed to look like? I have other things to worry about. I think these type annotations would make everyone happy. The IDE can navigate and inform but the objects will still need to be defined somewhere. I assume we can define a custom type with these annotations?

[shadowgovt]

You and OP are both right, because it really depends on what you're doing.

At the scale I operate, it would be corporate suicide to try and write this code in straight JavaScript without type support. But for smaller teams, more focused teams, and teams that use a heavy testing discipline or enforced naming conventions that supplement the lack of static typing, it's not a problem.

[lostcolony]

Your basic disagreement here feels like it would be obviated by the parents "I hope this makes its way into the ECMAscript spec"? I.e., you would get typing without any of the tooling Typescript requires; the parent's point was JS + typing would be a pure benefit compared to Typescript, and you've said nothing to disagree with that.

So while you technically are disagreeing with the parent, it's on the smallest of points, and completely disregarding the main one the parent offered (which, fair enough, but wanted to point that out)

[pwdisswordfish9]

What does "while I knew what was wrong and where I could fix it I didn’t have any idea what existing tools I had available in that context to fix it" mean?

[NoWizards]

I couldn't disagree more with you... All i see when working with different levels of experienced contributors is param:any any[]. Even more when you want to interact directly with DOM instead of using an opinionated framework.

[j-krieger]

You‘re blaming the active misuse of a tool on the tool itself.

[EMM_386]

This is why "no-explicit-any" should be enforced in every project.

https://github.com/typescript-eslint/typescript-eslint/blob/...

[david422]

This is either just code that is too complicated or devs that aren't doing a good job of type hinting.

Everytime there is an any, it means that each developer reading or modifying this code has to find it out for themselves - every single time. Why not just type hint it correctly in the first place.