• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer
Codemotion Magazine

Codemotion Magazine

We code the future. Together

  • Discover
    • Live
    • Tech Communities
    • Hackathons
    • Coding Challenges
    • For Kids
  • Watch
    • Talks
    • Playlists
    • Edu Paths
  • Magazine
    • Backend
    • Frontend
    • AI/ML
    • DevOps
    • Dev Life
    • Soft Skills
    • Infographics
  • Talent
    • Discover Talent
    • Jobs
  • Partners
  • For Companies
Home » Frontend » JavaScript » JavaScript: A First Look at the Type Annotation Proposal
JavaScript

JavaScript: A First Look at the Type Annotation Proposal

Read on to discover details on how the TypeScript team aims to include Type Annotations in JavaScript, one of the most requested features.

June 3, 2022 by Codemotion

JavaScript, typescript, type annotation, type checking, static typing

 

Table Of Contents
  1. Type Annotations in JavaScript?
  2. Dynamic typing vs. Static Typing
  3. How Type Annotations work
  4. What about Type Declaration
  5. The benefits of type checking 
  6. The cons of Type Checking
  7. Controversies and compromises
  8. Is Type Annotation the future?

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.

typescript, javascript, type annotation, type annotations, type checking
Static Typing is the most requested feature according to JavaScript users in a survey by stateofjs.

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 

typescript, javascript, type annotation, type annotations, type checking
Type Checking in JavaScript would bring both many benefits and also some downsides. The debate among developers is heating up.

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.

typescript, javascript, type annotation, type annotations, type checking
Voices against Type Checking in JavaScript argue that it goes against web compatibility.

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. 

https://www.codemotion.com/magazine/frontend/javascript/svelte-why-is-it-an-innovation-to-javascript-frameworks/

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.

facebooktwitterlinkedinreddit
Share on:facebooktwitterlinkedinreddit

Tagged as:Front-End Full Stack Developer

Are You a Soft-Skilled Developer?
Previous Post
Don’t Miss the Next Edition of our Devs Book Club with Matteo Pagani!
Next Post

Related articles

  • 5 JavaScript Frameworks to Follow in 2023
  • A Quick Guide to NextJS
  • Why You Should Use Typescript for Your Next Project
  • Increase Your Speed and Efficiency With These 20 Incredible JavaScript Tips and Tricks
  • Video: Let’s Build a Modern React Application
  • How-to Guide: Adding VueJS to Your Existing Project
  • Svelte: Why Is It an Innovation to Javascript Frameworks?
  • 6 Ways to Implement Metaprogramming in JavaScript with Proxies
  • The Ultimate Guide to JavaScript | Learn JS to Grow Your Career
  • Best JavaScript Alternatives for Web Developers

Primary Sidebar

Learn new skills for 2023 with our Edu Paths!

Codemotion Edu Paths for 2023

Codemotion Talent · Remote Jobs

Java Developer & Technical Leader

S2E | Solutions2Enterprises
Full remote · Java · Spring · Docker · Kubernetes · Hibernate · SQL

AWS Cloud Architect

Kirey Group
Full remote · Amazon-Web-Services · Ansible · Hibernate · Kubernetes · Linux

Front-end Developer

Wolters Kluwer Italia
Full remote · Angular-2+ · AngularJS · TypeScript

Flutter Developer

3Bee
Full remote · Android · Flutter · Dart

Latest Articles

web accessibility standards, guidelines, WCAG

Implementing Web Accessibility in the Right Way

Web Developer

devops, devsecops, cibersecurity, testing

3 Data Breaches in Web Applications and Lessons Learned

Cybersecurity

The influence of Artificial Intelligence in HR

Devs Meet Ethics: the Influence of Artificial Intelligence In HR

AI/ML

google earth engine

What is Google Earth Engine and Why It’s Key For Sustainability Data Analysis

Data Science

Footer

  • Magazine
  • Events
  • Community
  • Learning
  • Kids
  • How to use our platform
  • Contact us
  • Become a Contributor
  • About Codemotion Magazine
  • How to run a meetup
  • Tools for virtual conferences

Follow us

  • Facebook
  • Twitter
  • LinkedIn
  • Instagram
  • YouTube
  • RSS

© Copyright Codemotion srl Via Marsala, 29/H, 00185 Roma P.IVA 12392791005 | Privacy policy | Terms and conditions

Follow us

  • Facebook
  • Twitter
  • LinkedIn
  • Instagram
  • RSS