DEV Community

loading...
Cover image for Is TypeScript Really... A Language??

Is TypeScript Really... A Language??

Adam Nathaniel Davis
React acolyte, jack-of-all-(programming)trades, full-stack developer
Updated on ・6 min read

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

Discussion (38)

Collapse
sancarn profile image
Sancarn

I think we should ask ourselves, what's the definition of a "programming language". Typically, programming languages are formal languages (comprised of syntax and semantics) which perform operations on data. Does typescript tick those boxes? It definitely has a syntax, and that syntax has meaning. The syntax is different to JS so it cannot be seen as the same language as JS.

JSX on the other hand has syntax and semantics, but doesn't perform any operations. The operations are performed by embedded typescript/javascript. So i feel this is the distinction here. The same can be said of HTML <button onclick="var x=1; console.log(x)">, here we have an embedded language which performs operation, but the language HTML doesn't perform this data on its own accord.

Conclusion: TypeScript can be seen as a language with which you can perform operations on data. Therefore it can also be seen as a programming language. JSX, like HTML, can only be seen as it creates a syntax tree (AST/hierarchy) but doesn't perform any operations on data itself.

Collapse
bytebodger profile image
Adam Nathaniel Davis Author • Edited

I appreciate the feedback. But with all due respect, I think your characterizations of TS & JSX are a bit... incomplete.

I think we should ask ourselves, what's the definition of a "programming language".

I didn't really wanna get into this level of "nerd-dom" in the original post, but there are some pretty good definitions out there of what makes a programming language a "real" language. One of the most commonly used is that of being "Turing complete".

Comp Sci people like to throw around that phrase because it sounds haughty. But if you look into what's needed to be "Turing complete", it's incredibly simple. With the desire and a little bit of research, you, me, or most other programmers could actually spin up our own Turing complete language in a weekend. Most of the features we see in modern languages go farrrrrr beyond what's needed to be "Turing complete".

The syntax is different to JS so it cannot be seen as the same language as JS.

Is it really?? I know I'm oversimplifying here, but the main point where we see differences between JS and TS is in the interface between functions/classes and in the assignation of variables. Granted, in a typical TS (or JS) app, there are a lot of places where we're assigning variables or defining function/class interfaces. But even then, the only "difference" is that, in TS, you have to declare your types. But most of the basic language constructs look the same between TS and JS - because they are JS. TS doesn't have, say, its own syntax for while loops or switch blocks - because those constructs are JS.

For example, if you want to see how TS handles iterators and generators, you can look here: typescriptlang.org/docs/handbook/i...

Hmm... that looks a whole lot like... JavaScript. That's because it is JavaScript. In fact, there's nothing on that page that varies from core JavaScript - because it is JavaScript.

So if the "language" provides some features that allow for additional type security, but the core features (the ones that are needed to be "Turing complete") are all just JavaScript features, have you created a new, standalone language??

To put this another way, when you decide to use TS in your project, you install it, as a package. Correct me if I'm wrong, but I don't believe it's possible to run TS without JavaScript, right??

I'm not saying this kills the idea of TS being its own language. As stated in the original article, PHP only runs in C. But if I want to spin up a PHP project, I don't first say, "Hmm... let me get the C compiler installed and running first, and then I'll install PHP." All that C magic is happening silently in the background.

In fact, it's common to find junior PHP devs who don't even know that PHP ultimately runs in C. The obfuscation is so complete that it's entirely possible to program in PHP for years without ever thinking (or knowing) about the underlying C. Are there any junior TypeScript devs who don't actually know that TS is running in JavaScript? Is that even possible to be so oblivious???

Furthermore, even if you're a master PHP programmer, that doesn't at all mean that you could immediately switch to C and just know what you're doing. Much of PHP's syntax is ported directly from C. But there are still so many differences that the "Master PHP guy", trying C for the first time, would be quite lost for at least a little while.

But if you've only learned TS, and one day, for some reason, someone said, "Hey... this particular thing must only be coded in plain-ol' JS," how long do you think it would take you to switch to base JavaScript? A day? A few hours, maybe? My contention is that the transition would be incredibly swift - because it's the same language.

