[Holy War Disclaimer: I'm not "pro-JavaScript" or "anti-TypeScript". And the questions I pose in this post are not designed to trash one or herald the other. And these questions aren't rhetorical - meaning that I'm honestly searching for the answer myself.]

Another post here on Dev.to got me to thinking about this subject. I'll freely admit that I haven't really done any coding in TypeScript and I've done a ton of coding in JavaScript. I have some... "reservations" about TypeScript. But a lot of those reservations come down to my own internal definitions of a programming language versus a library or a framework. So maybe those "reservations" are just my own internal mental block??

What The Documentation Says

Wikipedia defines TypeScript as "an open-source programming language developed and maintained by Microsoft". Wikipedia's not perfect. But it's fairly good on these kindsa "basic facts".

typescriptlang.org also defines TypeScript as "an open-source language which builds on JavaScript".

Every year, Stack Overflow publishes a list of the Most Loved/Dreaded/Wanted Languages. Very near the top, we see TypeScript. It also shows JavaScript. But it doesn't show React or Angular as a language option. So apparently their survey endorses the idea that TypeScript is, in fact, a separate language, while frameworks like React or Angular are just rolled up under JavaScript.

And Microsoft's github repo also lists TypeScript as a language.

So, I guess that settles it??

But the github repo also defines it as "a superset of JavaScript that compiles to clean JavaScript output."

Hmm...

In some ways, React "feels" like it meets the same definition. After all, React has its own language constructs (i.e., JSX) that won't run in plain-ol' JavaScript. But when you run that magic npm start command, everything gets transpiled down to "clean JavaScript output".

[NOTE: I fully realize that JSX is not inherently tied to React. You can use JSX outside of React. For the purposes of this article, I'll be somewhat haphazardly transposing React & JSX. Technically speaking, it's more accurate to say that React is a framework while JSX is a bundle of additional language constructs that often run in tandem with React. I understand the distinction. But it would be needlessly verbose to try to suss out the differences every time I type "React".]

Interchangeability

If you're not using TypeScript, but you're using React, you've no doubt imported a bunch of packages from NPM. If you look "under the covers" at what's happening in those packages, you'll find that a good number of them are written in TypeScript.

As a React developer, does this really matter much to you? Probably not. There's really no conflict in running TS-based packages inside your non-TS-based React app - because, at the end of the day, it all just gets transpiled down to JavaScript anyway.

Maybe this is a trivial distinction, but I've never peered under the covers of an NPM package to find that it was written... in C#, or Java, or Python, or any other language. That's because those languages don't natively transpile down to JavaScript. But TypeScript does. (There are some additional packages that transpile these languages down to JavaScript - but they're relatively rare.)

To be clear, I'm not trying to claim that, if your "language" transpiles down to another language, that you're not actually writing in a full-fledged language. PHP transpiles down to C. And I haven't heard anyone argue that PHP isn't a "language". There are numerous other examples of this where one language is built right on top of another.

And if we want to get really anal retentive about it, none of us are writing in an "original" language unless we're crafting our code in machine-level byte-code. But it still feels kinda strange to me that we call TypeScript a "language".

Why Does This Matter??

First of all, I'll freely admit that it probably doesn't matter. At least not to most people. And it certainly doesn't have much impact on your project if you've already chosen TypeScript or plain-ol' JavaScript as your platform.

When I'm writing React code, you can call React a "language" or a "framework" or a "banana cream pie". Whatever. Makes no difference to me. The only time that it even (sorta) plays in my mind is when I hear the TypeScript Acolytes talking about the Magical Awesomeness of type-certainty.

Don't get me wrong. Type-certainty can be powerful. I even wrote an entire article about how I "ensure" type-certainty in plain-ol' JavaScript without TypeScript. (If you care, you can read it here: https://dev.to/bytebodger/javascript-type-checking-without-typescript-21aa) I've also spent years working in Java (not really a fan) and C# (I really enjoy C#).

So imagine this scenario: Let's say that you're cranking out C# code in your awesome C# job and some guy comes over to you and says, "Yeah, you know... All this static typing is really tough for me to deal with. So you know what I did? I created a new library that we can import right into the middle of our C# projects that will somehow make everything dynamically typed."

First, anyone who says that on a C# dev team might be in immediate danger of being terminated. Second, even if this hack isn't run out of the company, I can imagine every C# developer saying, "Why would you possibly want to do that???"

You see, when you're working in a statically-typed language like Java or C#, the static typing isn't a bug. It's not something to be washed out of your code. It's a feature. There are some times when static typing can feel like a hurdle to be cleared. Occasionally, it's oh-so-tempting to think, "Mann... I really wish that I could just change the type of this variable right here on the fly." But any C# developer worth his salt will tell you that such minor inconveniences aren't a flaw in the language - they're a strength.

To this imaginary revolutionary, I'd most likely say, "It sounds like you need to get a different job where you'll be allowed to write code in a dynamically-typed language." I wouldn't say it in a mean or snarky way. I'd just say it as a matter-of-fact observation. Because if you're working in a language that's built on Core Principle X, and you don't like Core Principle X, the answer is not to rework the entire language so that it no longer uses Core Principle X.

The Distinction Between Languages and Frameworks/Packages/Libraries

Here's why I sometimes obsess about the question of: Is TypeScript really a language? Because, if TypeScript is truly its own language, and one of the Core Principles of that language is that it uses strong typing (not static typing), then I'd say, "OK, sure. Whatever. If you desire strong typing, and you've chosen a language built upon a Core Principle of strong typing, then... sure. I get that."

But if TypeScript is really just... JavaScript. And if you decided that JavaScript's dynamic typing is some kind of "bug" that needs to be washed out of the language. Well then, I'd look at you just like the supposed C# developer who's spending his nights and weekends trying to develop a library that would make C# dynamically typed.

As stated at the top of this article, this isn't some kind of Holy War. (At least not, in my mind.) I'm not mad at TypeScript developers. In fact, I'd sincerely like to get some experience on a TypeScript project. But sometimes I get just a little bit annoyed by the TS crowd that talks about their strong typing as though it magically washes away all their bugs. They talk about dynamic typing like it's a curse. But I firmly believe that JavaScript's dynamic typing isn't a bug. It's a feature.

But I suppose the dichotomy makes sense if we all accept that TypeScript is a full-fledged language in its own right. Because every language will have its own set of Core Principles. And if strong typing is a Core Principle of the TypeScript language, then... so be it.

I don't know. It's probably a pointless distinction...