With JS, you make no assumptions about types, and you check the concrete value of the variable to make sure it is what you expect it to be. Or, if you do not care about its type in this particular case, you do not. In TS, you rely on the compiler to do it for you.
This isn't a problem with JS or TS, it's a developer choice. If a developer is choosing to blindly trust data, a static type checker is not going to save them from the self immolation they've choosen.
The aesthetic appeal I can partially agree with; plain JS is cleaner in an aesthetic sense. However, in my opinion the various typing options (ts/flow/etc) encode additional information. How one uses the type system dictates how useful that is. Again, blame the dev, not the tools.
It does not solve the problem
I don't think you've been clear on what you belive the problem is or was, and nothing in your examples suggests to me that we have the same idea on what problems static type checking might solve. (Optional semicolons seems a particularly bizarre inclusion. I'm genuinely curious who deems this a problem and why it's being related to types, not style).
It is not a superset...
Other commenters have already addressed precisely why it is.
5-7 I have nothing to say. If those things are important to someone, cool.
As you said it adds transpiling time which is something that you definitely don't want
I can't recall the last time I wrote JS without transpiling it. Using TS feels the same in this respect. If you're in an environment where nothing is being transpiled, minified, bundled, or otherwise built....I guess that's a genuine win for JS. I just personally haven't been in that situation in nearly a decade (even things like require.js dep management had a build step in 2012 and earlier). Other slowdowns I can't confidently opine on, as it seems very much like an empirical point and I have no data to draw from.
Having types isn't a reason to stop writing tests in strongly typed languages, and it's not a reason to stop writing them with statically checked JS. So i suppose we don't disagree on any testing points.
There are various approaches to specifying and enforcing your contracts. Articles like 'parse dont validate' or any of Giulio Canti's posts on dev explain better than I could how one can benefit from using a type system. I think one would be wrong to dismiss TS for the reasons you've offered.
On the other hand, most of the real world TS fans I've met in person fit this group:
TypeScript began its life as an attempt to bring traditional object-oriented types to JavaScript so that the programmers at Microsoft could bring traditional object-oriented programs to the web.
Taken from TS' docs. TS made it easier for them to avoid learning actual JS, and they found that very exciting. I found the results rather horrifying, but ymmv. As others have said, at this point they can use JS syntactic sugar to practice OOP as a religious dogma instead of applying it thoughtfully when appropriate to the problem.
Ultimately, how you use the tools determines the value you receive.
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'm a terrible phone typist, so bear with me.
This isn't a problem with JS or TS, it's a developer choice. If a developer is choosing to blindly trust data, a static type checker is not going to save them from the self immolation they've choosen.
The aesthetic appeal I can partially agree with; plain JS is cleaner in an aesthetic sense. However, in my opinion the various typing options (ts/flow/etc) encode additional information. How one uses the type system dictates how useful that is. Again, blame the dev, not the tools.
I don't think you've been clear on what you belive the problem is or was, and nothing in your examples suggests to me that we have the same idea on what problems static type checking might solve. (Optional semicolons seems a particularly bizarre inclusion. I'm genuinely curious who deems this a problem and why it's being related to types, not style).
Other commenters have already addressed precisely why it is.
5-7 I have nothing to say. If those things are important to someone, cool.
I can't recall the last time I wrote JS without transpiling it. Using TS feels the same in this respect. If you're in an environment where nothing is being transpiled, minified, bundled, or otherwise built....I guess that's a genuine win for JS. I just personally haven't been in that situation in nearly a decade (even things like require.js dep management had a build step in 2012 and earlier). Other slowdowns I can't confidently opine on, as it seems very much like an empirical point and I have no data to draw from.
Having types isn't a reason to stop writing tests in strongly typed languages, and it's not a reason to stop writing them with statically checked JS. So i suppose we don't disagree on any testing points.
There are various approaches to specifying and enforcing your contracts. Articles like 'parse dont validate' or any of Giulio Canti's posts on dev explain better than I could how one can benefit from using a type system. I think one would be wrong to dismiss TS for the reasons you've offered.
On the other hand, most of the real world TS fans I've met in person fit this group:
Taken from TS' docs. TS made it easier for them to avoid learning actual JS, and they found that very exciting. I found the results rather horrifying, but ymmv. As others have said, at this point they can use JS syntactic sugar to practice OOP as a religious dogma instead of applying it thoughtfully when appropriate to the problem.
Ultimately, how you use the tools determines the value you receive.
Very good contribution, concise and well explained, I genuinely coincide in some points with you.