Turn your ES5 code into readable ES6 (sugar-syntax). It does the opposite of what Babel does.

David Walsh has a post on it. I'm interested, as I'm still working on my muscle memory for ES6. Even the simple stuff. So blasting some old code through this as a kick start seems appealing.

Template Literals

The Template Literal, introduced in ES6, is a new way to create a string. With it comes new features that allow us more control over dynamic strings in our programs. Gone will be the days of long string concatenation!

To create a template literal, instead of single quotes (') or double quotes (") quotes we use the backtick (`) character. This will produce a new string, and we can use it in any way we want.


Transpiling ES6

While support for ES6 is always increasing, we can't always assume that users will be using a browser that supports all its features. So, in order to utilize ES6 features now and make sure we won't run into cross-browser compatibility issues, we need to transpile our code.

Let's look at two possible ways we can perform the task of transpiling our code. First, we will use npm scripts and Babel. For the second, we will look at using Gulp with Babel.


My New Favorite ES6 Toy: Destructured Objects as Parameters

Like a lot of other developers, I’m working through my continued education learning what I can about ES6. One of the ways I’m doing this is to attend workshops by smart people. I went to Kyle Simpson’s ES6: The Good Parts course and found myself particularly interested in the practical applications of a piece of ES6 I had previously not noticed: Destructured Objects as Parameters.


Babel Plugin to Add Function Names

Have you ever been working with those sweet new ES6 arrow functions, run into a problem, and noticed that now your stack trace is all anonymous functions? Yeah, that's not so great. That's why this Babel plugin is so useful. You can add names to your ES6 arrow functions, and it makes debugging a lot more simple.

ES6 module loading: More complicated than you think

Nicholas Zakas:

The differences between scripts and modules are subtle enough that it's hard for developers to understand the restriction of declaring what a JavaScript file represents ahead of time. My hope is that this post clarifies some of the reasons why it's not possible to autodetect modules from inspecting the source code and why tools such as ESLint ask you to specify the file type before executing. There will be a point in the future where ES6 modules are the dominant JavaScript file type and script files are left only on legacy applications, and at that point, it's likely that tools will default to assuming that files are modules. In the meantime, we're going through a difficult adolescence between scripts and modules where mixing the two is going to be a bit painful.