A few weeks ago, the news that JavaScript would finally have its type system came like a bolt from the blue. A team whose members are, among others, responsible for creating TypeScript prepared a document proposing to introduce typing into JavaScript.

The environment, excited about such a turn of events, started celebrating… with a trace of cautiousness.

My reaction was less favourable, to put it politely. I felt like Grouchy Smurf, muttering, “I hate JavaScript types!” I decided to let my grouchy side speak for a little longer, hence this light-hearted blog post.

In the following paragraphs, I’ll share my concerns about upcoming changes and explain why I don’t see them through rose-tinted glasses.

Take it with a grain of salt, and let me know how you feel about JavaScript types!

Eagerly awaited

As underlined by the proposal's authors, there's no denying that typing has been one of JavaScript’s most anticipated features.

There are even charts confirming this trend in the documentation of the new functionality. Considering the reliability of the State of JavaScript report, the results are impressive.

It’s comforting that Pattern Matching, which I’ve also recently described, is the third item on the list, just behind the introduction of Standard Library. Yet, static typing dominates both positions, outperforming the competition by 800 points.

Well, it’s not unusual that sometimes we want something that’s not truly needed.

No wonder someone has finally addressed the problem. And it wasn’t some random crowd but the people who knew the topic perfectly. After all, they’ve been working on TypeScript — a superset that gives excellent possibilities to a relatively simple language, JavaScript.

While giving another language superpowers with an additional compiler is practical and fun to implement, making such changes to an existing language — one with a past — is a different story.

And the implementation part is what I mainly have on my mind.

Currently, TypeScript is a solution that some apply while others don’t. These various approaches are a bone of contention in the environment as projects without TypeScript tend to be immediately considered legacy.

The idea of introducing types emerged to turn this ugly duckling into a swan and clear up the problem. Everybody would write type-strong applications and refactor them instead of endlessly rewriting them.

Of course, nobody treats it seriously. This industry is all about rewriting applications.

The end of TypeScript as we know it?

The very example of how the idea of types was proposed shows what the process might look like in the future — a petition, four photos, a registration journal, coming into force, five meetings, four stages, and it’s done! After half a year, we finally have a new, generic Omit for correct typing.

It doesn’t sound appealing, does it?

Comparing this with the TypeScript release cycle, where we get new versions with fixes or functionalities every few weeks, it even looks disturbing.

TypeScript is a library, and this is how we can treat it, even despite its specificity. We decide which version to use when we add it to a project. If we’re not ready for some solutions, we can stick to an older version with guaranteed compatibility.

What will it be like when TC39 controls the development centrally? Someone will have to let go, and it will probably be JavaScript that will bet on backward compatibility, which is hardly a catalyst for growth.

I haven’t found any explicit declarations that the introduction of static typing would end the development of TypeScript. Yet, Microsoft's people responsible for TypeScript are the primary originators, so their priorities may quickly change.

Naturally, one technology will compete with the other, reaching a deadlock, and we can imagine how they resolve it in the long run.

Is there anything to wait for? 

Now, this is my greatest fear — is it worth it?

I don’t see any significant benefit of having static typing in JavaScript. At least not in this form.

It’s worth noting that type annotations will be checked while the application is built, but they’ll be treated as comments when the application is in a runtime environment.

Functionalities known from TypeScript that affect the JavaScript code, i.e. enums, won’t be presented in the first iteration of the proposition — precisely because of their “commentary” type.

There’s more. 

The type-checker will be “external to JavaScript.” It won’t be a part of the interpreter but… a superset?

As you can see, there are many uncertainties. You may get the impression that the main goal of this proposal is to standardise tools such as TypeScript or Flow. Is this really what respondents of the State of JavaScripts survey voted for?

Static typing in runtime, which could solve IO data uncertainty problems and consequently replace libraries like io-ts, would be the game-changer we want. 

Instead, we get a slightly more extensive syntax, similar to TypeScript, checked by an external type-checker like… TypeScript.

We’re not doomed to fail

Despite everything I’ve written so far, I keep my fingers crossed for the creators of this proposal. I hope they develop a model that will meet the community's expectations.

Static typing is indeed what JavaScript needs, and the massive popularity of TypeScript proves it. Still, if we want to reach a satisfactory level, we’ll have to undergo a series of iterations that won’t seemingly bring much value and will only be the basis for further changes.

The topic of typing isn’t new. In the specification of the never-published EcmaScript 4, there were related provisions. They were to depart from the existing JavaScript and introduce a new order without backward compatibility.

At the time, in 2008, people feared it would be too big a breakthrough, but we know now that it was actually a missed opportunity.

These days, there’s nothing else to do but to make up for the wasted years by trying to fill the gap.

This article has been translated from Polish with the consent and cooperation of the author. You can find the original text on Robert's blog: rduraj.dev.