Is TypeScript Really... A Language??
Tags: javascript, typescript, react
Published: 2020-04-18 20:47:03

[**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...