Goodbye Typescript, hello native typing for Javascript ✨
Tags: javascript
Published: 2022-11-30 11:09:29

Typing. Love it or hate it, it has many advantages: better DX (through intellisense auto-completion), better code  documentation, less time consuming errors. Its benefits greatly outweigh its cost, so why do some people still avoid it? One word: **Typescript**. You have to set it up and make sure your tooling is working correctly which can add a layer of frustration to any project.

So what if I told you that native typing might be coming to Javascript? Christmas is right around the corner and boy do I have a gift for you 🎅

## The proposal 📄

TC39 is the comity in charge of Javascript's specs - they help maintain and evolve the definition of JS. If you're curious, I wrote a section about them in a [previous article](https://dev.to/christopherkade/the-future-of-javascript-features-to-keep-an-eye-on-3d0h).
They recently moved the [Type Annotations proposal](https://github.com/tc39/proposal-type-annotations) to Stage 1 (out of 4), which means it's time to widely speculate on the impact and implications of this feature !

> As much as I love being dramatic, this will **not** sign the death of TS by any means, it will simply allow for cleaner and more reliable JS code for projects that don't plan on using TS or that wish to use both in conjunction.

## What will native JS typing look like if this proposal passes? 

It would be very close to what we currently have with Typescript and Flow, namely:

```js
// both parameters are numbers, and this method returns a number
function add(a: number, b: number): number {
  return a + b;
}
```

These annotations will not stop you from passing a string or any other variable type as parameter. They will be ignored at runtime and are just there as guidelines that can be used by 3rd party type checkers such as your IDE.

The argument for strict typing has its place in this discussion in my opinion. In its current proposal, these types are _just_ type annotations, which is something we already have thanks to JSDoc. So the question remains: why?

## What's the point? 🤷

We're in an odd situation: Javascript is one of the only languages that has us write in one language (Typescript) to then have it transpiled to another one (Javascript). These layers add complexity to any project, so the more tools we add to our _default_ tool belt, the better.

The need for Typescript creates a form of monopoly on current available tooling, where each and everyone of them needs to evolve with TS in order to not be left behind. The [State of the Octoverse 2022](https://octoverse.github.com/2022/top-programming-languages) shows the impressive popularity of Typescript in 2022, which means this need to evolve becomes almost mandatory for your linters, bundlers etc.

Having this feature already bundled with our dear Javascript will only make it a more complete package and help us slow down the obvious tooling bloat we're currently facing.

--- 

What do you think? Would you see yourself using this feature if it releases? What are the risks that come to mind, especially if you're an avid user of Typescript?

Feel free to follow me on [Twitter](https://twitter.com/christo_kade) (if it doesn't implode by the time you finish this article), it's always a pleasure connecting with some of you 😄