Surviving ECMAScript 6
I recently watched an insightful talk from Rob Pike where he shared his experience attending Lang.Next, a conference focusing on new and upcoming trends in programming languages. While there, Rob noticed how many presenters focused on things they were adding to their respective languages. This concerned him because languages were becoming more complex and similar to one another.
I’ve found ES6 both fun and frustrating. I hope to provide some tips to help you focus on writing quality maintainable code.
You don’t need to convert everything to ES6 or adopt all the ES6 features immediately! It will take time to understand what works well and what doesn’t. ES3 took years to boil down to the good parts, as this photo illustrates:
Think about it: whole new sets of anti-patterns are under active development right now!
Rushing in too quickly to new features could be counterproductive. I’ve watched this happen in the React community. ES6 classes used to be all the hotness, but then we realized that classes lacked essential features like static properties and mix-ins. So, we used Babel and new language proposals to add those features in, but we depended on languages features that didn’t even exist. Now, many have moved back to
React.createClass or strictly ES6 classes with dangling static properties. Ironically, the initial code was easier to read and understand.
My advice: use what you know and understand well, then add in what makes sense.
Keep in mind that some of the new ES6 “syntactic sugar” can make things slower than its ES5 counterparts.
Use what’s supported
Babel also rewrites your code and now you depend on Babel. I experienced the downside of this when Babel 6 came out. Modules behaved differently and working syntax broke. If I use stable language features that are supported in the runtime, I don’t worry about my code breaking when new updates arrive.
Tools over features
--fix flag). If you don’t have that integrated into your editor, go figure that out right now and come back!
Another huge time-saver is automatic formatting. ESLint is getting better with this all the time (with the
--fix flag). I’m looking forward to the next releases now that JSCS has joined the team. ESFormatter is another great option.
Other indispensable tools include a good testing framework, test coverage, and continuous integration.
Tools increase my confidence in the code my team and I write. If a new language feature doesn’t work with my tools, I don’t care to use it yet. I’d much rather have my tools work.
Adopt new features with care
As you think about using a new feature, ask yourself:
- Will this feature require me to compile my code?
- Does this feature break the tools I’m using now?
- What do I gain or lose from using this feature?
If the benefits clearly outweigh the losses, using that new feature might be a good move. If not, perhaps your best bet may be achieving your goal through other means.