JSX on the other hand has syntax and semantics, but doesn't perform any operations. The operations are performed by embedded typescript/javascript.

If you're saying that a JSX tag is actually a function call, then yeah, I agree with you there. But just as TS provides some syntactic "flair" to the way that we assign variables, JSX provides its own syntactic "flair" to the way that we call functions.

The same can be said of HTML

I'm not quite seeing the analogy. HTML is a markup language. And by browser convention, it can be used to call JavaScript functions based on user actions (or, to embed JavaScript code right alongside the markup).

When you do this in JXS:

<UserDetail userId={someUserId}/>

You're not embedding a JavaScript call inside of some static markup. <UserDetail userId={someUserId}/> is a function call. It's functionally equivalent to:

UserDetail(someUserId);

Maybe this is splitting hairs, but the distinction feels significant (to me).

JSX, like HTML, can only be seen as it creates a syntax tree (AST/hierarchy) but doesn't perform any operations on data itself.

You didn't say this directly, but I feel like this statement conflates the markup of HTML with the function calls of JSX - which are only made to look like markup tags.

None of this is meant to "tear down" your arguments. In typical nerd-like fashion, I find the debate/discussion to be very interesting. And I truly appreciate your feedback.

And despite what might be inferred from my original post, I'm not trying to argue that JSX should actually be considered to be its own language. I'm only questioning whether TS has actually cleared that bar.

Please let me know where I've got it wrong!

Collapse
sancarn profile image
Sancarn

I didn't really wanna get into this level of "nerd-dom"

In order to answer the question "Is TypeScript really a programming language", you need to define what you mean by a programming language. I don't see this as nerdy. It's like asking "Is a cod an animal?" will always depend on the definition of what an animal is.

The syntax is different to JS so it cannot be seen as the same language as JS.

Is it really???

A syntax is made from a grammar. The grammar of TS and JS are different. E.G.

function greet(greeting: string): string {
   return greeting + " world";
}

is not valid JavaScript. This is because types are not part of the JavaScript grammar. Because the grammar is seperate, the syntax is seperate and thus the languages are seperate. You wouldn't call C and C++ the same language just because their for loops look the same. C is very different to C++ even though they may act in similar ways.

Correct me if I'm wrong, but I don't believe it's possible to run TS without JavaScript, right??

You can, compile to WASM.

But if you've only learned TS, and one day, for some reason, someone said, "Hey... this particular thing must only be coded in plain-ol' JS," how long do you think it would take you to switch to base JavaScript? A day? A few hours, maybe? My contention is that the transition would be incredibly swift - because it's the same language.

The switch from Java to C# is virtually instant. Arguably more so than from TS to JS. That doesn't mean Java and C# are the same language though.

You're not embedding a JavaScript call inside of some static markup

I beg to differ. I'm not talking about what is actually hapenning under the hood. I'm talking about the semantics of the language. Like let's take a look at HTML:

<button onclick="console.log('hello world')"/>

semantically can be seen as: <button onclick="EMBEDDED JS"/>

Similarly in jsx:

<button onclick={()=>console.log('hello world')}/>

semantically this can be seen as: <button onclick={EMBEDDED JS}/>. Realistically JSX is embedding the JS (with the same syntax as plain JS) between the parenthesis {...}.

Don't get me wrong, HTML and JSX are still languages. They have their own syntaxes and semantics. The difference between them and languages like JS/TS/C/C++/C#/Java/Lolcode is that they merely produce templates, (or at least their common use is in creating templates).

JSX/HTML result in a template (or AST), it isn't generally seen as computing.

TS/JS result in a computed output.

It's a bit of a grey area, I'll give you that much as you might even be able to formulate a JSX expression which does compute, but as this is not its common/typical use case, I would argue it still can't be classified as a real programming language, akin to JS/TS.

Collapse
jwp profile image
John Peters • Edited

Sancarn,

