Maker Series Recap: Wes Bos on Modern JavaScript

Meet Wes

If you’ve been working with or looking into modern web technologies, you’ve probably come across the name Wes Bos before. Wes is a full-stack developer from Hamilton, Canada, who’s best known for his energetic, thorough, and easy-to-understand tutorial videos. He’s cultivated a large following by providing free courses such as Javascript30 and CSSGrid, as well as premium courses like React for Beginners and ES6 for Everyone.

Having gone through several of these courses myself, I was excited to finally meet him in person at the first Maker Series workshop of 2018 and to dive deeper into some of these concepts. My expectations were high going into the event, and I can confidently say that Wes did not disappoint. We spent the day building a fun web application that used our laptop cameras, applied some filters to the feeds, and allowed us to download snapshot images that even worked offline. Since this was a hands-on workshop, we started with a scaffold of empty files and folders, and used each application feature we added to learn a different JavaScript concept, including promises, the async/await keywords, and service workers—each of which I’ll discuss in further detail in this post.

Promises: Providing Placeholder Variables to Help Us Create Better Data-Flow Management

Our first step in creating the day’s application was fetching data. Previously, when we would get data from a third party we’d make an asynchronous call that would return to us in the form of a callback function. Doing this created some fairly complex code, as it required us to get data from function “x” and handle that data in function “y.” Doing this many times over again in the same file, along with error-checking each call, created difficult-to-read code that got most developers in a situation properly referred to as “callback hell.” This name comes from the difficulty that someone has while trying to debug an issue inside of this pattern.

In an effort to deliver us from callback hell, Wes introduced us to the “promised land.” A promise, in JavaScript, is when we’re given an immediate response that will serve as a placeholder for future data. With the addition of promises we’re able to tame this workflow into a more readable, less complex task.

For example, we’re able to take a piece of code like this:

getTheWeatherFor('Dayton', function(weather) {
  getPicturesOfWeather(weather, function(pictures) {
    resizePicturesOfWeather(pictures, function(resizedPictures) {
      uploadNewPictures(resizedPictures, function() {
        console.log('Finally Done!');
      }, function(err) {
        handleError(err);
      });
    }, function(err) {
      handleError(err);
    });
  }, function(err) {
    handleError(err);
  });
}, function(err) {
  handleError(err);
});

And turn it into this:

getTheWeatherFor('Dayton')
  .then((weather) => {
    return getPicturesOfWeather(weather);
  })
  .then((pictures) => {
    return resizePicturesOfWeather(pictures);
  })
  .then((resizedPictures) => {
    return uploadNewPictures(resizedPictures);
  })
  .then(() => {console.log('Done');
  })
  .catch((err) => {
    console.log('Something Happened!', err);
  })

Because our goal is to get data that depends on our last call, this second approach ends up being much more readable. There’s less confusion about what’s going on, we’re naming our variables appropriately, and there’s a nice linear flow because of our ability to chain .then statements to the end of our promises.

Adding promises into our workflow was a great addition to our JavaScript toolkit, but we’re not done yet. Wes went on to teach us about an even newer approach to complete this exercise that is built on top of promises and released in a newer version of JavaScript with a pattern that uses the async and await keywords.

Async/Await: A New Way to Write Synchronous Code in an Inherently Asynchronous Environment

The async/await pattern was something I had heard about quite a bit but hadn’t looked into yet, so I was excited to see it on the agenda for this Maker Series. Wes explained async/await as a feature that gives us the ability to start writing code we can read line-by-line from the top to the bottom of a page in JavaScript.

Using the keyword async will define a function as asynchronous, which means that it will implicitly return a promise that will resolve when anything using the keyword await inside of it has finished resolving. Before we refactor our above code snippet to see exactly how this changes our promise-based flow, here are a couple points to note about using this pattern:

1. To use the await keyword, we have to use it inside of a function that is marked with the async keyword. This means that you cannot have a top-level await statement.

2. All functions marked with async return a promise implicitly.

So, to take the code we wrote above and transform it into a more readable format, we can do this:

async function go() {
  const weather = await getTheWeatherFor('Dayton');
  const pictures = await getPicturesOfWeather(weather);
  const resizedPictures = await resizePicturesOfWeather(pictures);
  console.log('Gonna upload them now');
  await uploadNewPictures(resizedPictures);
  console.log('Done!');
}

My question regarding this approach is with error handling. To gracefully handle that, Wes recommends using a try/catch block around the lines that use the await keyword. The try/catch pattern seems to be fairly forgotten about in the JavaScript community, and one Maker Series participant even asked if it was deprecated. Wes assured us that it wasn’t and is an advocate of using it in scenarios such as this.

Service Workers: Giving Us Multi-Threaded Background Abilities on the Client

Another topic I was excited to hear about during the workshop was service workers. With the addition of service workers to JavaScript, we’re now able to have something on the client side perform a task that does not affect our current JavaScript thread that is being executed in the browser. We are also able to send messages back and forth between our web application and the service worker, as well as store data on the client.

Wes talked us through service worker’s practical applications, including the ability for users to cache your site and provide offline capabilities. We could use a service worker, for instance, to intercept server requests from the client and instead serve the content they’re looking for directly from their own local storage, providing they’ve visited the site before. This is a great tool for someone like Wes Bos, who now has the ability to provide an “offline mode” for his courses for any users who may want to take them on a flight or a longer trip with no WiFi.

Here are a couple quick things to take note of when considering service workers:

1. Service workers run on a separate thread, so a break in your page JavaScript will not affect the currently active service worker.

2. Service workers require HTTPS.

3. Any change to service worker code will cause the browser to remove the current service worker and create a new one with a higher version number.

This implementation is still pretty rough and very involved from a development perspective. The code that Wes used to give our camera app an offline mode was actually directly from Google’s introduction of service workers. Wes predicted that we would start seeing abstractions written for these that’ll really help the developer experience pretty soon. One that is already in planning, he mentioned, is Workbox. Workbox is an API being developed by Google that is aimed specifically at abstracting the service worker logic around providing an offline mode and providing us with an easy-to-use way to do this.

A Day with Wes Bos: Teaching Modern JavaScript with Ease

Having Wes come to Dayton for this Maker Series was a treat. He’s incredibly knowledgeable, down to earth, and able to teach difficult JavaScript concepts like the ones mentioned above with ease. He was more than a coach or teacher for the day. He was also entertaining and engaging, which made it that much more enjoyable to be around him. That being said, I’ll be on the lookout for his next course because it’s sure to be a good one.

Collaborative Notes from the Maker Series