JavaScript is a pretty strange programming language. But it’s also pretty cool. Back in 2007, Jeff Atwood (founder of StackOverflow), made a case that JavaScript would become a bigger part of web development. Atwood coined the term “Atwood’s Law,” which states:

Any application that can be written in JavaScript, will eventually be written in JavaScript.

It’s now ten years later, and Atwood’s statement is truer than ever. JavaScript is continuing to gain more and more adoption…for good (and bad) reasons. At its core, JavaScript is a mix of some really good ideas and some really bad ones. The “next generation” of Javascript is something known as ES6. 

JavaScript is actually the term developers use for the ECMAScript language. Modern web browsers can execute version 5 of ECMAScript flawlessly. The next generation of ECMAScript, version 6 (or ES6 for short) doesn’t have full browser compatibility yet. But it’s the direction that the JavaScript language is headed. ES6 has a lot of forward-thinking ideas attached to it and is a really exciting programming language to use. There are a lot of reasons to get excited about it.

And there are a lot of reasons why we decided to build a whole new piece of curriculum around it for our new Advanced Programming Course.

In this post, I’ll get into the 12 main reasons why ES6 is the future of Javascript and web development. 

Reason 1: You can write it today.

Web browsers might not have full feature support, but that doesn’t mean you can’t use the new features that ES6 has to offer. There’s a cool project called babel that takes ES6 code and transpiles it…meaning it rewrites the code in the older ES5 language.

This lets developers benefit from new features available in ES6 without waiting for web browsers to catch up to the new technology (and without waiting for your users to update their web browser to use the newest version).

Super cool. 

Reason 2: ES6 is really fast.

Google spent a lot of time building the Chrome web browser. They also spent a lot of time tuning the algorithms that dictate how JavaScript executes. In the process, they extracted their JavaScript runtime from the web browser into something called NodeJS (which is the JavaScript programming language minus a web browser).

So, what does all of that mean?

JavaScript is an incredibly fast and efficient programming language to use for a variety of purposes. And since ES6 can be rewritten to be run in an ES5, ES6 benefits from all of JavaScript’s performance optimizations.

Reason 3: ES6 is 100% Backward Compatible.

This is an important feature of ES6 that has some interesting tradeoffs.

As I mentioned before, there are some hiccups in the JavaScript programming language. Douglas Crockford pointed out the bad parts of JavaScript in his book JavaScript the Good Parts. In the book, he advises good JavaScript developers to simply opt-out of the bad parts.

ES6 could have removed these bad parts outright. But the people who designed the language designers opted to leave the bad parts in.

Why oh why would they do that?!

JavaScript has a rich ecosystem. It’s filled with thousands of packages on the package manager (NPM), and it has widespread adoption. In order to ensure that ES5 JavaScript packages would always work in the context of the ES6 language, they decided to make the language 100% backward compatible.

This means that when you start writing ES6, you can start with the regular JavaScript you know and love. You can then slowly start embracing new features and adopting the aspects of ES6 that make your life easier as a developer as you get more comfortable over time.

Reason 4: ES6 has Object-Oriented Classes.

JavaScript supports a method of inheritance called prototypical inheritance. It’s a version of the inheritance that is a bit different from classical inheritance (or how inheritance works in most other programming languages).

ES6 supports class syntax. This mirrors other programming languages, but ES6 takes the traditional style of defining classes and inheritance and maps it to the corresponding prototype chain.

This is a small change, but it can make it a lot smoother to write object-oriented code in ES6 compared to other languages. 

Reason 5: ES6 has Arrow Functions

Functions are a cornerstone of the JavaScript functional programming language.  

But surprisingly, functions behave slightly strangely in JavaScript. 

In JavaScript, something weird happens to the ‘this’ keyword within functions. Because of that, developers often have to rebind the variable in ES5. Code like this is pretty common to see:

var that = this;

