Toggle Menu

Insights / Tech Tips / TypeScript vs ES6 vs ES2015

October 27, 2016

TypeScript vs ES6 vs ES2015

11 mins read

In this article, I’ll be giving you a bit of context on why ES6, ES2015, and TypeScript exist and will provide some concrete examples of key language features to help you make your mind up on what the right solution is for you.

A Brief History of ECMA

First things first, we need to define our terms. JavaScript (or JS) is an implementation of the ECMAScript (or ES) standard, which is maintained by ECMA International, a consortium of tech companies that include Adobe, Google, HP, IBM, Intel, Microsoft, PayPal, Yahoo, Apple, Netflix, Twitter – basically the internet as you know and love it. The last major version of ES was ratified in 2009 as ES5, so in 2015 when the ratification of ES6 happened, it was a huge deal.

At some point in the past couple of years, ECMA realized that the web will be rapidly disrupted regardless of the technology behind it. In response, ECMA decided to rename ES6 as ES2015 to set the stage for yearly updates to the language that has a run-time on pretty much every piece of hardware produced in the world. Along the way, Node.JS happened and language features of ES are now more important than ever because JavaScript is loosely and dynamically typed. We all know what happens when you aren’t a bonafide JavaScript expert.

What is TypeScript?

You may have recently heard of TypeScript as a new language that you need to learn, because Angular 2 is using it or you heard about it several years and chose to ignore it. If you’re like me, you resist learning new things and you despise using unproven technology. I actually use these tendencies to my advantage to filter out the cruft from the JavaScript-Framework-Of-The-Week™ sideshow. By being selective I can afford to deep dive into certain technologies, which unlocks the full power of these amazing technologies, so I can be more productive as a developer.

a logo

Long story short, TypeScript is JavaScript with type definitions bolted onto it, but the kicker is the types are optional and you can use TypeScript typings (which is a thing) in your JavaScript code without using TypeScript. Confused yet? There’s more. TypeScript is also a super-set of ES5, ES2015, ES2016 and future JavaScript functionality with the capability to compile down (aka transpile) to ES3 or ES4 to be able to run on really ancient browsers.

At BUILD 2016, Anders Hejlsberg, the inventor of C# and TypeScript, put it aptly: It benefits developers and users to use a transpiler like TypeScript to bridge the compatibility and productivity gap. In March 2015, everyone thought once the state of web JS caught up to the state of the art JS, we wouldn’t need transpilers anymore.


As I mentioned earlier, ECMA decided to adopt a regular update cadence for JavaScript, which means in March 2016 even if the state of web JS has caught up, but the state of the art JS continued moving forward. This is called the feature gap.


Transpilers like TypeScript, Babel or Traceur aim to close this feature gap. TypeScript outshines the competition from a transpile perspective because while Babel or Traceur are great tools that you can install into your IDE/text editor or build a pipeline, they can be buggy and debugging can be problematic. TypeScript in tandem with CLI tools and Visual Studio Code offers a solid development experience.

Solid Support

TypeScript has the advantage of receiving first class support by two tech giants, Google and Microsoft. Both at BUILD and Ng-Conf 2016 I’ve heard program managers say that they can’t imagine large-scale JavaScript development without TypeScript. Microsoft put this to test by implementing a new project in TypeScript, in the process creating a solid IDE and debugging experience for TypeScript itself, namely Visual Studio Code.


Google, on the other hand, did something entirely different. Not only did they make TypeScript a default for Angular 2, they also completely rewrote Google AdWords (responsible for $67 Billion in revenue) using a release candidate version of Angular 2. This level of trust for any JavaScript project is unheard of because the trust is inherently baked into the amazing static analysis tools that were built around TypeScript.

Full-Stack TypeScript

At Excella I’ve been working on building a JavaScript specialty practice over the past 3 years focusing on the benefits of full-stack JavaScript. With fellow colleagues we released a real-time, responsive web app and I gave a few talks on the general architectural patterns. This year I repeated the same exercise for full-stack TypeScript, which resulted in a new talk and I can report that TypeScript is the future JavaScript that I can get behind.

The DL

Let’s look at some specific ES2015 and TypeScript features below, so you can make up your own mind whether to use ES2015 or TypeScript on your project.

Typings (TypeScript only)

You can start using TypeScript today using typings. Below is a screenshot of a .js file that requires and attempts to use lodash. As you can see, when you hit dot you don’t get any suggestions. Depending on your IDE or text editor, the suggestion list can include the entire universe of known JavaScript functions that aren’t in any way related to lodash or some function you just typed up a few lines above.


