Static type checking does nothing for "type safety" in runtime [...] Static type checking reduces some errors
Why are you utilizing an absolute if you know it does do something, and you find that something valuable enough to us static type checking?
I'm not mentioning Typescript because your original statements seem very specific to static typing. That there where other options to Typescript were made in point 1 and I expected that was a different issue you had.
It's not either/or. Check/annotate your types statically, but don't pretend (as TS users all too often do, and as you seemed to indicate earlier in the thread by saying you didn't want to deal with dynamic types) that you don't need to check in runtime and that JS doesn't already offer the tools to do so.
That "does do something" is easily solved for with just comments (that TS advocates tend to label "a code smell," oblivious to the irony of adding tons of nonstandard syntax instead) to document functions and their types, which has been around in the vanilla JS world since long before TS and other "superset" "solutions" to typing, and ESLint (which you should be using in a modern JS development toolkit anyway).
The "other option" I'm recommending is the one which alters JavaScript the least (i.e. not at all, rather just implementing good authoring practices).
I AM focusing on TypeScript (because your article is in response to one against TypeScript and) precisely because its supporters act as if it solves things which are impossible in vanilla JavaScript (I've shown a million times in this thread that they're not) and that their resulting code is safer and better organized. It's not, and I'd invite them to see the long-term (as in multi-year) effects on code "organization" vs a similar well-commented (and still self-documenting) JS codebase. In addition to the far fewer LoC, the JS codebase will benefit from devoting the hours (amounting to months in a multi-year project) TS devs would have wasted on satisfying tsc (just to get their code to run) on actually validating in runtime (again, necessary with or without TS), with time left over to spare.
I don't have the background on JS or TS to grasp gaps I expect to be closed with types, my little experience suggests TS does not go far enough. And for that I can believe TS is not good.
Basically what you say here I have no argument against, but maybe some semantics.
Two parts you emphasize are "vanilla javascript" and "standard javascript".
And while I agree that Typescript is not standard/vanilla javascript, I think you might be conserned more on the native browser support.
Personally I would not consider comment annotation as vanilla javascript. As to if it is standard, I would need to do a in depth analysis of JS projects I neither have time or access to.
Linters are great and I hope that any project using vanilla JS is making use of both of these techniques.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Why are you utilizing an absolute if you know it does do something, and you find that something valuable enough to us static type checking?
I'm not mentioning Typescript because your original statements seem very specific to static typing. That there where other options to Typescript were made in point 1 and I expected that was a different issue you had.
It's not either/or. Check/annotate your types statically, but don't pretend (as TS users all too often do, and as you seemed to indicate earlier in the thread by saying you didn't want to deal with dynamic types) that you don't need to check in runtime and that JS doesn't already offer the tools to do so.
That "does do something" is easily solved for with just comments (that TS advocates tend to label "a code smell," oblivious to the irony of adding tons of nonstandard syntax instead) to document functions and their types, which has been around in the vanilla JS world since long before TS and other "superset" "solutions" to typing, and ESLint (which you should be using in a modern JS development toolkit anyway).
The "other option" I'm recommending is the one which alters JavaScript the least (i.e. not at all, rather just implementing good authoring practices).
I AM focusing on TypeScript (because your article is in response to one against TypeScript and) precisely because its supporters act as if it solves things which are impossible in vanilla JavaScript (I've shown a million times in this thread that they're not) and that their resulting code is safer and better organized. It's not, and I'd invite them to see the long-term (as in multi-year) effects on code "organization" vs a similar well-commented (and still self-documenting) JS codebase. In addition to the far fewer LoC, the JS codebase will benefit from devoting the hours (amounting to months in a multi-year project) TS devs would have wasted on satisfying tsc (just to get their code to run) on actually validating in runtime (again, necessary with or without TS), with time left over to spare.
I don't have the background on JS or TS to grasp gaps I expect to be closed with types, my little experience suggests TS does not go far enough. And for that I can believe TS is not good.
Basically what you say here I have no argument against, but maybe some semantics.
Two parts you emphasize are "vanilla javascript" and "standard javascript".
And while I agree that Typescript is not standard/vanilla javascript, I think you might be conserned more on the native browser support.
Personally I would not consider comment annotation as vanilla javascript. As to if it is standard, I would need to do a in depth analysis of JS projects I neither have time or access to.
Linters are great and I hope that any project using vanilla JS is making use of both of these techniques.