Type Annotations in JavaScript?
This year will mark the 10th anniversary of TypeScript creation and nowadays, it has become more and more used not only in big corporation projects but in small projects too.
To mark this event, the team who created TypeScript years ago has launched a new proposal to be added to the ECMAScript standard for type annotations, a possible solution for a type check in JavaScript.
This article with insights by Accenture explains the proposal at its first step to become part of the standard and be adopted by the browsers and IDEs. The project has many supporters, as static typing for JavaScript is still the most requested feature according to “the state of JavaScript” survey.
Dynamic typing vs. Static Typing
There are two kinds of programming languages: statically typed and dynamic ones In the static ones, variable types are known at compile-time and in most cases have to be specified when initializing a variable. In dynamic ones, type checking takes place at runtime or execution time and usually doesn’t require the type to be specified when initializing a variable.
JavaScript falls into the second category, being a dynamically typed language.
With JavaScript’s extensive usage in the large scale application, its use not only in frontend applications but in backend ones, type checking has become one of the major requested features leading to the creation of new tools like Flow or TypeScript.
It’s from this increased demand that a new proposal called ECMAScript proposal: Type Annotations was announced earlier this year.
What makes this proposal interesting, even if it’s only the first step in the process of becoming part of the EcmaScript standard, are some of its key features, and the team who created it, being the team behind TypeScript.
How Type Annotations work
What this proposal suggests is quite simple; let’s take a look at how we initialized a variable in JavaScript:
let myNumber = 12;
As it is right now, even if we want our variable to be a number it can be reassigned for example to a string and our IDE would not complain, with the possibility of introducing a bug or breaking some features.
With type Annotation the same variable can be initialized like this:
let myNumber: number = 12;
We are explicitly declaring it to be a number.
If we try to reassign it to be a string as before, our IDE will prompt an error and let us know, while we are writing our code, that this behavior is not something planned and that the variable should remain of type number, more or less what happens right now with TypeScript.
At execution time this new type declaration won’t influence how your code runs, this is because type annotations do not change the semantics of a program, and are equivalent to comments.
This is very similar to how JSDoc works, with type declarations as comments but with a more compact and clear syntax like TypeScript.
For reference, this is how we would declare the same variable in JSDoc:
/** @type {Number} */
let myNumber = 12; Code language: JavaScript (javascript)It would not require the scraping of type declaration like what happens now with TypeScript being the type syntax not natively supported in JavaScript.
What about Type Declaration
In the proposal, there is also the possibility to give particular names or aliases to types to be easily referenced with using the keyword type.
type CoolBool = boolean;
To create more complicated types of declaration, for example, when instantiating objects there is also, in the proposal, the introduction of the interfaces more or less like the ones already present in TypeScript.
interface Person {
name: string;
age: number;
}Code language: CSS (css)In this case, anything declared between the curly brackets {} will be entirely ignored at runtime.
The benefits of type checking
Why is this feature one of the most requested ones? Let’s look at some of the advantages of having a type check.
Types invalidate most of the silly errors that can inadvertently slip in JavaScript code and help identify them giving immediate feedback when writing new code or refactoring old code.
Think about, for example, a hidden error that only appears only when running like:
‘undefined’ is not a function.
Another significant advantage of making types explicit is to allow us to focus on how our system is built and how the different components of our code should work and interact with each other.
In large-scale applications, this leads to being able to abstract away the rest of the system while keeping the context in mind and writing a more correct and efficient code.
Having a visible type declaration helps significantly to read the code and understand what it should do. This is especially true in large-scale projects where orienting can be a nightmare. This can help to shorten the time to jump into an ongoing project for new developers and make it easier to refactor code without breaking it significantly.
The impossibility of JavaScript to incorporate things like types and compile-time error checks also made it a bad choice for server-side code in enterprises and large codebases with a lot of developers preferring other languages with a static type system.
The cons of Type Checking
So why not use TypeScript? Well, it also brings some downsides that the new proposal is trying to solve.
Some of the drawbacks of using TypeScript up to now are the possible lack of knowledge in the developer’s teams which requires time to be solved with training and/or study time, and the difficulties in migrating JavaScript projects to TypeScript.
Both of these can be seen as investments for the future but in the short run, these are two key factors to be evaluated and depending on the project schedule may or may not have an affordable solution.
These two problems could be partially solved with the introduction of this proposal, being type check conditional and leading to a less brutal change in the existing codebases. It also improves the change management strategies giving time to integrate the missing knowledge between the team members.
Another minor problem with the use of TypeScript has been the necessity to add various configurations in the initial phases of the project for transpiling the code from TypeScript to JavaScript to be used by the browsers. With this proposal, this problem may also be solved by having all the type checks ignored by the browsers and only used at compile time by the various IDEs.
Of course, the browsers should align to this new standard to be fully functional but the times also seem the correct ones where the end-users tend to have more up-to-date browser versions compared to the past.
Controversies and compromises
The main controversies come from two different groups of people: those who want a real static typed JavaScript and those who are widely open to having a dynamic only type.
The position against the first group (the ones who want to shift towards Static Typing) is simply that this kind of change would violate goals around web compatibility (i.e. “don’t break the web”), being this kind of change not only a breaking change for developers knowledge but for all existing applications too.
This could also completely replace other tools like TypeScript of flow, which is not the goal of this proposal since these tools have proven to be the ground for future implementation and further evolution of the language.
Let it out that a proposal for a full static typing system would never reach a full consensus between the developers.
On the other hand, it is undeniable that many organizations and teams have put a great effort into creating and using tools to obtain different types of type-checkers. A lot, of course, doesn’t mean all. That’s why to compromise with the second group of people, who want to maintain JavaScript a dynamic type language, this solution is entirely optional and won’t affect already existing applications nor would impose to use type annotation to those who don’t need it.
Is Type Annotation the future?
The main goal of this proposal is not to introduce TypeScript’s type-checking in every browser or JavaScript runtime but to propose a typed syntax that is compatible with and motivated by TypeScript, which any type-checker could use. A new syntax that JavaScript engines would skip over.
For sure, this is an interesting approach to one if not the most requested feature in JavaScript, which follows a similar path to python and its implementation, with a discrete success, of Type Hinting.
The times also seem mature for this implementation as the browser ecosystems are very different from what they were in the early 2010s when ECMAScript 4 (which had a similar proposal) failed. Back then it was unclear how long we would be stuck with ancient versions of Internet Explorer and many other browsers weren’t receiving as many updates as we are used to today.
If this proposal passes all the four stages I can see many TypeScript codebases move back and align with this new JavaScript.
