Over a million developers have joined DZone.

Should I Use ECMAScript 2015 Today?

DZone's Guide to

Should I Use ECMAScript 2015 Today?

People are asking this question a lot lately, and there are just a few questions you need to ask yourself before you can answer it. It can all be boiled down to a flow chart.

· Web Dev Zone
Free Resource

Deploying code to production can be filled with uncertainty. Reduce the risks, and deploy earlier and more often. Download this free guide to learn more. Brought to you in partnership with Rollbar.

In the last few weeks I was asked a few times the question that is the title of the post. In this post I’m sharing my opinion about that question and the answers I gave to some of the people who asked the question. My hope is that this post will help people who are thinking about using ES2015 in their projects.

With Great Power Comes Great Irresponsibility

Most of the developers I met lately are eager to use all the new buzzword technologies from the second they hear of them.

“Have you heard about React? Let’s use it in our next product/module cause it sounds great.”

"Yesterday I attended a Meetup about AngularJS. This framework is so cool and I want to check how to add it to our current solution."

“I heard that ECMAScript 2015 (ES2015) specs are out since June 2015. Let’s start writing code according to that spec.”

I’m always hearing these kind of sentences and I’m always overwhelmed by their problematic implications. Let’s make it clear, I’m an eager developer like any other developers who said these sentences. I also love to learn about new technologies and how to combine them into projects/solutions. On the other hand, after so many years in the industry I learned to look at the big picture and then to calm the buzz noises. You can and should use new technologies but before you do that you need to be sure that you aren’t running forward like a blind horse.

Returning to the subject of whether you should use ES2015 today:

Making Some Assessments

One of the people who asked me the question was a CTO of a known startup. He told me that his team is starting to write a new web application product. So he asked me the question and my diplomatic answer was “It depends”.  I asked a few more questions regarding his team, their JavaScript knowledge and about the product customers. Here are some of the questions:

  • Are your developers JavaScript veterans? Do they have knowledge in object-oriented paradigms?
  • Does your team include fast learners?
  • Does your team eager to learn new technologies?
  • Which browsers the end users are using? evergreen browsers? IE8…?

Once I got all the answers, I told him that they should think about starting to develop in ES2015. The main reasons were:

  • The team doesn’t have previous knowledge in JavaScript and they have good C# knowledge. From my experience, it will be easier to developers with object-oriented knowledge to move to ES2015 than to previous versions of JavaScript. This is a result of the new additions to ES2015 (classes, modules, arrow functions and more). Also, if the team is starting to learn JavaScript, my opinion is that they should learn the last version which is a super set on top of ES5.
  • Their end users are using evergreen browsers which is very helpful when it comes to using ES2015. Most of the evergreen browsers already implemented many of ES2015 features and that is great. On the other hand, there are features that aren’t supported and this is why I suggested to use transpilers such as Babel and Traceur or a language like TypeScript which can convert ES2015 code into ES5 code.  Another reason to use transpilers is for old browsers support. The problem with using transpilers is that they sometimes cause an overhead in development and maintenance.

Another person who asked the question asked whether to write his blog posts in ES2015 or with ES5. My answer was to write in both of the versions or to write in ES2015 and link the code to a transpiler playground to enable developers who don’t know ES2015 to translate the code into ES5. By doing that his readers will enjoy both of the worlds (ES2015 and ES5).

The third person who asked the question was already in the middle of creating a web application and his team was writing the whole product in vanilla JavaScript. They started writing the project in ES5 two years ago. To him I suggested that they should learn about ES2015 but it will be risky to use all of the new features in the project in it’s current state (which is very bloated). On the other hand, they can add some of the simple features like the usage of let keyword instead of var, default function arguments or arrow functions. They can also add the new structural keywords like classes and modules gradually and refactor their code. Regarding other more sophisticated features such as generators, reflect API or proxies,I would prefer to avoid them in legacy projects up until the team will understand how to use them.

To help you understand some of my thoughts, I created a small flow chart:


The main thing about the flow chart is that my opinion is that the answer to the question in the post’s title is yes, but there are a few preparations that teams should do before they run and use ES2015.


ES2015 is a major progress in the JavaScript language. It brings a lot of new language features which are very necessary to writing a more robust solutions. On the other hand, using ES2015 might be risky for some projects. Before you run and use ES2015 in your current project, I suggest to plan ahead and check whether your team/end users will be able to handle your decision. Doing that might help you avoid a lot of future problems.

(10x to Oren Rubin, Shai Reznik and Uri Shaked for their comments about the post draft)

Deploying code to production can be filled with uncertainty. Reduce the risks, and deploy earlier and more often. Download this free guide to learn more. Brought to you in partnership with Rollbar.

ecmascript 6 ,ecmascript ,javascript

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}