I work with pedagogies, teach, write curricula, coach, manage, mentor, consult, speak publicly, polemicize, and sometimes work as a full-stack web developer, architect, ontologist, and more.
TypeScript does not pretend to solve problems with runtime types. Please show where in the official docs it makes that claim? With or without TS, that is the developer's problem to solve. So let's just cross that nonsense out.
TypeScript is optional. You can use as much or as little as you want. If your types are gibberish, you probably just haven't learned to use types well. Anyone who wants to be considered a serious programmer should understand static types, whether in TS or not. It's no different than not understanding how variables work, or scope. Let's cross that one out, too.
This is actually restating #1, but nowhere in the TypeScript docs does it claim to "solve" the problem (which "problem" is that?). TS makes it easier to find type errors at compile time, and helps IDEs to provide better help. End of story. The rest is straw man. Into the loo with this one, too.
TypeScript is a superset because it includes language that is not in JS. What precisely in JS does it prevent you from using? Remember that all TS is removed at compile time and that TS is optional. What nonsense! Maybe take a class in set theory? Consign this one to the trash.
TypeScript is as open-source as React is. As many other major libraries and frameworks are. Angular? What, exactly, is the point here? Don't like M$, don't use it. Really grasping at straws here. From here on it's mostly just filler, no?
That big companies use it means it will be around for a long time, therefore it's a safe bet. And the increasing (skyrocketing, really) popularity of TS means that anyone wanting to work in an enterprise environment will probably need to know it. Sounds like a good reason to learn it to me. It's why I did. So this one is still more BS.
Static types are a feature. JS doesn't have them. Shitcan this one.
This is the only argument with even a modicum of truth in it. But while there is definitely a "TypeScipt Tax", that is true for learning any new thing. That said, learning a type system makes a programmer better at programming. It really should be a sine qua non (look it up). And better programmers write better code.
Just as fixing ESLint errors also takes time, but makes both better code and better programmers. Just as learning new language features takes time, but makes both better code and better programmers.
Wait, what was your point? I think this one's for the bin, too.
And that makes your batting average, um, 0.000.
I'm not a huge fan of TypeScript. as I've said many times elsewhere, I'd like to see the TC-39 committee get off their butts and approve an optional, Hindley-Milner type system with inferencing for ECMAScript. It is long since overdue.
But I can read the writing on the wall, and JS devs who refuse to learn TS will soon find themselves cranks, kooks, and dinosaurs. Whether you approve or not is irrelevant. Read 'em and weep.
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.
ROTFL. You could use this post in logic textbooks as the epitome of the straw man fallacy: en.wikipedia.org/wiki/Straw_man
TypeScript does not pretend to solve problems with runtime types. Please show where in the official docs it makes that claim? With or without TS, that is the developer's problem to solve. So let's just cross that nonsense out.
TypeScript is optional. You can use as much or as little as you want. If your types are gibberish, you probably just haven't learned to use types well. Anyone who wants to be considered a serious programmer should understand static types, whether in TS or not. It's no different than not understanding how variables work, or scope. Let's cross that one out, too.
This is actually restating #1, but nowhere in the TypeScript docs does it claim to "solve" the problem (which "problem" is that?). TS makes it easier to find type errors at compile time, and helps IDEs to provide better help. End of story. The rest is straw man. Into the loo with this one, too.
TypeScript is a superset because it includes language that is not in JS. What precisely in JS does it prevent you from using? Remember that all TS is removed at compile time and that TS is optional. What nonsense! Maybe take a class in set theory? Consign this one to the trash.
TypeScript is as open-source as React is. As many other major libraries and frameworks are. Angular? What, exactly, is the point here? Don't like M$, don't use it. Really grasping at straws here. From here on it's mostly just filler, no?
That big companies use it means it will be around for a long time, therefore it's a safe bet. And the increasing (skyrocketing, really) popularity of TS means that anyone wanting to work in an enterprise environment will probably need to know it. Sounds like a good reason to learn it to me. It's why I did. So this one is still more BS.
Static types are a feature. JS doesn't have them. Shitcan this one.
This is the only argument with even a modicum of truth in it. But while there is definitely a "TypeScipt Tax", that is true for learning any new thing. That said, learning a type system makes a programmer better at programming. It really should be a sine qua non (look it up). And better programmers write better code.
Just as fixing ESLint errors also takes time, but makes both better code and better programmers. Just as learning new language features takes time, but makes both better code and better programmers.
Wait, what was your point? I think this one's for the bin, too.
And that makes your batting average, um, 0.000.
I'm not a huge fan of TypeScript. as I've said many times elsewhere, I'd like to see the TC-39 committee get off their butts and approve an optional, Hindley-Milner type system with inferencing for ECMAScript. It is long since overdue.
But I can read the writing on the wall, and JS devs who refuse to learn TS will soon find themselves cranks, kooks, and dinosaurs. Whether you approve or not is irrelevant. Read 'em and weep.
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.