Chapter 4. Where to Start

It’s settled then. You are going to begin integrating ES6 into your projects. Still, you may have some questions about where to start. Or maybe you would like some best practices for your organization. The following suggestions may make this transition easier.

Incidental Functionality First

Your team will need to gain some momentum when using these new constructs, especially if you’re catching up on your innovation debt. I suggest you pick a portion of your app that isn’t considered “core functionality.” Let your team train up on areas of your app that add value and provide incidental functionality. This will allow you to leverage your team’s training process while minimizing any risk involved.

Graceful Degradation

Some browsers have more capabilities than other browsers. Maybe you’ve decided that you want to use some functionality that doesn’t exist in all browsers. In other words, your users will have a different experience on your site, depending on their web browser. When implementing different features for different browsers, there are two competing ideologies:

Progressive enhancement

Progressive enhancement suggests that you begin by building your site for the worst-case and most basic scenario. Once that exists, you add functionality for the more capable browsers.

Graceful degradation

Graceful degradation suggests that you build your app for the most capable browser. Once that exists, you find alternate functionality or turn off the functionality for less-capable browsers.

I recommend that you start out by implementing graceful degradation. Allowing your team to focus on the best possible scenario will produce the best possible experience for your customers. You may then combine your best-case scenario using a transpiler (see “Using a Transpiler”), pushing Microsoft’s Enterprise Mode (see “Microsoft’s Enterprise Mode”), and/or traditional monkey-patching. Combining these technologies may even enable the worst of browsers to run the latest ES6 code.

Note

Monkey-patching is the term used to describe the act of modifying JavaScript’s default behavior. An example of monkey-patching could be adding JSON.parse and JSON.stringify functionality into IE7. Because IE7 was released prior to the explosion of JSON, it doesn’t have support for the JSON API. However, a handful of libraries out there monkey-patch IE7 so that it has JSON.parse and JSON.stringify functionality. Monkey-patching is also known as duck-punching and polyfilling.

However, please do not shy away from shutting off different pieces of your site to users who are on older browsers. As discussed previously, herding your users to an evergreen (auto-updating) browser will reduce your development and maintenance costs. Further, as a member of the web community, we all have a duty to protect our users. While modern browsers are much faster and more capable than older browsers, that isn’t why you should help your users upgrade to a better browser. You should help them upgrade so that they can use a browser that has the latest security patches and updates. You should help them upgrade so that they can be safe.

Note

Evergreen browsers automatically update themselves. Additionally, they remain up-to-date, regardless of your operating system. This ensures that you have the freshest speed, security, and functionality enhancements available.

Train Your Teams

Once you’ve seriously committed to training your team, those commitments should be made apparent. Your commitment should be more than simply giving them goals on their annual performance review or buying each member a book to read. Create a culture based on the results of the training. Recognize, reward, and promote individuals who are leading the way and helping others to learn.

The number of pure JavaScript conferences is increasing. Both locally and nationally, these conferences are becoming viral. Find two or three of them and send your teams. If the conference is during the work week, pay your employees to attend the conference. Don’t require your team to use vacation days to go to a conference. If the conference is on a weekend, make strong recommendations that they attend. Have team members return and present their findings to the rest of the team. If you have to, offer comp time for those who use weekends to attend conferences.

Do everything in your control to get your teams trained and talking to each other about JavaScript.

Using a Transpiler

One of the quickest ways to get your team into ES6 is by using a transpiler. With a transpiler, you write ES6 code, and it is then turned into something that older browsers can understand. This means that your teams can start using tomorrow’s syntax today.

This means that you can have your teams write this:

let add = (x, y) =>  x + y ;

and it will convert that into code that your users’ browser can understand:

var add = function(x, y){
    return x + y;
};

If the idea of a transpiler interests you, you may be pleased to know that you have more than one option. As I write this chapter, there are two transpilers that are more widely used than others. Babel is the most widely used, and Traceur-Compiler is the second most widely used.

Babel (formerly known as 6to5 but changed its name when ES6 was renamed to ES2015) is the most popular, and currently supports 76% of the latest ES6 functionality. Babel is used and recommended by many of today’s greatest JavaScript developers. While Babel supports more features from ES6, Traceur-Compiler has a more semantically-correct implementation of those features.

As I compared Babel and Traceur side by side, I realized that some of the expectations that I had for runtime ended up being less important to the Babel engine than the Traceur engine. However, when Babel transforms your code, the code is more readable than it otherwise is when transpiled with Traceur. In other words, each library has its own benefits. Yours is the job of finding those differences and helping your team make an educated decision on what you should use.

In addition to Babel and Traceur, there are other transpilers that you should listen for. JSX w/ ES6, Closure, ES6-shim, CoffeeScript, and TypeScript are the ones that you should keep your listening for. Particularly, you may want to listen for TypeScript. In March of 2015, the Angular core team announced that their plans for Angular 2.0 include the adoption of TypeScript as an official part of their recommendation. Because of this, you will begin to hear about more and more developers integrating TypeScript with their projects. Additionally, TypeScript carries with it many of the features from ES7 (ES2016), which means that it will continue to be more and more relevant. Further, the TypeScript team has more developers on it than both Babel and Traceur combined, making it a mean competitor.

Microsoft’s Enterprise Mode

In the past few years, Microsoft has taken several steps toward helping the Web gain momentum. And more than one of those changes may prove helpful as you attempt to fight free of the bonds of oldIE. I am not asserting that we need to forget everything that Microsoft has done along the way to sandbag the progress of the Web. However, I do feel that we should each let our biases go and accept progress as such. Especially when it helps us move our organizations forward.

One of the reasons that many corporate environments are stuck using an old version of IE is because they have a few sites that don’t run well in newer versions of any browser. In almost all cases, these are sites that they depend on. And rather than rewrite those sites to work in modern browsers, they are more than happy to force all of their network users to continue using IE8 or IE9. If this sounds like your organization, or your customers’ organizations, KEEP READING! There is hope.

One of Microsoft’s recent features that I think you should care about is Enterprise Mode. Enabling Enterprise Mode on a Windows Network means that you can set up a list of certain sites that need and depend on oldIE to function appropriately. Then, any network user can open Internet Explorer 11 (or whatever the latest version is when you are reading this) and IE11 will load those sites with an older version of its JavaScript and HTML/CSS rendering engines. A version that acts, thinks, and performs like oldIE performs. All other sites will get to experience the Web through IE11.

Perhaps educating your network folks (or your customers’ network folks) about the benefits and ease of use of Enterprise Mode may afford you the freedom to upgrade your development process to only include more modern browsers. If are like me, you know the exact number of users that are still using oldIE. Fingers crossed that Enterprise Mode, along with Microsoft’s support changes coming in January 2016, will help us all move our projects into the future.

Summary

Every organization is different. Each team will need to set its own pace. With innovation in general, constant progress is key. Aggressively seek out new opportunities to help your projects stay on track with your innovation goals. The total reduction in costs for standardizing on modern technologies will make your efforts worth it. The age of “oldIE” isolation has already begun.

Get JS.Next: A Manager's Guide, 2nd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.