Nice points. It made me recall an automated testing tool named QTP now renamed UFT.

Their documentation made a big deal of the words Imperative vs. Declarative programming techniques.

Is HTML a language? It's minimally a declarative one, just like JSX. It could be argued that Typescript is a declarative offshoot of Javascript. Ok by me...

No matter what we call this stuff, we have to learn how to 'speak and read it'. In that sense it's a language.

Collapse
elmuerte profile image
Michiel Hendriks

HTML is a language, a markup language. But not a programming language. HTML does not result in an executable program. Of course you can make an interpreter for HTML which imposes a specific grammar so that it turns into a programming language, but that would not really be HTML anymore. It would be another esoteric programming language.

Declarative programming languages are commonly based on the declaration of facts, rather than describing a control flow. SQL or Prolog are examples of declarative programming languages.

JSX is JavaScript mixed with markup. Basically syntactic sugar for templating markup. It doesn't not really define a new language as it's basically JavaScript with the requirement of a specific pre-processor for processing the inline templates. So it does make JSX a programming language language, but that's because it's essentially JavaScript.

TypeScript on the other hand is a new programming language. Just because its primary output is a different programming language, for which it also offers interoperability makes no difference. I think you can compare TypeScript to JavaScript as you can compare C++ to C.

To continue on about JSX, TypeScript also has a "JSX" mode where the XML templating of JSX is supported in TypeScript, so basically TSX. Is TSX a new language? no, it's part of TypeScript.

Thread Thread
jwp profile image
John Peters

I try to stay away from minute definitions of a language, as I see no value in the discussion. If I need to read, write, speak or hear about something in order to understand and synthesize; then to me, I'm speaking a language.

Some cultures mix English with their native language. To us it a non-understandable mix of two, but to them it's a perfectly legitimate way to communicate.

Thread Thread
elmuerte profile image
Michiel Hendriks

I'm a programmer, an engineer. Being as much as correct, or maybe clear, as possible is in our nature. Making clear distinction in kind of languages is important. This isn't about making one kind of language inferior to the other. It's about setting boundaries in domains. Ambiguity is a huge problem. This is a primary reason why natural languages are extremely difficult to process. This is why TypeScript was made, weakly typed languages, like JavaScript, significant issues in correctness which strongly typed languages have not.

I live in a country where English, and other languages, are mixed with out native language. Especially for English we have grammatical rules how these borrow words are supposed to be transformed in various constructions. But mixing Dutch with English, German, and French has no absolutely no effect on the type of language which is applied. It is still the same kind of language, so called natural language. But even with language language, there is a special class dubbed legalese. It's a more formal application of natural language, but way less formal than languages commonly used by software.

Thread Thread
jwp profile image
John Peters • Edited

I don't disagree, but I do know that my knowledge of Programming languages has also taken on my own style in using them. It's similar to an accent in a spoken language. I don't feel that any one accent is better than any other; however; accent or not, if there's a violation in what is written or spoken; then that, and only that is of concern. It's exactly why I like Typescript because it makes me more cognizant of making things safer. The last thing I want to do (again) is to release a bug to production because of some really stupid accidental thing I did. I like Typescript coupled with Unit Tests because it builds confidence. I also love C# for Back-end work because it's safe.

Collapse
bytebodger profile image
Adam Nathaniel Davis Author

Here's another idea that, for some reason, only occured to me just now:

Is Flow its own language???

I've never heard someone say that they only like to code in Flow. In fact, such a statement would be borderline nonsensical. Because Flow doesn't run by itself. It only runs inside of JavaScript.

Now believe me, I'm not trying to delve into any kinda analysis about Flow vs. TypeScript. From my vantage point at least, it feels like TS, basically, "won". But there's still a lotta Flow-based code hanging around out there. And it's, by no means, a "dead" construct.

