[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...
Top comments (40)
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.