Remote Code Book Club

January 21, 2020

I love reading books. 📚 I love book clubs.

And I do love discussing the books with others.

So imagine how thrilled I was to discover, whilst casually scrolling through my Twitter’s feed, that Madison Kanna is setting up this remote code book club:


The tweet featured an image of Kyle Simpson’s books that caught my eye immediately. I went on to read about its details and my hopes were confirmed. The book club wants to go through You Don’t Know JS Yet series and as luck would have it, I bought them all last year! Such a timely purchase! 👏👏

Now, since we’re going to be meeting regularly every Sunday, that will motivate me to keep up with the rest of the fellow clubgoers. How awesome is that?

Our first meeting was on Sunday, 19 January for an hour over zoom. I found the format to be very friendly. We started with a quick introduction of what the Code Book Club is, its rules, and most importantly what it is not. There were hundreds of attendees from all over the world and it is truly amazing how we all could unite around discussing the same topic. Coding without borders? ❤️❤️❤️

After establishing our goals and a few organizational tips, we broke into smaller groups in chat rooms on zoom to discuss the content of the first chapter: What Is JavaScript?.

I really enjoyed this part of the book club, as it gave us an opportunity to not only get to know some of our fellow attendees, but also it let everyone be a part of the discussion and allowed to have their voices heard.

Prior to joining the call, we were given a few questions to ponder about whilst reading and we also discussed them in the smaller groups. Below you will find my answers and hopefully, you will learn a new thing or two about JS. ❤️

💥 What is one idea/concept/fact you learned while reading this chapter? Can you describe it to your group?

Although this was only an introductory chapter to JS, I found it very helpful to get back to the foundations. Mostly because it explained in details the concepts I’ve heard about before, but never delved into their details.

As an example, let’s look at the concepts of Backwards and Forwards compatibility. The author gives us great definitions:

Backwards compatibility means that once something is accepted as valid JS, there will not be a future change to the language that causes that code to become invalid JS. Code written in 1995—however primitive or limited it may have been!—should still work today. As TC39 members often proclaim, “we don’t break the web!”

In other words, once you have written your code in valid JS as of today, it will always be valid. Although there are many upsides to this, it may sometimes result in some of the features never make it to be part of the language, however cool they might be. Similarly, if some things get accepted and a few years down the line we regret it did, there is no coming back as it could break things if it was taken out.

Forwards compatibility means that including a new addition to the language in a program would not cause that program to break if it were run in an older JS engine. JS is not forwards-compatible, despite many wishing such, and even incorrectly believing the myth that it is.

Sometimes we would love to start using the latest and greatest of the JS syntax right away, but we might get hold up by the need to support older engines.

However, that should not stop us from writing the code in the latest fashion. We can use transpiling as a solution to the problem:

using a tool (such as Babel to convert the source code of a program from one form to another

For example, ES6 introduced both let and const keywords. We could start using them right away in our codebase, but prior to shipping it to the production, we need to transpile all the packages to use the older syntax of var keyword instead, so that the older engines can still interpret our code.

Another issue related to the forwards-compatibility not being JS feature, is when there is a missing API method that was only recently added. For that we can use polyfills as a solution.

a definition for that missing API method that stands in and acts as if the older environment had already had it natively defined

💥 What is one thing you struggled with or didn’t understand in this reading?

I found the chapter quite straightforward, and didn’t feel like I had trouble understanding its content. However, one example came to mind.

The author gave an example of one of the features introduced in ES6 to compare objects,

If you have written some JS code before then you most likely know that the preferred method of comparing the objects equality is triple equal operator ===.

I didn’t know this new method existed, so I went on to research for myself when would I choose over the triple equal operator. I found out that the only difference between the two is how they treat NaN and +0/-0 comparison: method is not the same as being equal according to the === operator. The === operator (and the == operator as well) treats the number values -0 and +0 as equal and treats Number.NaN as not equal to NaN.


💥 What is one thing from this chapter that you can directly apply to your learning/project/job? How?

My answer to this question may seem trivial to some, but now I know the official name of the group that is responsible for introducing the new features to JS:

The TC39 committee is comprised of between 50 and about 100 different people from a broad section of web-invested companies, such as browser makers (Mozilla, Google, Apple) and device makers (Samsung, etc).

And what is even more important, I now make it my priority to check their GitHub page for the latest features that we might get in JS.

As to how I can apply that on the job, I found that both optional chaining as well as the Coalescing Operator were at the very last proposal stage in December 2019, and I was thrilled that is something we’ve just introduced to our codebase at work.

What is optional chaining you may ask?

It provides a fail-safe approach when accessing object’s properties. In case a property does not exist, we get a very common error “Cannot read property ‘X’ of undefined”. In order to safe guard against that error, we used to use Short-Circuit Logic with the default value to solve this issue in the past (see the code snippet below in red).

code snippet

However, now we can rely on the latest feature (in green). When carousel does not exist and so the ? operator evaluates to either null or undefined, the whole expression will evaluate to undefined or thanks to the Coalescing Operator, ?? it will default to its value instead i.e. footerCarousel.slides:


One more interesting fact I learnt whilst reading the first chapter is related to the very common JS example, console.log(). Did you know that it us not specified in JS language itself?

but because of their universal utility are defined by pretty much every JS environment, according to a roughly agreed consensus

I have been a developer for three years now, and I still managed to gain some new knowledge whilst reading the very first chapterYou Don’t Know JS Yet. I can’t wait to go through all the books to understand even more complex concepts, such as scopes and closures. I highly recommend you either join us for the Sunday bookclub hour, or just read the series! 👏👏👏