If JSX is not a standalone language (and I'm not actually claiming that it is), and if TS is a standalone language, why doesn't Flow have the same status???

Collapse
matthewbdaly profile image
Matthew Daly

I think Flow is a better approach than Typescript, because it doesn't try to be more than a type system for Javascript. It's just an add on for the language. However, I think both Flow and Typescript should be considered as transitional solutions.

In the longer term there should be a push in Javascript to add native support for some sort of type annotations for Javascript, and Flow annotations seem like a good starting point for that.

Thread Thread
bytebodger profile image
Adam Nathaniel Davis Author

In the longer term there should be a push in Javascript to add native support for some sort of type annotations for Javascript

This is basically how we got to TypeScript. A good while back, Microsoft was actively participating in the ECMA standards group, and they were all poised to introduce much of what we now call TypeScript as part of the next ECMA spec. But at the last minute, there was a lot of debate and protest and MS's proposed changes got pulled. Eventually, MS released them as its own open source project - and now we have TypeScript.

Collapse
jwp profile image
John Peters

Nice article Adam. My thoughts are, that because Javascript is not a strongly typed language; we know that once Typescript is transpiled to Javascript, that the whole strong type argument fails.

But what is compelling about Typescript typing is that intellisense works as we type. Visual Studio Code automatically discovers all Properties. Functions, and Class types and their types needed to work. Its this interaction that preserves the illusion of strong typing. One simply cannot; for example, mistake strings for numbers or objects; (except for the type of 'any'. ) which restores ambiguity if desired
This means that Typescript can behave either way.

One may want to quantify the advantage of design time strong typing. The answer lay in the effort lost in finding run time errors where something expected didn't happen. When those issues are flagged at coding time we save an entire cycle of effort.

What's also interesting, is that most backends are Java, C#, or some other strong typed language. Even SQL is strong typed. It's much easier to map a backend model to the exact same strong type GUI side model. Some translation required e.g. number => int. Etc. But the conversion there is simple.

Finally there are 30 years worth of strong typers around. They are very comfortable with Typescript; which, allows them to ramp up much faster.

Today, I like Javascrpt but I believe its use as just a scripting language contributes to the messes I had to deal with in code. That code was just 3 years old. The first questions I had were didn't these folks ever hear about SOLID or even DRY. Didn't they know that monolithic code is immediate technical debt?

Why was JQuery so popular? The answer is it gave nouns to nameless objects. Why was Angular 1.0 so popular? Answer... it was the first to introduce binding concepts to Javascript world. Binding already being known by strong typers for 15 years before Angular.

Strong typing brings discipline to the table and it stops ambiguity of the untyped Javascript Object. Do we absolutely need it ? No, but some of us want it.

Collapse
bytebodger profile image
Adam Nathaniel Davis Author • Edited

Oh, man... good thoughts and good feedback. I think I agree with everything here, and I won't regurgitate it, but there are a few points that struck me:

But what is compelling about Typescript typing is that intellisense works as we type.

I sooooo get this. About 7 years ago, I was writing a lot of PHP code in my free time on a huge side project. As I tended to do every couple of years, I reached a point where I said, "Let me reassess the IDE options that are out there." And that was the first time that I stumbled across JetBrains (and their PHP-specific IDE, PHPStorm). It's not an exaggeration to say that it transformed my code. Because PHPStorm was the first IDE I ever found that did an amazing job of discovering all of my loosely-inferred types in PHP. And once I realized that the IDE could ferret this stuff out, it incentivized me to actually write code that would better "mesh" with PHPStorm. And when I say that it "meshed" with PHPStorm, what I'm really saying is that my code became much more explicit in broadcasting to the IDE (or to other devs who found themselves slogging through my code) exactly what type of variable they were looking at.

Finally there are 30 years worth of strong typers around. They are very comfortable with Typescript; which, allows them to ramp up much faster.

I'm nodding my head. And I'm also a little bit chagrined. As one of those "grey-beard" developers, I can tell you, in React, what really groks in my mind - class-based components. They just kinda... make sense. I don't have a "problem" with function-based components. But soooo many times, the class-based paradigm seems to better "fit" what React defines as a "component".

But I know some hardcore TS fans who will try to shout you down over the use of that ugly, nasty, unthinkable class keyword in their React components...

Strong typing brings discipline to the table and it stops ambiguity of the untyped Javascript Object. Do we absolutely need it ? No, but some of us want it.

I totally understand and respect this comment. Good points - all of them.

Collapse
jwp profile image
John Peters • Edited

Adam...

Your statement on finding a tool that really helped and incentivized you to 'lean into it to get more out of it', resonates with me (to the moon and back).

My first experience with this concept was back in 1988. I had put out a production bug that cost millions to fix. I was so upset at myself I went to their huge on campus tech library and checked out every book they had on software testing. This book changed my carrier and confidence levels.

I learned how Unit Testing objectives made my code bullet proof. So I leaned into the concept more and more thoughout my career. It was a major boost all the way around.

Today, I still willingly embrace unit test, as there's no substitute for it.

Collapse
citizen428 profile image
Michael Kohl • Edited

But soooo many times, the class-based paradigm seems to better "fit" what React defines as a "component".

That's interesting given that the first prototype of React was written in SML, a language that doesn't have classes. I also recommend Jordan's talk "React to the future", where he explains about ReasonML exists and why he sees React's future there.

youtube.com/watch?v=5fG_lyNuEAw

Thread Thread
jwp profile image
John Peters

reasonML

type schoolPerson = Teacher | Director | Student(string);

let greeting = person =>
  switch (person) {
  | Teacher => "Hey Professor!"
  | Director => "Hello Director."
  | Student("Richard") => "Still here Ricky?"
  | Student(anyOtherName) => "Hey, " ++ anyOtherName ++ "."
  };

Now that's refreshing to see.

Thread Thread
citizen428 profile image
Michael Kohl

You may enjoy this then:

stackbuilders.com/tutorials/reason...

Collapse
isaachagoel profile image
Isaac Hagoel

I am surprised that no one mentioned C++ that started off as a superset of C ("C with classes").
I think both typescript and C++ had the same motivation for taking that approach - luring in the existing user base and lowering the transition cost/ risk. Needless to say, it was successful in both cases.
I see why you doubt how much of an actual language it is. It feels very wonky at times and adds very little besides types. It is not at the same league as C# or Java (because the types are shoehorned in rather than being part of the foundation that everything else is built around). That's the price of backwards compatibility with Javascript I guess.
Making a static language dynamic is a much easier task than the other way around. For example Groovy and Clojure are dynamic languages for the JVM that have good interoperability with Java. They just use Object as the type for everything under the hood afaik)

