[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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
I appreciate the feedback. But with all due respect, I think your characterizations of TS & JSX are a bit... incomplete.
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".
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
whileloops orswitchblocks - 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.
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.
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:
You're not embedding a JavaScript call inside of some static markup.
<UserDetail userId={someUserId}/>is a function call. It's functionally equivalent to:Maybe this is splitting hairs, but the distinction feels significant (to me).
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!
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.
A syntax is made from a grammar. The grammar of TS and JS are different. E.G.
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
CandC++the same language just because theirforloops look the same.Cis very different toC++even though they may act in similar ways.You can, compile to
WASM.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.
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:
semantically can be seen as:
<button onclick="EMBEDDED JS"/>Similarly in jsx:
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.
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.
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.
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.
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.
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.
Here's another idea that, for some reason, only occured to me just now:
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???
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.
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.
No, it's not.. for the exact reasons Adam mentions in his comment replies. As soon as I got on my first TS project in the wild and had to take a deeper dive, the first thing I thought was "wait, so this is all just JS in the end". I thought we used to call stuff like that 'syntactic sugar' or frameworks or something similar but either way, to call TS its own entire language right away felt immediately off to me.. Again for the exact same reasons mentioned in these replies. Not sure how its even much of a debate but I guess when your Microsoft its pretty easy to get most of everyone to agree with you.
Hi @philipbeauford,
Welcome to the community! It's great to have you here. Thank you for your first comment and for sharing your thoughts on TypeScript. It's always interesting to hear different perspectives on programming languages and their classifications.
I hope you enjoy being a part of the community and feel free to share your thoughts and ask any questions you may have.
Best,
Jean-Luc
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.
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:
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.
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
classkeyword in their React components...I totally understand and respect this comment. Good points - all of them.
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.
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
Objectas the type for everything under the hood afaik)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.
I'm not qualified to know if it's a full fledged language or not, but you can't compile it to binary and I'm not aware of a runtime for it, not raw at least. Those facts slot it in a certain category in my mind- and I can't really help that.
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.
Agreed on all points. I would only follow up with one question:
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...
Yes ;)
reasonML
Now that's refreshing to see.
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.
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.
Yesss, does the person who writes PHP knows C? NO, isn't PHP C at the end? Yess, do you write your PHP code and then use the resulting C code in your projects? Hell no.
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.
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.
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.
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".
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!
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,
typeandinterface.) 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 ;)
You mean, like this?
dev.to/bytebodger/a-hooks-vs-class...
Or this?
dev.to/bytebodger/reinventing-the-...
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:
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 :)
The
why does it matter?is strong with this topicI 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.
But... what do you really think of TS?? :-D
Ah, yes, yet another is "CSS/JS/HTML,etc. a language?" post on dev.to.
I haven't seen those other posts on Dev.to and didn't realize that this was kinda "a thing" around here.
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.