There is joy in reading about JavaScript. It's like catching up with an old friend who is sharing what they've been doing. Lots of cool new ideas; super popular. Yet fundamentally, they haven't changed. They're the same, weird, sometimes awkward friend. That first friend, for some of us. In the end, we're just happy they're doing well.

That's the sensation I'm getting with reading Eloquent JavaScript. Last time, I began reading the book after a difficult interview. It opened my eyes that I know Javascript, but do I really know JavaScript? I've received comments that I should read Kyle Simpson's YDKJS (You Don't Know JS) books. I do own them. I suppose I didn't want to start with a series. I wanted a beginning-to-end kind of story. That said, I wouldn't be surprised if I decide to pick it up after Eloquent JavaScript.

On to Chapter 2, Program Structure.

And my heart glows bright red under my filmy, translucent skin and they have to administer 10cc of JavaScript to get me to come back. (I respond well to toxins in the blood.) Man, that stuff will kick the peaches right out your gills!

-_why, Why's (Poignant) Guide to Ruby

First of all, what a great quote. I read Why's guide a long time ago. It was humorous and showed me how diverse programming language communities are. Okay, back to the chapter two.

Expressions and Statements

We begin with understanding what expressions are and what are statements. Anything that produces a value is an expression. Anything that is written literally is also a value. 22 is an expression. "hello world" is an expression. Within a line of code, there can be multiple expressions. With that said, the line of code itself would be a statement. 1 is an expression, 1; is a statement.

Notice the difference?

I like to look at expressions as nouns — statements as verbs or actions. The action can sometimes be implicit, however. In JavaScript, you don't always need to add the ; to denote the end of a statement, so sometimes, you can omit explicit statements for implicit ones.

Statements can be simple, like 1;. But these statements aren't interesting; they are useless. Interesting statements affect something. Have an impact on its world. They could display something on the screen or update the state of a program. These statements can impact other statements, creating what is known as side effects.

Side effects might sound familiar to you if you use React Hooks. I've encountered that description due to learning about useEffect. I always thought side effects were something that the React developers referenced. It's much more than that. A side effect is simply a statement containing an action or result that could impact other statements.

Bindings

Marijn uses bindings to describe a way to store data and keep an internal state. If that sounds familiar to you, it may be because you know what variables are. However, Marijn seems to insist and call them bindings. I suppose it has something to do with their definition of a variable.

A variable is labelled as "not consistent" or having a fixed pattern; it is liable to change. This is partly correct with JavaScript variables. Using keywords like let or var makes sense with this definition. Using the keyword const does not fit this definition. Another way I was taught variables was by thinking about them as boxes. You are designating boxes for data you want to store and use later. If you need that data, you open up the box.

The author asks you to think a bit differently. Think of variables, or bindings, like tentacles rather than boxes. Think of them as pointers to values rather than containing values. Here's an example:
let ten = 10. ten doesn't unpack and reveal the data 10. What it does is it returns you the number 10 that it references.

It's a curious way of thinking about variables, and maybe a bit too much time was spent thinking about whether they're more like boxes or tentacles. I believe the author to be correct. Variables are references to data in memory. If we look at the code, we see that they are equal when comparing the two bindings. Why? Because 10 is saved in memory once, and both ten and anotherTen variables reference the number. Same with the string example.

let ten = 10;
let anotherTen = 10;
console.log(ten === anotherTen); // true; they are equal

let word = 'hello';
let anotherWord = 'hello';
console.log(word === anotherWord); // true

Again, something as simple as variables creates a discussion! It's fascinating how, when I first studied Javascript, I essentially skimmed through why things were the way they are. The rest of the chapter discusses loops and conditional execution (if-statements). If you are unsure about these topics, please make sure you read the chapter. Otherwise, I've noticed two things that I was not familiar with when using loops.

Do, while loop.

let yourName;
do {
  yourName = prompt('what is your name?');
} while (!yourName);

The difference here is that we always execute the block at least once. We always prompt the user for their name.

If they don't enter an accepted value, we will be in a loop until we get the name. I usually don't use do, while loops, but it's good to remember as a reference. Another thing about loops, specifically traditional for loops, is that they must contain two semicolons. I write the usual syntax so frequently that I never contemplated why I needed the semicolons in the loops. Well, the statement before the first semicolon is an expression or variable declaration. After the first semicolon, we have the condition, an expression that is evaluated before each loop iteration. Lastly we have the final expression, which will be evaluated at the end of each loop iteration.

//Notice empty space  v -- we don't set a condition so it can run forever if we let it
for (let current = 20; ; current = current + 1) {
  if (current % 7 == 0) {
    console.log(current);
    break;
  }
}

var i = 0;
for (;;) {
  if (i > 3) break; // we need the break statement, and still need the two semicolons!
  console.log(i);
  i++;
}

So that's it for Chapter two of the book. What did you think of it? Do you think I focused too much on the theory rather than explaining other aspects, such as loops or if-conditions? Are you enjoying the book yourself? I thought this chapter was a bit of a slower pace compared to the first chapter. A minor spoiler, but I have also read the third chapter Functions, and things pick up. By far my favourite chapter, so it's worth getting through chapter two.

Big thanks for the comments from the dev.to community. If you'd like to see some additional resources recommended by the community, check out the thread for the first chapter here.

Until next time.

Originally posted on my personal blog website, which you could see at alex.kharo.uk

Extra Exercises:

Chapter 2 introduced some exercises, which included a FizzBuzz exercise. My first attempt was the traditional way:

// print fizzBuzz from 1..n
function fizzBuzz(count) {
  for (let i = 1; i <= count; i++) {
    if (i % 15 === 0) console.log('FizzBuzz');
    else if (i % 3 === 0) console.log('Fizz');
    else if (i % 5 === 0) console.log('Buzz');
    else console.log(i);
  }
}

However we were told to think about a cleverer solution, combining the printed text together:

function fizzBuzz(count) {
  for (let i = 1; i <= count; i++) {
    let word = '';
    if (i % 3 === 0) word += 'Fizz';
    if (i % 5 === 0) word += 'Buzz';
    console.log(word || i);
  }
}