Collapse
bytebodger profile image
Adam Nathaniel Davis Author

Good points. The more I think about it, there's no shortage of "Superset Of-" languages. That is, after all, part of the evolution of programming.

And I suppose I am more-than-a-little hung up on what TS seems to be bringing to the table. It's typing - and... that's about it. And, AFAIK, there's no way to just run TS. By itself. For the time being, at least, it actually requires you to have a JS runtime for it to work. That feels to me like... a package.

I'm realizing that one of my personal definitions for a standalone language is that it can run... standalone. Or at least, it should be "standalone" to the casual observer. I understand that one language may be completely dependent upon another - but if I have to manually supply the runtime for the 1st language, then it doesn't feel to me like the 2nd language is really much of a "language" at all.

Collapse
rrbs_s profile image
rs.s • Edited

Is C# a language? It allows both dynamic and static typing, just like TypeScript. The dynamic keyword was introduced in C# 4.0.

Is C# 3.0 a REAL language while C# 4.0 is not a language, just some framework written by a developer ranting about only having strong typing?

My opinion:
Just because something is a superset of another language does not mean it is not a language.
If JS creators would create ”JS2.0” with strong typing, would it not be a language? Only difference is that TypeScript has another name (just a branch of a language I’d say)
Whether one likes/dislikes static/dynamic typing is of no influence on the definition of language.

Collapse
bytebodger profile image
Adam Nathaniel Davis Author

Agreed on all points. I would only follow up with one question:

Is C# 4.0 a separate language from C# 3.0??

