> I am definitely going to recommend they write TS instead of JS
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.
TypeScript isn't really a "compile-to-JavaScript" language in the same way that, say, Rescript is. Modulo a few corner cases (e.g. enums) which are now considered anti-features, TypeScript has the exact same runtime semantics as JavaScript - you can (almost) convert TypeScript to JavaScript just by stripping away the type annotations (and, if various ECMAScript proposals go through, you won't even need to do even that).
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 guess by that same definition, Coffeescript isn't a compile-to-JavaScript language either, as it has the same semantics as vanilla JavaScript?
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).
No, CoffeeScript doesn't have the same semantics as vanilla JavaScript; not in any meaningful sense I can think of, certainly not in the way that TypeScript does.
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):
That's it! TypeScript code is syntactically valid JavaScript code, just with added type annotations (and, as mentioned, soon that'll still count as syntactically valid JavaScript code); JavaScript code is syntactically valid TypeScript code without any type annotations - which doesn't make it syntactically invalid! Indeed, if you turn down the strictness settings on tsc to permit untyped code, the compiler doesn't even complain about it.
CoffeeScript has quite a lot of code generation features, while TypeScript largely just removes code in order to transpile to JavaScript. The only exception I can think of is enums, and I suspect they wouldn't have put those in if they had it all to do over again.
Which further exposes the irony of casual hipsters who say things to me like "Thank God for Typescript, it's like a whole other language than JS". For example, a designer, who writes a quick one off plug-in for Figma in Typescript without realizing 99.9% could have been just written/pasted into the JS file (which is ultimately what Figma runs).
To be honest, in the appropriate context I will contradict myself and say that that you should think of TypeScript as a separate language. There's a lot of dynamic things you can do in JavaScript that will interact poorly with attempts to statically reason about your code with TypeScript; even if it's the approach you'd take in JS, when you add typing you should recalibrate how you approach the problem - that, to me, is an argument for thinking of it as separate language.
...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.
Because TypeScript is the de facto standard way of writing JavaScript for most of the industry and it has killed all of the other compile-to-js languages.
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.
> Because TypeScript is the de facto standard way of writing JavaScript for most of the industry
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.
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.)
Not that I think download metrics is the best metric to decide that, but even with that, flow-bin has almost half a million of downloads per day. That's far away from dead, at least in my world. And I'm guessing that doesn't count anything from Facebook as they most likely run their own registries.
Don't you find it interesting that node-fetch is slightly less-dead otherwise has exactly the same "aliveness" as typescript [0] from your source (click 5 years)?
I don't want them to "learn JS." Most likely the person in question is trying to write web applications, and I want them to learn what is most useful for that. After writing web applications for years without TypeScript and then for years with it, I cannot imagine going back. I can make complex refactors with very little worry. Thanks to type inference, most of the TypeScript code I write is indistinguishable from JavaScript, so the idea that learning TS takes away from learning JS is ridiculous. When I suggested that the extra syntax might be distracting at first, I meant for like... a week.
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.