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
i know there's much text in the thread and obviously you didn't read it all, which is ok, no problem.
This talk about using or not using TS is just an experiment with the OP and I . I suspected that I would get more explanations if I proposed closed statements that I would find online, slightly modified and that's all, we also use TS as well as JS, that's not the point, not really.
You -unlike the half of the comments and like the other half as well- have the error of stating your pov instead explaining why some assumptions are wrong "as is".
None of what I said is wrong, but also it's not 100% true, that's why it caused so many replies, some for, some against.
The other error you stated is that TS didn't came to solve anything. Obviously this is a silly argument, every tech came to solve a problem, otherwise it would be ignored, there's no reason for anyone to learn something new if it does not solve a real life concern.
Prototype inheritance, Equality and type juggling, Management of modules, Scope, Lack of types and lack of robust OOP system, were the things they tried to solve with TS. Some are solved and working pretty well in JS since time ago, others are not included -yet- and that's why we are still using TS.
If tomorrow a new JS version adds all TS features, in less than 2 years there will not be a single project started with TS and having TS will become a proof that it's a legacy project. But for the moment it isn't like that so, we've to use TS where it's needed.
TS adds syntactic sugar that facilitate us to work with types and other stuff, but at the end you can do exactly the same using JS type checks and custom types if you want. Obviously it will cost much more dev time but you'll end up with typechecks on runtime as well.
People uses TS instead self-implementing this stuff because it makes it easier and faster to go hands on and because having a compiler taking care of this is easier and adds less boilerplate than doing it with vanilla js at this point.
The rest of your answer... I would like you to explain it in more detail because I think you can do it and I plan to write a post with excerpts of this conversations (mentioning each author) from the engineering point of view, concluding about real concerns about one or another. We both know we'll end up concluding that TS is necessary but the questions are: why is it? when is it? and so on.
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.
i know there's much text in the thread and obviously you didn't read it all, which is ok, no problem.
This talk about using or not using TS is just an experiment with the OP and I . I suspected that I would get more explanations if I proposed closed statements that I would find online, slightly modified and that's all, we also use TS as well as JS, that's not the point, not really.
You -unlike the half of the comments and like the other half as well- have the error of stating your pov instead explaining why some assumptions are wrong "as is".
None of what I said is wrong, but also it's not 100% true, that's why it caused so many replies, some for, some against.
The other error you stated is that TS didn't came to solve anything. Obviously this is a silly argument, every tech came to solve a problem, otherwise it would be ignored, there's no reason for anyone to learn something new if it does not solve a real life concern.
Prototype inheritance, Equality and type juggling, Management of modules, Scope, Lack of types and lack of robust OOP system, were the things they tried to solve with TS. Some are solved and working pretty well in JS since time ago, others are not included -yet- and that's why we are still using TS.
If tomorrow a new JS version adds all TS features, in less than 2 years there will not be a single project started with TS and having TS will become a proof that it's a legacy project. But for the moment it isn't like that so, we've to use TS where it's needed.
TS adds syntactic sugar that facilitate us to work with types and other stuff, but at the end you can do exactly the same using JS type checks and custom types if you want. Obviously it will cost much more dev time but you'll end up with typechecks on runtime as well.
People uses TS instead self-implementing this stuff because it makes it easier and faster to go hands on and because having a compiler taking care of this is easier and adds less boilerplate than doing it with vanilla js at this point.
The rest of your answer... I would like you to explain it in more detail because I think you can do it and I plan to write a post with excerpts of this conversations (mentioning each author) from the engineering point of view, concluding about real concerns about one or another. We both know we'll end up concluding that TS is necessary but the questions are: why is it? when is it? and so on.