And yeah, I know that this comment (and this post) is insanely semantic. But I've never seen anyone list C# 4.0 and C# 3.0 as separate languages. But the common convention seems to be that TypeScript is commonly referred to as a separate language.

Is it somehow "bad" or "harmful" that TS is usually referred to as a standalone language?? No. But these are just the kinda nerdy things that occasionally keep me up at night.

Maybe I just need to fix myself a stronger cocktail...

Collapse
rrbs_s profile image
rs.s

Is C# 4.0 a separate language from C# 3.0??

Yes ;)

Collapse
raulmarindev profile image
Raúl Marín

Thank you for the article 😊, it has made me think about TypeScript from a different angle. My conclusion is that I don't mind if it's a different language or not and I don't want to invest time in trying to figure it out 😂. As a very pragmatic person, what matters to me is if a certain tool, in this case, TypeScript, makes my work easier or not. For those interested in the static typing vs dynamic debate, TypeScript has a pretty cool "Type Inference" in place so you don't need to be specifying a type everywhere. The type is inferred by the context in your code. You can check out more info about it here: typescriptlang.org/docs/handbook/t.... For example, in a React component, you can write "const dispatch = useDispatch();" or "const [searchTerm, setSearchTerm] = useState('');" and it works. The type of the variables is implicitly set thanks to the value you are assigning to them.

Collapse
khrome83 profile image
Zane Milakovic

Not sure this is much of a debate. It’s a language, it just gets compiled during a build process instead of being interpreted. Unless you use Dino, which I think runs it natively. It’s design to look and feel similar to JavaScript, because it’s a super set. And they change the language to match the future features in JavaScript.

Collapse
georgedel profile image
georgedel • Edited

I'm coming from the C# world and Typescript makes a lot sense to me. To me, Typescript is a version of C# dedicated to the front-end. I have Typescript in mind as a way to write javascript in a more secure way.

I agree, it's not a battle between javascript and Typescript, the thing is to know when to choose each technology regarding the needs of the project.

Collapse
bytebodger profile image
Adam Nathaniel Davis Author • Edited

I totally agree with you. And as I stated in the article, I have some significant C# experience myself. Maybe it's that experience that keeps me from levelling any of the "standard" complaints against TS (e.g., "It's much more verbose and it's harder to read.") And I was being sincere when I stated that I'd like to get some experience working on TS projects. (For whatever reason, all of my new gigs over the last 4-5 years have been in React shops where the decision had already been made to not use TS.)

This is why I'll freely admit that my little internal debate about language-or-not-a-language is almost certainly arbitrary. But I figured it might be fun to solicit some thoughts from the Dev.to community regarding my little "hang-up".

Collapse
georgedel profile image
georgedel

I know what you mean. I did a lot of Angular projects, where Typescript is a dependency anyway. But even in some VueJs projects, I used the TS option as well. I guess old habits die hard!

Collapse
seanmclem profile image
Seanmclem • Edited

The why does it matter? is strong with this topic

Collapse
andrueandersoncs profile image
Andrue Anderson

Is Typescript really a programming language? Hmm. Interesting question! My instincts say yes, mainly due to the compilation (transpilation?) step, the added semantics, the additional syntax, and the additional keywords. The fact that it (com/trans)piles to JS is irrelevant in my mind due to the reasons you pointed out in the article. Many languages transpile to JS these days. It all becomes machine code eventually. Even looking at running code on any machine one can see that code and data are indistinguishable. So the answer for me is yes, if only because of the added language constructs (namely, type and interface.) If JS itself could process these constructs without a transpilation step I would consider them to be the same language. If these constructs were implemented as functions (and I could think of ways one could go about that) then I would consider it to be a framework.

Really liking the train of thoughts! Write something on class vs functional components, I really wanna get into the weeds on that. I have lots to say on the benefits of functions ;)

Collapse
bytebodger profile image
Adam Nathaniel Davis Author
Collapse
cryptoquick profile image
Distributed Hunter Trujillo • Edited

Ah, yes, yet another is "CSS/JS/HTML,etc. a language?" post on dev.to.
is this a programming language

