The multiple 800 pound gorillas that I have yet to see TypeScript supporters adequately address are:
You don't need TypeScript (or any other "superset") to check JavaScript types statically. JSDoc @param/@typedef/@type/@return/etc. annotation, combined with ESLint (or VS Code set to check JS) works just fine. You don't even need to install JSDoc (though you get auto-generated code docs if you do) - it's just a docgen for a function/class comment syntax/doc paradigm that has been standardized across multiple languages.
Static type checking does nothing for "type safety" in runtime, creating a false sense of security when you still need to validate (ideally on frontend for user experience as well as backend for data security/integrity) in runtime.
TypeScript still transpiles to loosely, dynamically typed JS. Your struggles to appease tsc are moot.
Junior developers are still trying to grok JS qua JS - i.e. loosely, dynamically typed. Not only is point 2 a major issue in this regard, but so are the mountains of extra learning curve you're piling on them... And then there's the most damning cop-out of TS not named "any": "typeof" (which is completely different in a TS context despite the same exact keyword existing in JS, with either context potentially occurring in a .ts/.tsx file. Super fun for someone still just trying to learn JS.
Assumption that those criticizing TS are inferior developers who just had one or two bad experiences with it, and that there's no possibility whatsoever that the person criticizing TS might have used it longer than you have and seen its long term negative effects on complex, real world projects.
I am not familiar with the TS alternatives, usually the issue I read about equally apply to introducing static typing in any form, see your 2, 3, and 5.
I'm going to first need to restate what I think you are getting at.
It is important to do runtime testing for other important system failures, type issues will be identified during this effort.
Is that accurate?
Thus static type checks are redundant.
Is that also where you are headed?
.3. This is true in all static type languages, the types are a compile time construct. The TS to JS adds the complexity that while working in Typescript you may actually be working with untyped code and you've only declared expectation on that untyped code.
This is much like passing void* in C. The type system is subverted and the compiler will assume you know the type. It is not like C in that JS actually has runtime type information and you will only have corrupt data due to JS loose typing around strings and numbers.
.4. Why are you using Typescript and having your junior devs learning all the dynamic, loose typing. Teach them to stay in the typed world.
I'm actually being overly harsh here, I don't think Typescript sufficiently separates the two words so that you can avoid the other, this is likely the root cause of my mixed feelings. I need to learn how to get TS to help me rather than it providing guarantee I can use.
.5. If I utilize points 1, 2, 3 and 4 as a base. Point 4 is the only one that I would say hints at long term negative effects. Otherwise these issues read more like
'Why utilize Typescript when there are better alternatives. We don't use those because static typing is pointless.'
Put in point 5 and it is topped off with 'and you don't believe me even though I've used Typescript longer than you.'
I think static type systems have proven themselves over and over again. But we also have sufficient evidence that systems can be built without static typing with stability and reliability that an argument against static typing is strong.
As someone whose job it is to assure that stability, I don't want to be doing it for dynamic languages.
I never said not to check types statically. Never said static type checks are redundant. I said you don't need anything but JavaScript and tooling you're already likely to use with it (with or without TS) for that. And that you still need to learn the dynamic type system JS already offers to actually safeguard against wrong types at runtime. TS adds zero benefit, and a great deal of burden, for things you already can do without it (and still need to do with or without).
Your response to point 5, in the context of your other interpretations of what I actually said, is "You still don't really understand TypeScript, no matter how long you've used it. How could you not accept its greatness and inevitability if you did?"
Your response to 4 ignores 3. They can't avoid dynamic typing. They're transpiling to JS. It also, as is far too common among TS fans, ignores what junior devs are already expected to learn (and anybody who tells them to ignore dynamic typing needs to go back and re-learn JS - sans TS - themselves).
Your responses to 4 and 3 prove my point about 2.
I don't want to be doing it for dynamic languages.
Then I guess you'd better start doing all of your frontend in WASM (loaded with plain ol' dynamic JS, with or without TS, of course).
My intention for my summary of 5 was thinking it might help you see how the sum of your statements come together.
Thank you yor try to do the same, though I need some help connecting the translation. Namely my mistake seems to primarily stem from the assumption that you are not in favor of types.
I would say this assumption mainly stems from item 2, which I explicitly asked for help in understanding. Could I get further clarification on how that point isn't general to all type systems mentioned?
I'm against butchering JavaScript to behave like another language through the use of a "superset" (TypeScript, though I have the same issue with CoffeeScript, ClojureScript, etc.) because someone decided that, rather than take the time to learn JavaScript qua JavaScript, one should impose one's personal language preferences on all other devs involved.
In his original edition of You Don't Know JS, Kyle Simpson said two very important things when it comes to JavaScript:
They're not "bad parts" or "weird parts," just JavaScript parts. Learn the what and why of these parts, not just the "good parts" (referring to the books JavaScript: The [Good/Bad/Weird] Parts)
If you try to hack around or avoid these key characteristics of JavaScript (primarily referring, at the time, to the "object oriented JavaScript" craze of the early-mid last decade), you're setting yourself up for failure.
To be clear, what I'm saying is:
Yes, you should check types at "compile" time, but you don't need anything other than vanilla JS, long-standardized comment syntax, and ESLint (and/or VS Code Intellisense set to check JS), to do that - none of the extra, bloated, nonstandard syntax or tooling of TS is necessary.
That still doesn't save you from from needing to understand, account for, and utilize dynamic typing in JavaScript at runtime, whether or not you're writing it as TypeScript (though if you are, you're piling on a ton of unnecessary stuff in avoidance the core JS stuff you still need to learn, like it or not).
This does not help me understand your second point, which I'm still interested if I was able to extrapolate the meaning of correctly or not.
Thank you for providing a clearer position.
I think it is interesting that you don't like that someone is trying to make Javascript usable for themselves, yet are aware that the environment does not allow for an alternative, WebASM still has JS boot straps and is a much more recent option (not fully ready) compared to all previous attempts.
Static type checking does nothing for "type safety" in runtime, creating a false sense of security when you still need to validate (ideally on frontend for user experience as well as backend for data security/integrity) in runtime.
I'm not sure exactly how I can further clarify this, other than to say "yes, you should check types statically, but you don't need TypeScript to do so" and "but you still need to account for runtime, which static type checking will never solve, and vanilla JavaScript already provides tools for this if you bother to learn its dynamic type system instead of acting like a static checking superset eliminates this need."
Making something useful for yourself is one thing. Imposing it on others and acting like it's the only way is something entirely different. Just look at all the demands on library maintainers to add types to their libraries, when the maintainers themselves haven't expressed any desire to use (let alone maintain additional support for) TypeScript.
Static type checking does nothing for "type safety" in runtime [...] yes, you should check types statically
I think I'm having a hard time with these two statements, why would you believe we should check types statically if at the same time you believe they do nothing for runtime. I think we both agree that the only thing that matters is runtime behavior. Everything else is done in support of getting the runtime portion correct.
I might be in agreement on pushing you desire for Typescript onto 3rd party libraries. I feel as though our discussion is more focused on why Typescript is or is not valuable and why it is winning the static typing challenge of javascript.
Static type checking reduces some errors (not as many as TS proponents would have you believe), BUT you don't need TypeScript to check them statically in JavaScript, and completely altering the language is pointless if you don't need to.
Static type checking isn't panacea, and you still need to account for runtime. Vanilla JavaScript already provides the tools for this.
In either case, TypeScript is a pointless "solution."
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.
The multiple 800 pound gorillas that I have yet to see TypeScript supporters adequately address are:
@param/@typedef/@type/@return/etc. annotation, combined with ESLint (or VS Code set to check JS) works just fine. You don't even need to install JSDoc (though you get auto-generated code docs if you do) - it's just a docgen for a function/class comment syntax/doc paradigm that has been standardized across multiple languages.I am not familiar with the TS alternatives, usually the issue I read about equally apply to introducing static typing in any form, see your 2, 3, and 5.
I'm going to first need to restate what I think you are getting at.
It is important to do runtime testing for other important system failures, type issues will be identified during this effort.
Is that accurate?
Thus static type checks are redundant.
Is that also where you are headed?
.3. This is true in all static type languages, the types are a compile time construct. The TS to JS adds the complexity that while working in Typescript you may actually be working with untyped code and you've only declared expectation on that untyped code.
This is much like passing void* in C. The type system is subverted and the compiler will assume you know the type. It is not like C in that JS actually has runtime type information and you will only have corrupt data due to JS loose typing around strings and numbers.
.4. Why are you using Typescript and having your junior devs learning all the dynamic, loose typing. Teach them to stay in the typed world.
I'm actually being overly harsh here, I don't think Typescript sufficiently separates the two words so that you can avoid the other, this is likely the root cause of my mixed feelings. I need to learn how to get TS to help me rather than it providing guarantee I can use.
.5. If I utilize points 1, 2, 3 and 4 as a base. Point 4 is the only one that I would say hints at long term negative effects. Otherwise these issues read more like
'Why utilize Typescript when there are better alternatives. We don't use those because static typing is pointless.'
Put in point 5 and it is topped off with 'and you don't believe me even though I've used Typescript longer than you.'
I think static type systems have proven themselves over and over again. But we also have sufficient evidence that systems can be built without static typing with stability and reliability that an argument against static typing is strong.
As someone whose job it is to assure that stability, I don't want to be doing it for dynamic languages.
I never said not to check types statically. Never said static type checks are redundant. I said you don't need anything but JavaScript and tooling you're already likely to use with it (with or without TS) for that. And that you still need to learn the dynamic type system JS already offers to actually safeguard against wrong types at runtime. TS adds zero benefit, and a great deal of burden, for things you already can do without it (and still need to do with or without).
Your response to point 5, in the context of your other interpretations of what I actually said, is "You still don't really understand TypeScript, no matter how long you've used it. How could you not accept its greatness and inevitability if you did?"
Your response to 4 ignores 3. They can't avoid dynamic typing. They're transpiling to JS. It also, as is far too common among TS fans, ignores what junior devs are already expected to learn (and anybody who tells them to ignore dynamic typing needs to go back and re-learn JS - sans TS - themselves).
Your responses to 4 and 3 prove my point about 2.
Then I guess you'd better start doing all of your frontend in WASM (loaded with plain ol' dynamic JS, with or without TS, of course).
My intention for my summary of 5 was thinking it might help you see how the sum of your statements come together.
Thank you yor try to do the same, though I need some help connecting the translation. Namely my mistake seems to primarily stem from the assumption that you are not in favor of types.
I would say this assumption mainly stems from item 2, which I explicitly asked for help in understanding. Could I get further clarification on how that point isn't general to all type systems mentioned?
I'm against butchering JavaScript to behave like another language through the use of a "superset" (TypeScript, though I have the same issue with CoffeeScript, ClojureScript, etc.) because someone decided that, rather than take the time to learn JavaScript qua JavaScript, one should impose one's personal language preferences on all other devs involved.
In his original edition of You Don't Know JS, Kyle Simpson said two very important things when it comes to JavaScript:
To be clear, what I'm saying is:
This does not help me understand your second point, which I'm still interested if I was able to extrapolate the meaning of correctly or not.
Thank you for providing a clearer position.
I think it is interesting that you don't like that someone is trying to make Javascript usable for themselves, yet are aware that the environment does not allow for an alternative, WebASM still has JS boot straps and is a much more recent option (not fully ready) compared to all previous attempts.
I'm not sure exactly how I can further clarify this, other than to say "yes, you should check types statically, but you don't need TypeScript to do so" and "but you still need to account for runtime, which static type checking will never solve, and vanilla JavaScript already provides tools for this if you bother to learn its dynamic type system instead of acting like a static checking superset eliminates this need."
Making something useful for yourself is one thing. Imposing it on others and acting like it's the only way is something entirely different. Just look at all the demands on library maintainers to add types to their libraries, when the maintainers themselves haven't expressed any desire to use (let alone maintain additional support for) TypeScript.
I think I'm having a hard time with these two statements, why would you believe we should check types statically if at the same time you believe they do nothing for runtime. I think we both agree that the only thing that matters is runtime behavior. Everything else is done in support of getting the runtime portion correct.
I might be in agreement on pushing you desire for Typescript onto 3rd party libraries. I feel as though our discussion is more focused on why Typescript is or is not valuable and why it is winning the static typing challenge of javascript.
Both of these can be true at the same time:
In either case, TypeScript is a pointless "solution."
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.