Book Club: Eloquent Javascript - Chapter 1
Tags: bookclub, javascript, webdev, beginners
Published: 2021-07-03 16:19:27

---
title: Book Club: Eloquent Javascript - Chapter 1
published: true
description: How I used a bad interview experience to relearn JavaScript fundamentals. 
tags: bookclub, javascript, webdev, beginners
cover_image: https://eloquentjavascript.net/img/cover.jpg
series: Eloquent JavaScript Book Club
---

I recently did a technical job interview that was for a frontend position. It was for a company that specialised in cybersecurity technologies, but they were looking for React developers to create better UI dashboards for clients.

I expected the interview to ask some algorithm questions, maybe talk about some JavaScript data structures or optimisation. Instead, I was taken aback by the questions I got. _What is prototypal inheritance?_ _Can you explain, fundamentally, what are promises?_ _What are some differences between a function declaration and a function expression_?

My first thought right away was, how _simple_ must their codebase be?! I thought the company was looking for React devs! I now see that they were looking for competent Frontend Engineers, not people who can quickly spin up a Next app and boast about how they understand static generation. They wanted engineers who have mastered the fundamentals. These fundamentals can help solve any complex bug in the JS ecosystem. That's the beauty of being a master of the language.

Every error message in any framework is just because something was grinding against the way JavaScript works. However, JavaScript is complex. So how does JavaScript work?

## The Interview didn't go so well.

I realised I have a good gist of what's going on with JavaScript, but I struggled to explain the basics simply because I never looked inside the JavaScript _engine_. It was a **fantastic** lesson; I didn't want to feel resentful or upset with how little I know. Instead, I am using the experience as a way to learn. I want to be able to answer these questions. I always enjoyed looking underneath the hood; now it's time to **seriously** focus my direction towards the language that kick-started my career.

I want to start a book club. For myself. Potentially for you, too, the reader. I searched online (and my dusty bookcase) for an up-to-date, renowned textbook around JavaScript. I decided to start with [Eloquent JavaScript](https://eloquentjavascript.net/), highly regarded as an excellent JavaScript text. Also, I have skimmed through it before, and the author, Marijn Haverbeke, has a great voice.

I was a bit nervous to begin because it might be too basic at this point in my career. Starting with sections that explain what a [string](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String) is will quickly lose my interest. At this time of writing, however, I am pleasantly surprised with what I read so far.

This post will focus on chapter one. The series will focus on my notes and observations. It will be around the content I didn't know about JavaScript. I strongly recommend you read the book yourself. It's free, available for most devices, and possibly covers everything you need to know to get started with the language and programming in general.

## Chapter One

> Below the surface of the machine, the program moves. Without effort, it expands and contracts. In great harmony, electrons scatter and regroup. The forms on the monitor are but ripples on the water. The essence stays invisibly below.

<aside>
  - Master Yuan-Ma, <i>The Book of Programming</i>
</aside>

### Numbers and Memory

Dealing with types in JavaScript costs memory. If you need to store values in a variable (or _bindings_ as the author calls them), the variables need to occupy space on your computer. In typical modern computers, we have more than 30 billion bits in volatile working memory (think RAM). Nonvolatile storage, like SSDs or hard disks, have much, much more.

JavaScript's number type has a fixed number for bits. 64 bits to store a single number value. That's fascinating because, at first glance, it doesn't sound like a lot. When you begin understanding bits, you realise that what that means is that we have around `2^64` (2 to the power of 64) potential numbers. That equates to approximately 18 quintillion options.

That is a lot. Issues usually arise when dealing with massive numbers. Let's talk about all the grains of sand on our Earth. If we stored that value in a variable, we would still have around ten quintillion bits left to do whatever we want.

Some caveats include negative numbers that use an extra bit to signify the `-` sign and non-whole numbers like floats. If we consider all of that, we would still have 9 trillion combinations for whole numbers. Unfortunately, not enough to store all the grains of sand...

### Operators and Types

We have unary operators, rather than just binary operators. A binary operator would be something like `5 + 3`, where the plus symbol takes two values. A unary operator takes one value; hence the name. `typeof` is a unary operator that returns the value type.

There's only one ternary operator called the conditional operator. You might have seen it before: `true ? 1 : 2`.

`null` and `undefined` are peculiar types. The author says they are used interchangeably and are more or less the same thing. I can't entirely agree, as I see `undefined` as values that could exist later, whilst null symbolises the value's absence. I'd instead stick to just using undefined if I can, but it's always best to secure your types wherever possible. The author also mentioned that:

> The difference in meaning between undefined and null is an accident of JavaScript's design, and it doesn't matter most of the time.

Exploring that a little bit, I found this quote on a Stack Overflow [post](https://stackoverflow.com/questions/5076944/what-is-the-difference-between-null-and-undefined-in-javascript) explaining a bit more about the accident.

> Quote from the book Professional JS For Web Developers (Wrox): "You may wonder why the typeof operator returns 'object' for a value that is null. This was actually an error in the original JavaScript implementation that was then copied in ECMAScript. Today, it is rationalised that null is considered a placeholder for an object, even though, technically, it is a primitive value."

- Captain Sensible (great name)

In JavaScript, we also have automatic type conversion:

```js
console.log(8 * null);
// → 0 (null is converted to 0)
console.log('5' - 1);
// → 4 ('5' becomes 5)
console.log('5' + 1);
// → 51 (1 becomes '1')
console.log('five' * 2);
// → NaN (can't use *, /, or - on strings)
console.log(false == 0);
// → true (false becomes 0)
```

A neat tip is if you ever find yourself with `NaN` errors, keep in mind that further arithmetic operations on `NaN` keep producing `NaN`, so look where you might be doing any accidental type conversions.

It's also best to use the strict equal operator `===` as that allows you to _precisely_ test for equal values and avoids automatic type conversion.

## End of Chapter 1

That's it! As I get into the groove of writing these chapter recaps, I'll hopefully also learn to connect my notes. Currently, it's a little bit all over the place. I do hope you might've learned at least one thing. If anything was confusing here, please let me know, and I can try to explain further. Otherwise, you can check out chapter one on the author's website [here](https://eloquentjavascript.net/01_values.html).

Have you read the chapter? The book? let me know your thoughts in the comments, and if you think it's a great book to really master the fundamentals in JavaScript.

The next chapter focuses on **Program Structure**. We just learned about the nails; let's master swinging the hammer.

_Originally posted on my personal website, which can be found at [alex.kharo.uk](https://alex.kharo.uk)._