function() {



This is because the function rebinds the value of this unless you explicitly rebind the variable.

This is particularly annoying when writing JavaScript code. 

Why is rebinding annoying? Let me explain through this analogy:

Think about you as a person. You have properties like a name, address, etc…Imagine that when you’re writing letters, you could use templates. So for a letter signature, you could use something like:



But for some really strange reason, this only works when you type. You could potentially use these things when you talk, but before you talk you’d need to explicitly say:

“Hey remember who you are when you’re talking so you can reference things like your name, address, etc.

That’s what the below line of code does:

var that = this;

It’s not difficult to write that line of code. But It’s just stupid to have to do it and to think about.

Rebinding is particularly annoying when writing JavaScript code. 

But ES6 has a solution. 

ES6’s solution to the problem is something called arrow functions. Arrow functions are a slightly different syntax to defining functions that behave in a much more logical way in regard to the value of this.

I’ve found the value of the feature is much more noticeable in ES6 because the class syntax makes it much more intuitive to write object-oriented code in the language. This makes the this keyword much more useful!

Reason 6: Modules are built into ES6.

Modules have to be one of the most boring aspects of ES6. It’s a feature that wasn’t even built into the JavaScript language initially. Because of this, it brought up an interesting question: 

How can you ensure that different packages do not conflict with each other?

In regular JavaScript, two different patterns evolved to make it possible to break things into different systems. These systems were CommonJS and AMD.

These different module systems had different ways of segmenting the module information. They both worked well, but it was possible to find yourself in a situation where you had to use different syntax to load different packages that had different module syntax.

According to this StackOverflow post:

“Arguments around which format is better state that CommonJS attempts to cover a broader set of concerns and that it’s better suited for server-side development given its synchronous nature, and that AMD is better suited for client-side (browser) development given its asynchronous nature and the fact that it has its roots in Dojo’s module declaration implementation.”

ES6 includes a built-in module system. Because it’s part of the language, it provides one definitive way to load and export modules. The syntax is also suitable both for server-side and client-side functionality.

Reason 7: ES6 has template literal strings.

This is one of my favorite features of ES6. It’s a small one, but it’s pretty common to want to build up a string that includes variables within it.

Ruby has a feature they call string interpolation, which does exactly this. JavaScript had been missing the feature until ES6 came along. ES6 supports it, just with a slightly different name.

This means that instead of building up a string like, “Hello there, Ken”, but replacing the name Ken with the person you’re addressing name like this:

var message = “Hello there, ” +;

You can build them fluidly like this:

var message = `Hello there, ${}`

It’s a small thing, but when building up strings that are built up of many different parts, template literals are enjoyable to use.

Whenever I use template literal strings in ES6 code, it just feels good to write!

Reason 8: ES6 uses Yarn

JavaScript packages are frequently loaded from the NPM (Node Package Manager) source. It can take a while to run the command to install all the packages and have them completed. Because of that, sometimes developers can end up with different versions of the packages.

Facebook built a new client on top of the NPM platform to allow NPM to scale and work on big applications…like Facebook. They also open-sourced the code.

Yarn, like NPM, allows you to bring dependencies into your project, and it allows you to pull them from the NPM source too. However, Yarn introduces many awesome optimizations.  Traditionally running the command:

npm install

Would install all the third party packages into the project.  This process has a few drawbacks.

  • First, it’s not “deterministic.” This means that sometimes your machine can get different versions of packages in them then other projects. This generally only happens in massive projects, but it can cause a lot of bugs and confusion.
  • Second, it’s pretty slow.  Running that command can easily take several minutes to complete.  I’ve heard stories of colleagues doing ridiculous things to optimize the process in a small way.

Yarn fixes both of these things.  With yarn, the versions of the packages you get are always consistent.  In addition, the command to install them generally runs much faster, which means you can get back to coding a lot more quickly.

Technically, you can use yarn with regular JavaScript in addition to within ES6, but it’s a pretty recent improvement to the JavaScript ecosystem. Overall, it’s a step in a really good direction for both JavaScript and ES6.

Reason 9: ES6 solves the same problems as CoffeeScript but in a better way.

The CoffeeScript programming language was designed to cover up a lot of the problems that plagued JavaScript. It was essentially created to make it a lot more difficult for developers to write buggy code. CoffeeScript looks similar to Ruby but works with JavaScript. CoffeeScript developers still need to have a working knowledge of JavaScript, though, because example code, documentation, etc… will only show you how to achieve something in JavaScript.

ES6 fixes a lot of the problems that JavaScript faced. But since it’s backward compatible with JavaScript code, it’s easy to learn incrementally and start adopting features slowly.

Reason 10: In ES6, const and let solve traditional scoping problems.

ES6 has the new keywords const and let (realistically replacing JavaScript’s var keyword), which allow developers to write safer code with less worry about leaking the variable out of scope, and prevent you from having duplicate declarations of the variable in the same scope. So, let’s say we wrote the below valid JavaScript code:

var a = “hello”;

var a = “bye”;

This would cause the value to be the final value (in this case ‘bye). If we’re doing something like this though, we probably shouldn’t have set the value of the variable initially. This is a mistake. But if we try similar code with a const or let:

const a = “hello”;

const a = “bye”;

This would produce an error that indicates there is a problem:

TypeError: Identifier ‘a’ has already been declared

This can help developers catch problems with scoping.

Reason 11: ES6 has a cool new feature called the Spread Operator

The spread operator is an interesting way to build new arrays based on the values of existing arrays. This feature took me the longest to get a feel for, but once I did, it became one of the features I most appreciate in the ES6 language.

The spread operator is a single construct in the ES6 language that is super versatile.

It’s similar to the splat operator in Ruby. It can do things like:

  • Copy an array
  • Concatenate arrays
  • Insert new items into arrays

The spread operator is a powerful tool. Once you start figuring it out, it will become your go-to solution when working with arrays. It even makes libraries like underscore or lodash less important, since solutions to manipulating arrays are built directly into the language.

Reason 12: ES6 has Promises

Promises make the async nature of JavaScript more predictable and friendlier to handle. They provide a consistent way of handling future events instead of arbitrary library specific patterns.

This makes it a lot simpler to understand how to structure your code.

There’s a lot that makes ES6 exciting.

Jeff Atwood was right when he talked about JavaScript having a bright future in the programming community. It’s the practical language of choice in a variety of cases. 

But JavaScript isn’t a perfect language. It has a number of flaws. A lot of the flaws were caused by quickly building the language without having a lot of experience working in in it. Over the past 20 years, developers have gotten more and more experience with the JavaScript language, which has lead to improvements. 

ES6 does 3 essential things super well:

  • It starts by taking all the aspects of the JavaScript programming language that make it awesome.
  • It then works to build constructs to fix JavaScript’s flaws
  • It adds some features that make your quality of life as a developer just so much better.

To say that ES6 has a bright future would be an understatement. Web browsers are currently working to adopt working with the ES6 code natively, but until that happens, we can use babel to get a step ahead of this cutting edge programming language.

If you graduated from a coding bootcamp or just want to level up your programming skills, it can make a lot of sense to try out ES6. 

Learning it can be an amazing way to differentiate yourself from other developers and evolve your career. 

It’s also just super fun to use. 

We just launched a new course that helps you learn ES6.

Firehose Advanced Programming is a new course that helps new developers evolve their skills and get experience with new technologies to help them accelerate their careers faster than their peers.  We give you dedicated support from our engineering team and a structured curriculum to help you learn ES6 without getting stuck. The course is currently only open to Firehose students and graduates, but we plan to release it to a wider audience soon.  You can learn more about the course from our launch announcementStay tuned for the wider launch!

AuthorKen Mazaika

Ken Mazaika is the CTO and co-founder at Firehose. Previously, he was a tech lead at (acquired by PayPal) and a member of the PayPal/eBay development team in Boston.

Leave a Reply

Your email address will not be published. Required fields are marked *