Collapse
bytebodger profile image
Adam Nathaniel Davis Author

I haven't seen those other posts on Dev.to and didn't realize that this was kinda "a thing" around here.

Collapse
tarvk profile image
Tar • Edited

Okay so here is my main question;
Would TS have been more of a language if it defined its own syntax from scratch?
It would still compile down to JS and have all the same runtime characteristics.

In my opinion there would be no doubt about it being a separate language if it defined completely new syntax and compile to JS. And to me the fact that it took JS as a basis for the language, rather than making up its own new syntax doesn't make a difference at all. It just made it easier for developers to switch to TS, that's all. So I personally do really think TS is its own language.

Collapse
jwp profile image
John Peters

I agree. To me, a language is something we read, write, speak or hear. It's a dialect which, after being learned, is simple to use for communication.

I even speak Bug... oh nooo, bad news, snafu, yikes, unbelievable, stupid, inane, clueless.

In Bug there's no verbs, no prepositions, just adjectives. Everyone understands Bug.

Collapse
hugecoderguy profile image
Christian Kreiling • Edited

Whether or not TypeScript is a programming language isn't so much up for debate, in my opinion. It's a JS superset, so all JavaScript is also valid TypeScript, but not vice-versa. This is because TypeScript is gradually typed - a cool area of research if you ask me.

I think a more adventurous question to ponder is whether or not TypeScript is a suitable replacement for JavaScript for developing applications that run on a standalone JS engine (e.g. Node) or in a browser. I think a useful approach to this question is to think about the pros vs. cons of JavaScript, and seeing how many pros hold up and how many cons go away by simply adding TypeScript.

Rather than get into that debate, I'd like to point out some frontend alternatives to developing in JavaScript and TypeScript:

  • Phoenix LiveView: some would argue we've gone full-circle in web dev - everything was rendered on the server (SSR), then everything was rendered on the client (SPA), and now we've come to realize that a hybrid approach is probably best for 90+% of new projects. LiveView not only brings server-side rendering back, but also manages client-side state on the server. It's a no-JavaScript, just-add-water approach to rich client experiences.
  • Elm lang: Elm is a functional, immutable language that also compiles to JavaScript. Though it's a language, it is also like a framework in that its underlying architecture is reactive, i.e. events and event handlers are pretty much language primitives. This is so powerful because there's no architecturally complex rendering layer between the developer and the language, such as React and Angular.

Personally, I think that TypeScript is a popular embodiment of very interesting research into gradual typing, but not much more. Adding types to JavaScript is definitely a cool feat (in the 90's I bet it'd have been a dream), but it does not solve many problems that are inherent to developing in JavaScript like evaluating variable equality and lack of an intuitive & expressive concurrency model. Dynamic vs static typing is a matter of preference - there is not and never will be a winner or a loser in that debate. Instead I think it's more productive to look at other modern languages like Go and Elixir, and ask ourselves whether or not TypeScript really compares to them. My short and sweet answer to that is no, it does not :)

Collapse
damxipo profile image
Damian Cipolat

I do not think it is a language it is just a tool that uses JS and generates a code of a rather poor quality by the way. I think it could become a language the day they invent their own engine as google did with v8 and can directly understand TS, but for me it is still a super set of js and saying that it is a language is a joke for programming languages real. Personally I have used TS and it really provides little, it is quite ridiculous that they have not implemented something better with numbers and do not implement float, double. I think it's halfway there and I don't see why it becomes so popular. More could do a better try or let companies like google explore this better and be features of v8 at some point.

Collapse
bytebodger profile image
Adam Nathaniel Davis Author

But... what do you really think of TS?? :-D

Collapse
scottshipp profile image
scottshipp

I think the real question to ask is if the benefits of TypeScript outweigh its costs? What are those benefits? What are those costs? What does TypeScript help someone achieve that JavaScript doesn't? Who is that person and what are they like? What do we give up for those benefits? Might I want to pay that cost for those benefits maybe?

Most semantic debates have no useful outcome.