Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
It is not against TS, honestly. As I said it's a good thing to learn and to use.
But I'm also honest and realistic about the current state on the market, where there is more projects without TS than with TS. Thinking the opposite is just neglecting the truth of the market.
This is changing though, not as quick as we expected some years ago, but I expect either TS being on the TOP of the state of the art in a couple of years or JS bringing those desired features in the core API while making TS "deprecated" or included in the spec by the TC39 (we'll see which proposal is admitted and in which way as there are some of them, including TS itself).
The JSDoc along with TS pragma has proven to be a good approach on three situations;
1- You want to migrate a code base (of any complexity) from JS to TS. By adding JSDoc and TS pragma you can get static typing, type checks... without having to rewrite the code. Still providing full compatibility between JS and TS along the process.
2- You understand the benefits of static typing buy you also think that using TS has more drawbacks than what it really has (by lack of experience) or the realistic drawbacks that came along with TS (dev time, specifically) can't be justified for the requirements, budget etc.
3- You have a new project in mind but none of the devs (or the major part at least) have previous experience with TS and/or they are not interested on it.
I know you'll tell that either be the case, go ahead with TS and most of the time you'll be right.
Still there are situations where you won't, and in such cases, IMHO is better to use TS Pragma with JSDoc than not using neither TS nor this approach.
If you notice that I try to make more people to know about that is just for that reason (as we discussed before).
An important part of my job is to choose tech stacks accordingly to the business needs, which is not necessarily what I want to use. Despite that I'm not paid to bring my likenesses over the table but to find what aligns better between the business (client) and the available resources (devs).
If it's TS, go ahead with TS, if it's plain JS, it will be plain JS (but I'll encourage the team to use TS Pragma with JSDoc and add it as requirement in the code) so any future migration (if any) will be much easier and we benefit from the features it brings in the meantime.
Oh please, you're constantly advocating for using JSDoc over TS. You're not fooling anyone claiming now that you're unopinionated and "choose tech stacks accordingly to the business needs". The reality is: you've never chosen TS for that tech stack. The fact you're pretending otherwise right now speaks volumes. Deep down even you are realizing you're being obnoxiously stubborn and that the whole world has moved on to greener pastures.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
You should create a post around that stuff, your opinions, likenesses and the reason (if any) behind them instead creating threads larger than the main post in others articles.
You think it's me being stubborn and neglecting the current state of the art and I need to point you again the metrics we care about, which are less than 24k open job positions around TS in the entire European Union vs the over 65k in JavaScript (LinkedIn, searched just now), or the 5.3k vs over 13k if you filter by remote only. If we move to US market it's much much worse for TS.
No survey answered by few hundreds (not necessarily developers) can compete agains that, like it or not, believe it or not (you can search it for yourself in 2 minutes).
You can lie to yourself and say "TS is JS" and it's not. Any JS is valid TS code but not a single line of TS (other than comments) is valid JS.
TS is not so widely used as you think or as you'd like. Sorry. I also find it useful and a must in some projects (not in all of them of course, I'm pragmatic, not a fanboy) and I show people a way to introduce themselves in TS or Typing JS projects with the pragma+comments approach.
I'm wondering what do you do for the industry or for your beloved TS.
Create posts, teach people the basics on an easy way, or teach advanced concepts so we all can learn more and become better developers, do something, show off!
Arguing with others and trying to "change the world" without even trying to understand why it works the way it does is a nonsense and a lose of time.
Any JS is valid TS code but not a single line of TS (other than comments) is valid JS
This right here... Shows you do not know what you're talking about.
You live in the past and for some reason are scared to learn Typescript and so you try to convince people on a dev platform not to use Typescript by trolling each and every post about it.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
@Rense Bakker
try to run your TS file in a browser without compiling to JS. Also there are no plans to support that in a browser.
Typescript extends JS by adding types.
And yes there are benefits using TS.
The downside is that some developers are not aware that your code still can fail on production. I see by getting data from (external) api which is unexpected type, missing. The code breaks on production. Because there are trusting on mockData and TS.
Yes the problem comes from the api. But still your code needs to catch it instead breaking.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Just adding that there are multiple proposals for adding optional type notation into JS core API (including TS itself, Flow and others) but AFAIK none of them reached a stage to be considered a possibility in the short term.
Another issue I faced one time (but I bet is not the only place where this happen) is being on a project where they had budget either for using TS or for applying TDD... They choose TS which is an aberration if you advocate for quality. Also two things happen: an imminent lack of confidence in the code in the short term and tech debt growing quickly. (This is not usually perceived by core team till the exact point where some devs start leaving and new ones come in).
Thinking that TS will magically convert your code into good, robust and trustable code is just ridiculous.
It has benefits and I expect a growth in the amount of business asking for TS in their open job positions because TS + TDD is usually better than JS + TDD.
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.
It is not against TS, honestly. As I said it's a good thing to learn and to use.
But I'm also honest and realistic about the current state on the market, where there is more projects without TS than with TS. Thinking the opposite is just neglecting the truth of the market.
This is changing though, not as quick as we expected some years ago, but I expect either TS being on the TOP of the state of the art in a couple of years or JS bringing those desired features in the core API while making TS "deprecated" or included in the spec by the TC39 (we'll see which proposal is admitted and in which way as there are some of them, including TS itself).
The JSDoc along with TS pragma has proven to be a good approach on three situations;
1- You want to migrate a code base (of any complexity) from JS to TS. By adding JSDoc and TS pragma you can get static typing, type checks... without having to rewrite the code. Still providing full compatibility between JS and TS along the process.
2- You understand the benefits of static typing buy you also think that using TS has more drawbacks than what it really has (by lack of experience) or the realistic drawbacks that came along with TS (dev time, specifically) can't be justified for the requirements, budget etc.
3- You have a new project in mind but none of the devs (or the major part at least) have previous experience with TS and/or they are not interested on it.
I know you'll tell that either be the case, go ahead with TS and most of the time you'll be right.
Still there are situations where you won't, and in such cases, IMHO is better to use TS Pragma with JSDoc than not using neither TS nor this approach.
If you notice that I try to make more people to know about that is just for that reason (as we discussed before).
An important part of my job is to choose tech stacks accordingly to the business needs, which is not necessarily what I want to use. Despite that I'm not paid to bring my likenesses over the table but to find what aligns better between the business (client) and the available resources (devs).
If it's TS, go ahead with TS, if it's plain JS, it will be plain JS (but I'll encourage the team to use TS Pragma with JSDoc and add it as requirement in the code) so any future migration (if any) will be much easier and we benefit from the features it brings in the meantime.
Oh please, you're constantly advocating for using JSDoc over TS. You're not fooling anyone claiming now that you're unopinionated and "choose tech stacks accordingly to the business needs". The reality is: you've never chosen TS for that tech stack. The fact you're pretending otherwise right now speaks volumes. Deep down even you are realizing you're being obnoxiously stubborn and that the whole world has moved on to greener pastures.
You should create a post around that stuff, your opinions, likenesses and the reason (if any) behind them instead creating threads larger than the main post in others articles.
You think it's me being stubborn and neglecting the current state of the art and I need to point you again the metrics we care about, which are less than 24k open job positions around TS in the entire European Union vs the over 65k in JavaScript (LinkedIn, searched just now), or the 5.3k vs over 13k if you filter by remote only. If we move to US market it's much much worse for TS.
No survey answered by few hundreds (not necessarily developers) can compete agains that, like it or not, believe it or not (you can search it for yourself in 2 minutes).
You can lie to yourself and say "TS is JS" and it's not. Any JS is valid TS code but not a single line of TS (other than comments) is valid JS.
TS is not so widely used as you think or as you'd like. Sorry. I also find it useful and a must in some projects (not in all of them of course, I'm pragmatic, not a fanboy) and I show people a way to introduce themselves in TS or Typing JS projects with the pragma+comments approach.
I'm wondering what do you do for the industry or for your beloved TS.
Create posts, teach people the basics on an easy way, or teach advanced concepts so we all can learn more and become better developers, do something, show off!
Arguing with others and trying to "change the world" without even trying to understand why it works the way it does is a nonsense and a lose of time.
This right here... Shows you do not know what you're talking about.
You live in the past and for some reason are scared to learn Typescript and so you try to convince people on a dev platform not to use Typescript by trolling each and every post about it.
That should be then 😂
@Rense Bakker
try to run your TS file in a browser without compiling to JS. Also there are no plans to support that in a browser.
Typescript extends JS by adding types.
And yes there are benefits using TS.
The downside is that some developers are not aware that your code still can fail on production. I see by getting data from (external) api which is unexpected type, missing. The code breaks on production. Because there are trusting on mockData and TS.
Yes the problem comes from the api. But still your code needs to catch it instead breaking.
There is a proposal to adopt type notation in JS
Without JS no TS
@Rense Bakker
one more thing what we can see a lot in code, when using TS. Is typing to any to avoid TS error.
Just adding that there are multiple proposals for adding optional type notation into JS core API (including TS itself, Flow and others) but AFAIK none of them reached a stage to be considered a possibility in the short term.
Another issue I faced one time (but I bet is not the only place where this happen) is being on a project where they had budget either for using TS or for applying TDD... They choose TS which is an aberration if you advocate for quality. Also two things happen: an imminent lack of confidence in the code in the short term and tech debt growing quickly. (This is not usually perceived by core team till the exact point where some devs start leaving and new ones come in).
Thinking that TS will magically convert your code into good, robust and trustable code is just ridiculous.
It has benefits and I expect a growth in the amount of business asking for TS in their open job positions because TS + TDD is usually better than JS + TDD.