(Like expecting that just because you declared something as type X, that it guarantees at runtime it will always be type X, but it won't. You may get data from an API that _says_ it returns type X but the contents don't match. That can be valid code that compiles and has weird runtime behavior)
This is exactly why I never recommend TypeScript to new developers.
A similar problem (that used to be worse) with people learning JavaScript is the lack of separation between JavaScript and the DOM + browser APIs. 10+ years ago, people have told me how much they hated JavaScript and when probed about it further, would admit that it’s actually the DOM or new/inconsistent browser APIs that have caused issued.
JS has a number of its own flaws and quirks, yes, but there are two fundamental issues that make it harder to approach as a new learner (as opposed to, to say, Python) are how tightly coupled it has historically been to it’s primarily application case and how high or low level is this language?
Care to provide what you mean?
Strict TS won't compile pretty much any type-unsafe operation.
It's not perfect, the standard libraries are a bit too unsafe type wise, exceptions are untyped and need Either/Result-like data types to be handled but it's an extremely powerful language if you know it and it's ecosystem.
Most people though don't even bother reading the docs and can't tell you what a mapped type is or what is a disjointed union, etc.
As soon as you have third party code calling your methods all bets are off. It could be JS calling your methods, or there simply is a hidden cast somewhere.
This is the moment that you realize that type annotations really are just a compile-time fiction, much like Python. At least in my definition, this is weak typing as the variable is physically capable of changing to any type at runtime, despite its type annotations.
In case of C++ this would lead to desastrous memory corruption. If all data is dynamic you can't have a safe program as data on the stack must be monomorphic or you corrupt nearby memory.
Naturally, you can defend against hostile input via excessive defensive programming (asserting against nulls, asserting against wrong types etc.). Or you simply use a strong static typed language.
The idea that someone is good at another language so they'll automatically be good at another is a common misconception. In fact, they're likely to be worse because they're less likely to spend time trying to learn things from the ground up and less likely to write idiomatic code.
It's especially bad with js/ts because of it's popularity (so lots of new programmers that complain about how NaN doesn't equal itself), and because it's the defacto web language so lots of people are forced to use it as a secondary language that don't want to spend time learning it.
Why is that? If you want them to learn JS, teach/recommend them to learn JS?
Compile-to-JavaScript languages come and go, but JavaScript has remained. First learning vanilla JavaScript makes sense, and then add TS on top if you really have to. At the very least they'll be prepared for when TypeScript goes out of favor.
This is both a curse and the secret behind its success - it's arguably not a separate language, but instead an annotation layer on top of the existing language for encoding and checking your static reasoning and assumptions.
I think that's besides the point. My point was more that people who are supposed to learn JavaScript, should do so by learning vanilla JavaScript first, then they can move on to learning whatever is currently hyped by the zeitgeist (which happens to be TypeScript currently).
Most CoffeeScript will simply syntax error if you feed it into a JS interpreter (and vice versa), and there's no trivial syntactic transform to get around that (i.e. it's not just a new surface syntax over JavaScript). Various features in CoffeeScript have no equivalent in JS, so new code needs to be synthesized for them; even fundamental features that are shared by the two languages are different - for just one example, this [0] article shows that how a function is compiled in CoffeeScript is non-local - the compiler is tracking variable scopes to get around the fact that CoffeeScript and JavaScript have different scoping semantics.
With TypeScript, the "compilation" process is (almost):
parse(typeScriptCode) -> treeMap(removeTypeAnnotation) -> write
...but that's mostly just what I say to JavaScript devs, to be polite - to not tell them that their JavaScript code is bad, too. Code that's difficult to reason about statically is strictly worse, in my opinion, than code that's easier to reason about statically. And in that sense, TypeScript is just guiding you to write better JavaScript, which maybe undercuts its claim to being a language of its own.
The chances of it going out of favour are very slim, there's a giant ecosystem built on it and the language is very well loved by devs (should be second only to Rust).
Microsoft has 50 people on payroll working only on TS. Any competitor needs a gargantuan investment.
It really isn't, but I guess that's really context specific. What country and sector are you talking about? For US-SaaS, what you're saying is probably true, but there is a whole world outside of that, and JavaScript is with 99% certainty much more wildly used than TypeScript.
> and it has killed all of the other compile-to-js languages.
Also it hasn't. I've been writing ClojureScript for the last 5 years, almost exclusively. And while the community is small, I wouldn't say it's "dead" or been killed. There are a bunch of compile-to-JS languages that haven't "been killed", besides ClojureScript.
But it serves basically the opposite niche compared to TypeScript.
> The chances of it going out of favour are very slim
Same has been said about everything, always, and it's always not true. Winds change, and surely so shall the winds of TypeScript. Not being able to see that it's possible, will put you at disadvantage.
Any valid JavaScript is valid TypeScript and you're gonna write and read TS anyway in the industry.
They aren't in competition, but coming back to the first comment it sounds reasonable to start directly with TS for many users.
I'm not sure you're 100% right about it overtaking JS for most of the industry.
I wouldn't recommend it to beginners until they've learned JS because it's a lot of stuff to learn on top of JS to achieve basically the same outcomes (with fewer bugs). Chapter 5 in the Eloquent JavaScript book gets to higher order functions, which in TS means Generics. Nobody needs to learn Generics in Chapter 5 of their programming journey.
You also don't really appreciate how useful TS is until you've battled at least one project in plain JS.
(Arguably you can go a long way without HoF too, but perhaps not if you're hoping to understand other people's code.)
https://npmtrends.com/@babel/preset-flow-vs-flow-bin-vs-type...
Compare it with typescript [1] contributions if you want.
[0] https://github.com/facebook/flow/graphs/contributors
[1] https://github.com/microsoft/TypeScript/graphs/contributors
An anecdote: I was sold a similar story on CoffeeScript back in the day, stressed myself out learning it, only to discard it a couple years later. TS won't have an identical fate as its shepherded by Microsoft, but eventually it will go the way of the dodo (whereas core JS will still be humming along).