What is the difference between ES5, ES2015 (formerly known as ES6), and TypeScript? Which should we learn and use?
We want to understand the differences between them, but first we must understand what each of these are and why they exist. We’ll start with ES5.
ES5 is what most of us have used for years. Functional programming at its best, or worst, depending on how you view it. I personally love programming with ES5. All modern browsers support it. It’s extremely flexible but also has many factors that contribute to apps that can become train wrecks. Scoping, closures, IIFE’s and good guard logic are required to keep our train on the rails with ES5. Despite this, its flexibility is also a strength that many of us have leaned on.
Perhaps the most difficult problem that ES5 poses for us is the difficulty in identifying issues at development time. Tooling for ES5 is lacking as it is complicated, at best, for a tool to decipher how to inspect ES5 for concerns. We’d like to know what properties an object in another file contains, what an invalid parameter to a function may be, or let us know when we use a variable in an improper scope. ES5 makes these things difficult on developers and on tooling.
ES6/E2015 Leaps Forward
Here are some of the ES2015 features as seen in Luke Hoban’s reference. A full list can be seen here at the spec. - arrows - classes - enhanced object literals - template strings - destructuring - default + rest + spread - let + const - iterators + for..of - generators - unicode - modules - module loaders - map + set + weakmap + weakset - proxies - symbols - subclassable built-ins - promises - math + number + string + array + object APIs - binary and octal literals - reflect api - tail calls
This is a dramatic leap forward to ES5 and modern browsers are racing to implement all of the features. This chart shows the current compatibility of browsers for ES2015.
Node 4.x labels itself as Long Term Support (LTS). The LTS label indicates their release line. All even numbered major versions focus on stability and security. All odd numbered major versions (e.g. 5.x) fall under Short Term Support (STS), which focus on active development and more frequent updates. In short, I recommend you stay on node 4 for production development and node 5 for future research of features that may be in future LTS versions. You can read the official node guidelines for versioning here.
Bringing it back to ES2015, we now have an incredible amount of functionality that we can optionally use to write code.
How Do Developers Consider ES2015?
There are also many ES5 developers who couldn’t wait to use ES2015. The point is that many folks who have used ES5 are already on to ES2015, while many more are still making that decision to migrate.
So there are many of us, all with different perspectives, all leading to an eventual ES2015 (or beyond) migration.
Supporting ES5 Browsers
Where does TypeScript fit in? Should we even bother with it?
First, I think the name throws people off. The word Type in TypeScript indicates that we now have types. These types are optional, so we do not have to use them. Don;t believe me? Try pasting your ES5 code into the TypeScript playground. Look mom! No types needed! So shouldn’t we optionally call it Type?Script or [Type]Script ? Kidding aside, the types are just once piece of TypeScript. Perhaps a better name is simply ES+.
What if we could identify scoping issues as we type them? What if we could identify mismatched parameters in our tool with red underlines? What if our editors and IDEs could tell us when we make a mistake in using the other people’s or our own code improperly? This is what we generally rely on tooling for.
Identifying Issues Early
Whether we use Atom, VS Code, Visual Studio, Web Storm, or Sublime Text we enjoy a plethora of innate features or extensions to our tool of choice that help us write better code faster. These tools should (and can) help use identify problems early.
Is it more fun to find an issue right away as we code it, so we can fix it there … or to get called at 5am due to a production outage when traffic cranked up on our app and hit our hidden bug? I prefer to be home at 5 with my family :)
These tools today try their best to help identify problems, and they do an admirable job with what they have to work with. But what if we could give them a little more help? What if we could give them the same types of help that other languages like C# and Java provide today? Then these tools can really help us identify issues early and often.
This is where TypeScript shines.
The value in TypeScript is not in the writing less code. The value of TypeScript is in writing safer code. Over the long haul, it helps us to write code more efficiently as we take advantage of tooling for identifying issues and automatically filling in parameters, properties, functions, and more (often known as autocomplete and intellisense).
I joke that TypeScript should be called ES+, but when we examine it more closely, that is what is really is.
So what does TypeScript offer over ES2015? I’ll focus on the three main additions I feel add the most value:
- Future ES2016+ features (such as Annotations/Decorators and async/await)
TypeScript is ES plus features like these.
Types and interfaces help provide the tooling it needs to identify problems early as we type them. With these features our editors don’t have to guess whether we used a function properly or not. The information is readily available for the tool to raise a red flag to us so we can fix he issues right away. In some cases, these tools can also help recommend and refactor for us!
TypeScript promises to be forward thinking. It helps bring the agreed upon features in the future ECMAScript spec to us today. For example features like decorators (used in Angular 2) and async/await (a popular technique to make async programming easier in C#). Decorators are available now in TypeScript while async/await is coming soon in v 2.0 according to the TypeScript roadmap.
From the top of the TypeScript website’s front page we find this statement:
Why Not Just use ES2015?
That’s a great option! Learning ES2015 is a huge leap from ES5. Once you master ES2015, I argue that going from their to TypeScript is a very small step. So I suggest back, once you learn ES2015, try TypeScript and take advantage of its tooling.
What About Employability?
Does learning ES2015 or TypeScript hurt my employability? Absolutely not. But it also doesn’t mean that you shouldn’t understand ES5. ES5 is everywhere today. That will curve down eventually, but there is a lot of ES5 code and it’s good to understand the language both to support it and to understand what problems ES2015 and TypeScript help solve. Plus we can use our knowledge of ES5 to help use debug issues using sourcemaps in the browsers.
Keeping Up with the Emerging Technology
What does this all mean? Just when we have browsers that support ES2015, ES2016 may be out. Without help, this could be awful if we want to support all ubiquitous browsers and use the new features! Unless we have a way to use the new features today and support the browsers we need.
This is why the emergence of transpilers has become so important in the Web today. TypeScript and Babel (the major players in transpiling) both supported ES2015 before it was in the browsers. They both plan to support (and already do in some cases) ES2016 features. These tools are the current answer to how we move forward without leaving behind our customers.
How Do We Transpile?
We can use tools like Gulp, Grunt, WebPack, and SystemJS with JSPM to transpile with Babel or TypeScript. Many editors connect directly to these tasks to transpile for us as we code. Many IDEs now support automatic transpilation with a click of a button. We can even use TypeScript from the command line to watch our files and transpile as we go.
No matter how or where we code, there are many ways to transpile.
What It All Means
A fact in our chosen profession is that technology changes. It evolves. Sometimes it happens much faster than we can absorb it. That’s why it is important to take advantage of tools that can help us absorb and adapt to the changes, like TypeScript and Babel for ES2015 (and beyond). In this case, we’re using technology to keep up with technology. Seems like a paradox, but at the core it’s simply using our time effectively to keep up.