Run the following commands:

$> npm install typings

$> typings install lodash

And then add the following statement to the top of your .js file:

/// <reference path=”typings/modules/lodash/index.d.ts” />

Voila, now you have all lodash functions available to you.


If you had any doubts on how to use a particular function, you get more guidance from the IDE when you open the parenthesis. No need break your workflow and pull up documentation in your browser.


Types (TypeScript only)

Types may sound scary, limiting, and a general headache to a JavaScript developer. Coming from a .NET/C# background, I definitely appreciate that I don’t have to setup elaborate contracts between system components before I even write a single line of useful code. By using types, we don’t want to introduce similar cons, but instead bring in the pros of a typing system. It is up to you to not to overuse the typing system.

Take a simple function that takes a parameter and does some string operations, returning a number.


The code seems simple enough, so why do we need types? Consider a scenario where you’re the author of Foo and you know that someone else will consume Foo or Foo will be used elsewhere in the codebase separated from its definition.

In that case, the developer either needs to rely on documentation, which works fine for well-documented libraries like lodash or they’ll need to seek out the implementation for Foo and understand the implementation behind it. After all, how should I know if Foo is returning a string or a number, and because this is JavaScript, returning both a string and a number or nothing at all?

Using the colon syntax, we can restrict what bar can be and what Foo can return.


With this implementation, the consumer of Foo knows that they must provide a string and they will get a number back in return. They’ll get proper code completion or a red squiggly line if they make a mistake. Furthermore, this TypeScript code, when transpiled, looks exactly like the code we originally wrote.


Types are a compile time feature only and have no impact on runtime code. I recommend that you use types for complicated business logic and public interfaces. The best way to experiment with types is by playing around with them in the TypeScript playground. There’s no planned JavaScript support for types.

Decorators (TypeScript or planned ES future)

Decorators are heavily utilized by Angular 2 and it is a critical feature that rounds out the type story. Decorators are denoted with the @ syntax and can be attached to classes, methods or parameters to attach metadata or behavior about that class, method or parameter at run time. Angular uses decorators to mark classes as @Component, @Directive, @Pipe or @Injectable so that the framework can validate the kind of code the developer is intending to provide to optimize runtime performance.

More details on TypeScript decorators can be found here. Future JavaScript support for decorators is planned.

Classes (TypeScript or ES2015)

You can define classes in ES2015 and TypeScript. You can write constructors and property getters and setters. In TypeScript class definitions also feed into the type system, so the benefits of using classes are clearer. In addition, utilizing type parameters on class constructors or methods, you can create documentation free, easy to use, framework quality code.


Promises (TypeScript or ES2015)

Promises are available natively in ES2015 and TypeScript. Below is an example of wrapping a function with a callback in a promise. By utilizing promises, we simplify code that needs to be written downstream. Promises can be chained, executed in parallel or can be used to defer execution.


See how connect is being consumed below:


Async/Await (TypeScript or planned ES future)

Async/await picks up, where promises leave us. We can declare any function as async, so long as it is awaiting the result of a promise. In the below example, connect internally implements promises and is returning a promise. When we await connect, behind the scenes the code continues to execute asynchronously, with callbacks and all, however to the developer, especially when debugging, the code seems to execute synchronously.

This is a big deal, in terms of avoiding callback hell and heavily indented code. Another benefit is how previously very complicated error handling scenarios now become dead simple to implement.


When async/await is used at the lowest of your application, it allows you to write the rest of your application in this manner as well, simplifying your overall implementation. Below is an example of how connect is consumed.



ES2015 offers some modern features like classes and promises, but it  falls short of fully addressing real world development concerns like avoid callbacks, debugging and error handling challenges brought upon by nested code, and still leaving developers to work with a transpiler to reach the widest audience possible. TypeScript is a remarkable piece of technology, offering a world-class integrated development experience. The free and cross-platform Visual Studio Code editor is the icing on the cake.

Check out my full-stack TypeScript starter project on Excella Labs and this sample project from the TypeScript team to being hacking around or creating your large enterprise application today.

What are your thoughts and experience with ES2015 or TypeScript?


You Might Also Like


Simplifying Tech Complexities and Cultivating Tech Talent with Dustin Gaspard

Technical Program Manager, Dustin Gaspard, join host Javier Guerra, of The TechHuman Experience to discuss the transformative...


How Federal Agencies Can Deliver Better Digital Experiences Using UX and Human-Centered Design

Excella UX/UI Xpert, Thelma Van, join host John Gilroy of Federal Tech Podcast to discuss...