As usual, this comes off as someone who assumes I haven't worked on numerous projects written in TypeScript throughout the years, and haven't attempted to give it (and, as I mentioned in a previous comment, CoffeeScript) a fair shake. I have, repeatedly, and the benefits have never outweighed the drawbacks. Your beloved superset ends up not only being superfluous, but detrimental.
Time and time again, I've heard the same refrains:
"Type safety" (there's not, any more than you already have in JavaScript with proper function/"class" commenting/documentation you should use anyway - the same is true of any other language). And none of the static typing in any of those languages is going to save you from runtime. You're correct that that's not inherently the fault of TypeScript for the most part, but billing it as "your types are safe now" results IRL in a lack of attention paid to, and effort bothering to learn, dynamic types already in JS and runtime type checking.
"Type inference." Yeah, that's cool I guess, but it doesn't replace the need to properly document correct type usage.
"Better organization of complex codebases" (when, in fact, complexity usually grows exponentially).
Nothing in TypeScript requires you to use classes (in fact, it's often harder to use ES6 classes with TypeScript). ES6 classes were the result of the standards committee improving JavaScript
Wait... I'm confused. I thought in TypeScript everything JavaScript was valid and good and... How is it something you believe improves JavaScript, that is now actually in the spec, is harder to use with this blessed superset thereof? While I don't share your opinion of ES6 classes, do you not see the contradiction here?
And nobody on the TS side seems willing to address the effect it has on both junior devs and talent pool.
I usually hear, as I did earlier in this thread, "not the type of dev I'd want to hire." That doesn't answer the question. So how do you create experienced JS devs? Is your answer to take experienced C# devs and plop them into JS via TypeScript?
And what about that other 50% (again, likely WAY higher) of JS devs? Do you just tell them their however many years of experience with JS are invalid if they don't write TypeScript?
And for the small startup and the dev(s) they're fortunate enough to find who they can afford with enough competence to build their product, do you impose TypeScript on them?
As usual, this comes off as someone who assumes I haven't worked on numerous projects written in TypeScript throughout the years, and haven't attempted to give it (and, as I mentioned in a previous comment, CoffeeScript) a fair shake.
Because you write like someone that hasn't taken the time to actually give Typescript a shot and make very, very basic mistakes about how it works and what its purpose is.
Your beloved superset ends up not only being superfluous, but detrimental.
You haven't given any reasons for it being detrimental.
(there's not, any more than you already have in JavaScript with proper function/"class" commenting/documentation you should use anyway - the same is true of any other language).
Typescript is more capable of representing complex types and doing so with dependencies. That's not something you get with JSDoc; more npm modules have correct Typescript typings than JSDoc documentation. Typescript is also much more elegant, saving probably multiple kilobytes of space on a large project compared to JSDoc comments. Last, Typescript types everything by default, while JSDoc does the exact opposite. If you forget a JSDoc comment on a variable or a module doesn't have JSDoc types, then you're screwed. Typescript covers much more, is much safer, and is much more elegant.
but billing it as "your types are safe now"
I never said this, I said it gives you more type safety than whatever tool you're using currently. It's not 100% type safe (I doubt this is not possible), but it does prevent a large margin of errors from even happening, much moreso than JSDoc.
results IRL in a lack of attention paid to, and effort bothering to learn, dynamic types already in JS and runtime type checking.
If you'd really used Typescript before you'd know that Typescript requires you to use runtime type-checking in order to limit down union types. It's encouraging better practices, not replacing them.
How is it something you believe improves JavaScript, that is now actually in the spec, is harder to use with this blessed superset thereof? While I don't share your opinion of ES6 classes, do you not see the contradiction here?
I again didn't say this, please avoid putting words in my mouth. I said the majority of Typescript developers I've encountered prefer to not use ES6 classes simply because there are other alternatives (e.g. a more functional flavor of Javascript) that work better for them with the same effects.
And nobody on the TS side seems willing to address the effect it has on both junior devs and talent pool.
It... doesn't have any effect? It's just a tool. That's like saying ESLint or JSDoc has a significant effect on junior devs and the talent pool.
Do you just tell them their however many years of experience with JS are invalid if they don't write TypeScript?
I didn't say this. You're sounding fanatical.
And for the small startup and the dev(s) they're fortunate enough to find who they can afford with enough competence to build their product, do you impose TypeScript on them?
I didn't say I'd impose Typescript on anyone, but it wouldn't necessarily be a bad thing. Typescript isn't that hard to learn and doesn't take near as long to get started with as you're implying. It's just Javascript.
Are we really worrying about kilobytes? That's like arguing for SQL over NoSQL (not at all implying there aren't legitimate use cases) in 2020 because "storage is expensive."
You do know comments get stripped out of transpiled and/or minified JavaScript, right? And why aren't you worried about kilobytes of type definitions in not only your code, but every DefinitelyTyped definition dependency you're pulling down?
I again didn't say this, please avoid putting words in my mouth.
I literally quoted you saying ES6 classes are harder in TypeScript. NBD, and I'd say encouraging devs not to use them is a plus, but I'm not the one who called them an improvement to JavaScript, and making something harder (which is still commonly used in TS, seen it plenty of times) isn't the way to discourage it.
It's just JavaScript
No, it's not.
I've said what I needed to say, based on years of experience in both JS and TS, and I know I'm not going to change the minds of people dead set on treating JS like another language built on completely different paradigms. So I'll leave by recommending they check out Ryan Dahl's (Node.js and Deno creator's) recent experiences and motivation for moving away from TS for Deno's internals, and especially Kyle Simpson's (YDKKS author's) comments (some of which are the same beefs I have) as to why that's a bad idea.
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Are we really worrying about kilobytes? That's like arguing for SQL over NoSQL (not at all implying there aren't legitimate use cases) in 2020 because "storage is expensive."
You do know comments get stripped out of transpiled and/or minified JavaScript, right? And why aren't you worried about kilobytes of type definitions in not only your code, but every DefinitelyTyped definition dependency you're pulling down?
I'm not worried about it, I'm saying it saves space, both in the amount of code you have to read but also in the final sizes of the files you're working with. JSDoc comments are ugly, illegible, and not usable if you use them everywhere to get the same type safety you get from Typescript. JSDoc is a great way to document Javascript, but it is not in any way a replacement for Typescript if you care about type safety.
I literally quoted you saying ES6 classes are harder in TypeScript.
No, you didn't. I said this:
Typescript neither encourages nor inhibits you from using it, but I think you'll find that the majority of Typescript developers don't use classes.
Not that Typescript classes are harder to use, but that most Typescript, and Javascript, users don't feel the need to use them.
but I'm not the one who called them an improvement to JavaScript
Because it was better than the previous implementation of classes (having to use objects)? I mean... it's objectively an improvement to Javascript. If you can't acknowledge that, then you really don't need to be making any sort of comments on anythingJavascript-related.
which is still commonly used in TS, seen it plenty of times
Seeing something several times and it being 'common' in TS code are not the same thing. Please provide numbers that the majority of Typescript code uses ES6 classes solely (not just for working with a single library or for a single component, but as the base building block of an application) and then we can talk.
Update June 10 2020: I saw that this design doc was being discussed more widely. Most people don't have the context to understand this narrow technical document - it is only applicable to a very particular, very technical situation in the internals of Deno. This is not at all a reflection on the usefulness of TypeScript in general.
Kyle Simpson said this about Typescript:
TS is a linted set of JS that accommodates some opinions on good code. That's great.
I'm sure it is exhausting having to edit your comments after I've pointed out a contradiction, so it looks like I fabricated your actual words as shared in the blockquote (yeah, you did that, the blockquote is exactly what you said... That's pathetic, dude), and cherry-picking the one lukewarm comment you could find from Simpson (among countless negatives) that you could drop to make it look like he supports TS.
But yeah, it is a complete waste of time to debate someone who has to stoop to such lows.
I'm not cherry-picking any comments from Simpson, I found a comment that said he is indifferent to Typescript.
As for the Deno post, I read the comment at the top of the document you sent me that says that the findings in the document shouldn't be used as a way to talk about the usefulness of Typescript. Again, here's the part quoted from the document:
This is not at all a reflection on the usefulness of TypeScript in general.
Typescript was not the right choice for Deno's internals. Only for the internals, not for anything else, because the Typescript compiler resulted in some runtime inefficiencies for them. Almost nobody will hit that issue in production, and it's slowly being solved by rewriting TSC in Rust, like the swc project is doing. It is not cherry-picking for me to listen to the author's intent. I did not intend to make it look like he supports TS (that was implied nowhere in my comment). Please read my comments more carefully before assuming ill-intent.
Maybe you should read the resources you link (or quote, for that matter as well) before commenting on them. Similarly, maybe you should actually use a piece of software extensively, observing the community and projects surrounding it much more carefully, before making false, unsupported claims about the project's usefulness or capabilities. In the future, I'd highly recommend against doubling down on your claims when someone points out that they're wrong, using that as a sign that you need to educate yourself further on what you're talking about, instead of continuing to spout false assertions and FUD that might deter new users away from using a beneficial piece of technology. It's toxic, immature, and makes no one want to believe or take seriously any of your points.
Must be even more exhausting, putting forth that much effort to FUD my "FUD" (which couldn't possibly be based on numerous real life experiences over several years, because you disagree with me).
And Dahl's experience isn't nearly as uncommon as you would have people believe. That's why I referred to it. In this case, it's a matter of direct impact on a tool that more and more people are migrating to, away from Node. It's a BFD.
As for Simpson, he has expressed plenty of opinions unapologetically against TypeScript. As I said, it must have been exhausting to hunt down one snippet that was mere indifference.
And there's still the (pathetic) matter of editing a comment to make it appear that I made up a direct quote from you. It's OK. We all contradict ourselves at times, especially in the heat of an argument (and frankly, it wasn't that big of a deal until you resorted to the narcissistic, abusive boyfriend tactic of "I never said that!!!"). It's not ok to resort to virtual gaslighting when called on a contradiction (and again, a minor one until you went this route).
There's obviously nothing to be gained from continuing this "debate." You like TypeScript. I like actual JavaScript.
Let's not get any deeper in the weeds, so you don't have to resort to any more toxic behavior. On the whole, DEV's comments are extremely productive even when there is disagreement. This, on the other hand, is more akin to Reddit.
Must be even more exhausting, putting forth that much effort to FUD my "FUD" (which couldn't possibly be based on numerous real life experiences over several years, because you disagree with me).
You provided no evidence to support your claims and severely misunderstood basic parts of Typescript. I doubt your life experiences were extensive enough for you to be able to make an informed decision on whether Typescript is useful for a project or not if you were unable to get basic things right.
And Dahl's experience isn't nearly as uncommon as you would have people believe.
Please provide evidence that this is the case. Are there any other experiences with Typescript that I should be reading about? Are tons of people using Typescript as a runtime instead of using as a compile-time tool, as it's usually intended to do?
As for Simpson, he has expressed plenty of opinions unapologetically against TypeScript.
Please provide links, I could not find any evidence of this.
As I said, it must have been exhausting to hunt down one snippet that was mere indifference.
This was taken from the first page of google:
(and frankly, it wasn't that big of a deal until you resorted to the narcissistic, abusive boyfriend tactic of "I never said that!!!")
There is literally no need to behave like this. It's toxic and I suggest you stop.
There's obviously nothing to be gained from continuing this "debate." You like TypeScript. I like actual JavaScript.
I like both. This is not an either/or situation, it's possible to like multiple languages at the same time.
so you don't have to resort to any more toxic behavior
I was not the one that compared the person I'm talking with to an 'abusive boyfriend'. And you're right, this conversation is done. Dev.to admins have been notified accordingly. Please stop with this behavior. It creates a toxic and unwelcoming atmosphere for those that are new to Dev.
And tattling to the admins after you edited your comment and called me a liar for quoting it in its original form? The same admins who would be most likely to have a record of your edit?
Yeah. I'm done. Let them sort it out, but let the record show that I never attacked anyone personally (as you did many times, provable at least until you make more edits) unless calling out a quoted contradiction (which you then deleted) counts, until you continued that attack by calling me a liar with nothing but an edited comment to back up the claim (the aforementioned "virtual gaslighting," which apparently continues with you suddenly "taking the high road" immediately after yet another personal attack).
Feel free to get the last word in, as I'm sure you will.
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.
As usual, this comes off as someone who assumes I haven't worked on numerous projects written in TypeScript throughout the years, and haven't attempted to give it (and, as I mentioned in a previous comment, CoffeeScript) a fair shake. I have, repeatedly, and the benefits have never outweighed the drawbacks. Your beloved superset ends up not only being superfluous, but detrimental.
Time and time again, I've heard the same refrains:
Wait... I'm confused. I thought in TypeScript everything JavaScript was valid and good and... How is it something you believe improves JavaScript, that is now actually in the spec, is harder to use with this blessed superset thereof? While I don't share your opinion of ES6 classes, do you not see the contradiction here?
And nobody on the TS side seems willing to address the effect it has on both junior devs and talent pool.
I usually hear, as I did earlier in this thread, "not the type of dev I'd want to hire." That doesn't answer the question. So how do you create experienced JS devs? Is your answer to take experienced C# devs and plop them into JS via TypeScript?
And what about that other 50% (again, likely WAY higher) of JS devs? Do you just tell them their however many years of experience with JS are invalid if they don't write TypeScript?
And for the small startup and the dev(s) they're fortunate enough to find who they can afford with enough competence to build their product, do you impose TypeScript on them?
Because you write like someone that hasn't taken the time to actually give Typescript a shot and make very, very basic mistakes about how it works and what its purpose is.
You haven't given any reasons for it being detrimental.
Typescript is more capable of representing complex types and doing so with dependencies. That's not something you get with JSDoc; more npm modules have correct Typescript typings than JSDoc documentation. Typescript is also much more elegant, saving probably multiple kilobytes of space on a large project compared to JSDoc comments. Last, Typescript types everything by default, while JSDoc does the exact opposite. If you forget a JSDoc comment on a variable or a module doesn't have JSDoc types, then you're screwed. Typescript covers much more, is much safer, and is much more elegant.
I never said this, I said it gives you more type safety than whatever tool you're using currently. It's not 100% type safe (I doubt this is not possible), but it does prevent a large margin of errors from even happening, much moreso than JSDoc.
If you'd really used Typescript before you'd know that Typescript requires you to use runtime type-checking in order to limit down union types. It's encouraging better practices, not replacing them.
I again didn't say this, please avoid putting words in my mouth. I said the majority of Typescript developers I've encountered prefer to not use ES6 classes simply because there are other alternatives (e.g. a more functional flavor of Javascript) that work better for them with the same effects.
It... doesn't have any effect? It's just a tool. That's like saying ESLint or JSDoc has a significant effect on junior devs and the talent pool.
I didn't say this. You're sounding fanatical.
I didn't say I'd impose Typescript on anyone, but it wouldn't necessarily be a bad thing. Typescript isn't that hard to learn and doesn't take near as long to get started with as you're implying. It's just Javascript.
Are we really worrying about kilobytes? That's like arguing for SQL over NoSQL (not at all implying there aren't legitimate use cases) in 2020 because "storage is expensive."
You do know comments get stripped out of transpiled and/or minified JavaScript, right? And why aren't you worried about kilobytes of type definitions in not only your code, but every DefinitelyTyped definition dependency you're pulling down?
I literally quoted you saying ES6 classes are harder in TypeScript. NBD, and I'd say encouraging devs not to use them is a plus, but I'm not the one who called them an improvement to JavaScript, and making something harder (which is still commonly used in TS, seen it plenty of times) isn't the way to discourage it.
No, it's not.
I've said what I needed to say, based on years of experience in both JS and TS, and I know I'm not going to change the minds of people dead set on treating JS like another language built on completely different paradigms. So I'll leave by recommending they check out Ryan Dahl's (Node.js and Deno creator's) recent experiences and motivation for moving away from TS for Deno's internals, and especially Kyle Simpson's (YDKKS author's) comments (some of which are the same beefs I have) as to why that's a bad idea.
I'm not worried about it, I'm saying it saves space, both in the amount of code you have to read but also in the final sizes of the files you're working with. JSDoc comments are ugly, illegible, and not usable if you use them everywhere to get the same type safety you get from Typescript. JSDoc is a great way to document Javascript, but it is not in any way a replacement for Typescript if you care about type safety.
No, you didn't. I said this:
Not that Typescript classes are harder to use, but that most Typescript, and Javascript, users don't feel the need to use them.
Because it was better than the previous implementation of classes (having to use objects)? I mean... it's objectively an improvement to Javascript. If you can't acknowledge that, then you really don't need to be making any sort of comments on anythingJavascript-related.
Seeing something several times and it being 'common' in TS code are not the same thing. Please provide numbers that the majority of Typescript code uses ES6 classes solely (not just for working with a single library or for a single component, but as the base building block of an application) and then we can talk.
Here's the link to Ryan Dahl's experiences with Typescript. I'd recommend you actually read what you're sending me before commenting because he says this:
Kyle Simpson said this about Typescript:
Don't see any negative opinions here. Link to the tweet.
Please stop commenting. You're showing how uneducated you are on the topic and how little you really know. It's exhausting.
I'm sure it is exhausting having to edit your comments after I've pointed out a contradiction, so it looks like I fabricated your actual words as shared in the blockquote (yeah, you did that, the blockquote is exactly what you said... That's pathetic, dude), and cherry-picking the one lukewarm comment you could find from Simpson (among countless negatives) that you could drop to make it look like he supports TS.
But yeah, it is a complete waste of time to debate someone who has to stoop to such lows.
I'm not cherry-picking any comments from Simpson, I found a comment that said he is indifferent to Typescript.
As for the Deno post, I read the comment at the top of the document you sent me that says that the findings in the document shouldn't be used as a way to talk about the usefulness of Typescript. Again, here's the part quoted from the document:
Typescript was not the right choice for Deno's internals. Only for the internals, not for anything else, because the Typescript compiler resulted in some runtime inefficiencies for them. Almost nobody will hit that issue in production, and it's slowly being solved by rewriting TSC in Rust, like the swc project is doing. It is not cherry-picking for me to listen to the author's intent. I did not intend to make it look like he supports TS (that was implied nowhere in my comment). Please read my comments more carefully before assuming ill-intent.
Maybe you should read the resources you link (or quote, for that matter as well) before commenting on them. Similarly, maybe you should actually use a piece of software extensively, observing the community and projects surrounding it much more carefully, before making false, unsupported claims about the project's usefulness or capabilities. In the future, I'd highly recommend against doubling down on your claims when someone points out that they're wrong, using that as a sign that you need to educate yourself further on what you're talking about, instead of continuing to spout false assertions and FUD that might deter new users away from using a beneficial piece of technology. It's toxic, immature, and makes no one want to believe or take seriously any of your points.
Must be even more exhausting, putting forth that much effort to FUD my "FUD" (which couldn't possibly be based on numerous real life experiences over several years, because you disagree with me).
And Dahl's experience isn't nearly as uncommon as you would have people believe. That's why I referred to it. In this case, it's a matter of direct impact on a tool that more and more people are migrating to, away from Node. It's a BFD.
As for Simpson, he has expressed plenty of opinions unapologetically against TypeScript. As I said, it must have been exhausting to hunt down one snippet that was mere indifference.
And there's still the (pathetic) matter of editing a comment to make it appear that I made up a direct quote from you. It's OK. We all contradict ourselves at times, especially in the heat of an argument (and frankly, it wasn't that big of a deal until you resorted to the narcissistic, abusive boyfriend tactic of "I never said that!!!"). It's not ok to resort to virtual gaslighting when called on a contradiction (and again, a minor one until you went this route).
There's obviously nothing to be gained from continuing this "debate." You like TypeScript. I like actual JavaScript.
Let's not get any deeper in the weeds, so you don't have to resort to any more toxic behavior. On the whole, DEV's comments are extremely productive even when there is disagreement. This, on the other hand, is more akin to Reddit.
You provided no evidence to support your claims and severely misunderstood basic parts of Typescript. I doubt your life experiences were extensive enough for you to be able to make an informed decision on whether Typescript is useful for a project or not if you were unable to get basic things right.
Please provide evidence that this is the case. Are there any other experiences with Typescript that I should be reading about? Are tons of people using Typescript as a runtime instead of using as a compile-time tool, as it's usually intended to do?
Please provide links, I could not find any evidence of this.
This was taken from the first page of google:
There is literally no need to behave like this. It's toxic and I suggest you stop.
I like both. This is not an either/or situation, it's possible to like multiple languages at the same time.
I was not the one that compared the person I'm talking with to an 'abusive boyfriend'. And you're right, this conversation is done. Dev.to admins have been notified accordingly. Please stop with this behavior. It creates a toxic and unwelcoming atmosphere for those that are new to Dev.
Is it done or am I supposed to provide examples?
And tattling to the admins after you edited your comment and called me a liar for quoting it in its original form? The same admins who would be most likely to have a record of your edit?
Yeah. I'm done. Let them sort it out, but let the record show that I never attacked anyone personally (as you did many times, provable at least until you make more edits) unless calling out a quoted contradiction (which you then deleted) counts, until you continued that attack by calling me a liar with nothing but an edited comment to back up the claim (the aforementioned "virtual gaslighting," which apparently continues with you suddenly "taking the high road" immediately after yet another personal attack).
Feel free to get the last word in, as I'm sure you will.