That was a great read! Thank you. Not many people have the guts to write that they don't like TS too much because it's a HOT topic and everyone attacks them with the benefits that TS offers while no one is against those benefits. 😄
In general, programming goes back and forth in terms of "the best way to write an app". I don't want to expand on this but one example is going from OOP to Functional programming (FP) and vise-versa or SPA vs SSR. Again I see that I can elaborate on the statements above but I don't want to waste time explaining something that it's not my point.
My point is that people who come from languages like Java love TS and it makes sense because they are used to that paradigm of coding. I came to JS from Java and after some time of using it, I felt in love with JS for the "dynamic behaviour" it offers. I feel more powerful doing things with JS and I never returned to Java. Also I am now a big fun of FP and almost never use OOP. So I think there is some "truthness" on "People who go with TS don't really know how to write good JS"
However we are humans and we can't always rely on people writing good JS and the truth is that even if you are experienced enough with JS, TS does a better job on handling large codebases. I use Webstorm and the IDE offers autocompletion for JS even though it's not great. Is it true if someone says: "We write TS in order to make the IDE happy so it can help us prevent humans syntax errors or remind us we wrote a wrong code" ? I don't think it's 100% true because with TS you get errors on compilation not only inside IDE.
But let's be honest. TS offers some great benefits over pureJS and anyone benefits from them. So it's a fact that TS offers a great experience in letting you know that you did something wrong that you, as a human, could easily code it wrong with pureJS.
But let's be honest again. TS code it's not clean and there is so many examples out there that showcase TS code vs the same code in JS and of course JS wins all the time. You might argue that reading TS code can be easier because you know the typings. For example for function that receives a person argument, in TS you know exactly that the argument is an object with known properties. And you are right.
There in no doubt TS benefits are great but having to write TS code is something that I don't personally love. So I have to leave with coding in a way I don't love for the benefits I need. I think everyone agree that it would be amazing if you could write JS code and have TS benefits. Maybe people coming from Java would not love that either though (kidding.. or am I?).
JS is a very dynamic language. And TS limits the "dynamic" behaviour of JS in order to do its job.
Does that mean that TS limits you to do things that you could otherwise do with pure JS ?
YES.
But still, with workarounds and a bunch of code and experience with TS generics and diving deeper to TS becoming a better developer you can still achieve the result with the "limited JS dynamic behavior" (TS) ?
YES.
Conclusion: I am not against TS because I think everyone loves the benefits but I am against TS because I think everyone loves writing JS more than writing TS.
Since I want TS benefits in order "to be more confident with my code" (as TS docs say) I have to write TS.
NO.
The last couple of days I have been experimenting with JSdoc + TS type checking and pure JS code. And it works amazingly + offers the benefit of explaining your code not only typing it + write docs out of it. Not sure if that's really better than just using TS but currently it seems so.
I also have the option to type only the things I need to. For code that I am sure how it will behave I don't have to write typings. Even though that might seems a bad practice since you should type anything, right now I think it's an advantage. But still early to have an opinion.
Final conclusion: In order to make your code behave the way it should to and be more confident about your code and also using JS, I highly recommend this stack:
XState
Cypress component testing (beta)
JsDoc with TS type checking + pure JS (not a strong opinion)
Modularazing your code
I will write an article about this stack when I experiment a bit more with it. Hopefully it will be within this year.
Yes I've never had an issue writing stuff people think is controversial as I have no particular issue with defending myself and find with my ideas for Frontend Dev I need to often anyway.
In general, I think your observations are dead on. I'm not really sure what the solution is. I do think it's interesting when Vue exports different types for end-developer rather than what they use in the codebase. It makes sense but it suggests this divide is a real one anyway. Which is insane from the perspective of a true typed language and a nod to how artistic this whole endeavor is.
I haven't found JSDOC particularly pleasant anyway because for some reason it feels like more work, but that also acknowledges the fact that you weren't forced into that work when you were just iterating on the idea.
Since writing this article I've had the opportunity to continue to maintain other TS libraries including a whole platform built on top Babel (and custom Babel parser types) Honestly it is a bit of a mess sometimes and we sit there cursing TypeScript but yet we stick at it. I think as library authors it is just part of the thing.
Applications are different as you say, strict state management, robust testing etc all cover the basis. They should be there anyway even with TS. I feel it is likely in that environment the extra work is something you'd need to invest in one way or the other regardless so maybe TS isn't that bad. Like I've seen the move to TS + Prettier instead of ESLint in some cases. That is a simplification in a sense. It's also where it is least necessary.
As a library author, you can write in TS or write your definitions and call it a day. I'm starting to think that the latter might have been the better move for most libraries. It just is awkward how TS bug fixes and upgrades tend to break Semver in ways we don't want to embrace as a library author. It just adds ultimately to the unpleasantness to all those downstream.
This is by far the most relatable comments I can read about typescript on the internet.
As a nodeJS developer who modularazing the codebase, do functional programming with dependency injection. do my unit test properly. write component tests and e2e tests. I just cannot relate the pain points of javascript that many says over and over again.
There's some inferiority situation happening in javascript community and they think the dynamic character is (always) a language problem...
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.
That was a great read! Thank you. Not many people have the guts to write that they don't like TS too much because it's a HOT topic and everyone attacks them with the benefits that TS offers while no one is against those benefits. 😄
In general, programming goes back and forth in terms of "the best way to write an app". I don't want to expand on this but one example is going from OOP to Functional programming (FP) and vise-versa or SPA vs SSR. Again I see that I can elaborate on the statements above but I don't want to waste time explaining something that it's not my point.
My point is that people who come from languages like Java love TS and it makes sense because they are used to that paradigm of coding. I came to JS from Java and after some time of using it, I felt in love with JS for the "dynamic behaviour" it offers. I feel more powerful doing things with JS and I never returned to Java. Also I am now a big fun of FP and almost never use OOP. So I think there is some "truthness" on "People who go with TS don't really know how to write good JS"
However we are humans and we can't always rely on people writing good JS and the truth is that even if you are experienced enough with JS, TS does a better job on handling large codebases. I use Webstorm and the IDE offers autocompletion for JS even though it's not great. Is it true if someone says: "We write TS in order to make the IDE happy so it can help us prevent humans syntax errors or remind us we wrote a wrong code" ? I don't think it's 100% true because with TS you get errors on compilation not only inside IDE.
But let's be honest. TS offers some great benefits over pureJS and anyone benefits from them. So it's a fact that TS offers a great experience in letting you know that you did something wrong that you, as a human, could easily code it wrong with pureJS.
But let's be honest again. TS code it's not clean and there is so many examples out there that showcase TS code vs the same code in JS and of course JS wins all the time. You might argue that reading TS code can be easier because you know the typings. For example for function that receives a
personargument, in TS you know exactly that the argument is an object with known properties. And you are right.There in no doubt TS benefits are great but having to write TS code is something that I don't personally love. So I have to leave with coding in a way I don't love for the benefits I need. I think everyone agree that it would be amazing if you could write JS code and have TS benefits. Maybe people coming from Java would not love that either though (kidding.. or am I?).
JS is a very dynamic language. And TS limits the "dynamic" behaviour of JS in order to do its job.
YES.
YES.
Conclusion: I am not against TS because I think everyone loves the benefits but I am against TS because I think everyone loves writing JS more than writing TS.
NO.
The last couple of days I have been experimenting with JSdoc + TS type checking and pure JS code. And it works amazingly + offers the benefit of explaining your code not only typing it + write docs out of it. Not sure if that's really better than just using TS but currently it seems so.
I also have the option to type only the things I need to. For code that I am sure how it will behave I don't have to write typings. Even though that might seems a bad practice since you should type anything, right now I think it's an advantage. But still early to have an opinion.
Final conclusion: In order to make your code behave the way it should to and be more confident about your code and also using JS, I highly recommend this stack:
I will write an article about this stack when I experiment a bit more with it. Hopefully it will be within this year.
Yes I've never had an issue writing stuff people think is controversial as I have no particular issue with defending myself and find with my ideas for Frontend Dev I need to often anyway.
In general, I think your observations are dead on. I'm not really sure what the solution is. I do think it's interesting when Vue exports different types for end-developer rather than what they use in the codebase. It makes sense but it suggests this divide is a real one anyway. Which is insane from the perspective of a true typed language and a nod to how artistic this whole endeavor is.
I haven't found JSDOC particularly pleasant anyway because for some reason it feels like more work, but that also acknowledges the fact that you weren't forced into that work when you were just iterating on the idea.
Since writing this article I've had the opportunity to continue to maintain other TS libraries including a whole platform built on top Babel (and custom Babel parser types) Honestly it is a bit of a mess sometimes and we sit there cursing TypeScript but yet we stick at it. I think as library authors it is just part of the thing.
Applications are different as you say, strict state management, robust testing etc all cover the basis. They should be there anyway even with TS. I feel it is likely in that environment the extra work is something you'd need to invest in one way or the other regardless so maybe TS isn't that bad. Like I've seen the move to TS + Prettier instead of ESLint in some cases. That is a simplification in a sense. It's also where it is least necessary.
As a library author, you can write in TS or write your definitions and call it a day. I'm starting to think that the latter might have been the better move for most libraries. It just is awkward how TS bug fixes and upgrades tend to break Semver in ways we don't want to embrace as a library author. It just adds ultimately to the unpleasantness to all those downstream.
This is by far the most relatable comments I can read about typescript on the internet.
As a nodeJS developer who modularazing the codebase, do functional programming with dependency injection. do my unit test properly. write component tests and e2e tests. I just cannot relate the pain points of javascript that many says over and over again.
There's some inferiority situation happening in javascript community and they think the dynamic character is (always) a language problem...