Hey everyone, Welcome back! I hope you all are doing good. So this change is big. This is a huge announcement from Microsoft. They’re trying to extend the support of TypeScript type syntax in JavaScript. Now, what does this mean? Does this mean that you can drop TypeScript? Does this mean that JavaScript is becoming TypeScript? Let’s discover that in this article. We’ll be covering this blog post which is an official announcement from somebody from Microsoft. So let’s just go ahead and see what this is about.
Table of Contents
What is TypeScript?
I’m assuming that you know what TypeScript is or at least you know what JavaScript is. If you don’t, then it’s a problem because I’m assuming that. So for those of you who don’t know what TypeScript is. It’s basically a Type system built on top of JavaScript which is not enforced on runtime, but it’s more like a developer experience type system. It increases your developer experience of coding in JavaScript. I believe like after a certain point if you’re working with a pure JavaScript project without external tooling like TypeScript, it’s fundamentally impossible to scale at beyond a certain level. It’s just become too hard to refactor untyped JavaScript code.
TypeScript is a separate system
But anyway, what’s happening is that TypeScript used to be a separate language or a separate you know, system in itself, right? You would have to compile down the TypeScript to JavaScript for which you would have compilers like Bable and, you know, SWC for example. These things are coming up with rust implementation of TSC and so on. So you would have to compile it down to JavaScript and then you ship it to the browser and then the browsers have V8 and SpiderMonkey and you know what have you these engines inbuilt of them which run this JavaScript code and execute the machine code, which means that you see that interactivity and buttons on the screen which are potentially created by JavaScript. So this is what today’s world looks like. What these guys are proposing is that, why do we need this compilation step at all? I mean with TypeScript, can we not directly executive the code which you have written with the types without the runtime security in the browsers themselves.
So what this means essentially is that effectively what we’re doing in this proposal, which is still a highly, stage zero proposal, you can see it’s a new state proposal. But you can see that, for example, if I am writing the JavaScript code and shipping this to the browser, all I have to do is just, in my IDE (Integrated Development Environment) like VS Code or whatever, you will get a nice typed completions, A number, B number you will have this number as well. But when your browser is actually running it also running the same code. Remember that there is no compilation step. That means this is not removed. There is no Babel involved, there is no TSC involved, nothing is involved. So this is not removed. Your browser actually sees this and chooses to ignore this. So it’s almost like how we work with JS TOC or how we used to work with JS TOC. It was a way of just declaring what your function parameters are, its return type, the description is, and so on. And then your IDE would automatically IntelliSense that, plug it in wherever you are using that. But TypeScript obviously has a much, much, much broader reach than JS TOC and it is a more complete system as well feature-wise. So moving forward, if this proposal is adopted, it’s still very early, but moving forward if this is adopted then you could technically write TypeScript directly within the browsers by avoiding this compilation step at all.
And this is, in fact, a huge deal because the TypeScript compiler is, in fact, slow, at least for the build times. It will improve your speed a lot. TypeScript takes a long time to compile because it’s written in JavaScript and it hits its bottlenecks when there are a lot of files. Sure, I mean there are efforts going in the Rust and Go world for writing a native TypeScript compiler, but this proposal is also interesting in a way that you don’t even need to compile it down at all.
No type-checking enforcement
As I said, a very important point here to note is that there is no type-checking enforced in the JavaScript runtime. Because that will totally defeat all the performance optimization and everything, and the language itself, I mean JavaScript is not a statically typed language, it’s a dynamically typed language, so all the optimizations and V8 and hacks and everything which has been implemented so far that would be useless. So this is just a way to ignore the types and you jt can just ship on JavaScript and the browser will take care of the rest of the stuff. It’s just that you would move one compilation step from the pipeline.
You can see over here that it mentioned that this proposal is not proposing putting TypeScript type-checking in every browser and JavaScript runtime which is super important performance-wise, you know language-schematic-wise, syntax-wise, and everything. It’ll create tons of issues. Obviously, this is not a solution. It is just a lazy way to ship TypeScript files to the JavaScript world without any changes.
Comments
Now there are obviously some interesting comments on this one of those mentions that unless there’s a one-to-one match with TypeScript, we’ll still need to transpile everything because obviously if there are some parts which you can write only in TypeScript, then it does not make a lot of sense. And it, in fact, mentions here that we would not be actually writing or we will not be actually compiling down enums, namespaces, and parameter properties will be out of scope because they have observable runtime behavior, right? So these things in TypeScript should actually modify your runtime behavior as well. Therefore we will not be having those sorts of things available in the JS runtime itself. And obviously, that begs the question that what will happen then if somebody is writing an enum? Because that will not be supported in a JavaScript file. So anyway you have to compile it down to a JavaScript file, so what’s the use of that?
The obvious response is that not every project uses or will use those unsupported features. So that’s a starter. This is still a state 0 proposal. We should not really expect a lot of clarity on all the details. That’s why there are stages in the TC39. So let’s see how everything goes.
So this is about it for this article. This is a shockingly good update. I think it’s a big one. It’s a big, big update and it’s a very early stage but still, we will see its implication probably in the next few months. I don’t know how much time it’ll take to move to stages 1, 2, 3. But hopefully, it moves because we’ll love to see TypeScript executing directly in the browsers themselves.
Thank you for reading this blog. Share this with your friends!