100 days of code — day 17 & 18, core JS

Finished another chapter in “Coders at Work”, this time it was Douglas Crockford, the creator of JSON. In the interview he pointed out some sweet features of JS, he described his own “eureka”-moment when he understood closure, something I look forward to.

In the end of the interview, he turns a bit pessimistic, pointing out that we have this amazing tool for communication, but it is all a huge mess right now, buggy and fuzzy, ad hoc solutions and glitter on top. His words almost have a prophetic ring to them, in our time of fake news and the recent banning of Alex Jones, and other such noise.

Mad Ha(t)ter got haters

I continued reading YDKJS, patiently and slowly. And I learned new stuff, here about built in functions in JS:

Briefly, there is a String (capital S) object wrapper form, typically called a "native," that pairs with the primitive stringtype; it's this object wrapper that defines the toUpperCase() method on its prototype. A string value can be wrapped by a String object, a number can be wrapped by a Number object, and a boolean can be wrapped by a Boolean object.

Fancy, object-wrapping.

I also took a small peek into the concept of truthy/falsy. The following list contains “falsy” values in JS:

  • “” — empty double quotes
  • ‘’ — empty single quotes (both examples here are empty strings)
  • 0 , -0, NaN (Not A Number, invalid number)
  • null, and undefined
  • false

On the other side, we have the truthy-values, like:

  • “hello” — non empty string
  • 42 — an actual number
  • true
  • [ ] , [1, “2”, 3] — arrays, empty or not
  • { }, { a: 42 } — objects, empty or not
  • function foo() { … } — functions

When talking about comparing values, there are four equality operators: ==, ===!=and !==. As we all know from mathematics, the ! sign works as a negation. In YDKJS there is an important quote:

The difference between == and === is usually characterized that == checks for value equality and === checks for both value and type equality. However, this is inaccurate. The proper way to characterize them is that == checks for value equality with coercion allowed, and === checks for value equality without allowing coercion; === is often called "strict equality" for this reason.

The example he provides is as follows:

var a = "42";
var b = 42;

a == b; // true
a === b; // false

Here is a nice picture I made myself, to break it even further down, using boxes as an analogy:

… little boxes made of ticky tacky…

So, double equals comparison without coercion, will in JavaScript give you, well, interesting results:

A bit convoluted… Source

Coercion in JavaScript apparently is a very hot potato, and after asking my clever coworker, I will stick to triple equals, until I understand coercion properly.


The rest of the introductory chapter one of YDKJS was a bit over my head, but I continued to book two, “Scope & Closures”.

Openture > Closure

Here, he starts by explaining how JS-code is being compiled in microseconds (or less) before its execution.

I spent quite some time trying to understand the difference between LHS and RHS look-ups and variable assignments. It is a bit confusing, but not incomprehensible. The “engine”, “scope” and “compiler” interact and cooperate with each other. The compiler first declares variables (unless already declared in the current scope), and then when executing, the engine finds the variable in the scope and assigns to it, if found in the scope. An important quote from the text is:

LHS and RHS meaning “left/right-hand side of an assignment” doesn’t necessarily literally mean “left/right side of the = assignment operator". There are several other ways that assignments happen, and so it's better to conceptually think about it as: "who's the target of the assignment (LHS)" and "who's the source of the assignment (RHS)".

Consider my program:

function printStuff(a){
console.log(a); //420
}
var number = 420;
printStuff(number);

The last line invokes the function printStuff(), and as a function-call, the engine requires an RHS reference to fetch the value of number. Right above, we have the var number = 420;, where the engine needs a LHS lookup.

Why is this important? The engine will use both of these lookups to find the relevant values of variables. If the variable, in a LHS lookup, cannot be found in the scope chain, e.g nested scopes and such, a global variable will be created, or you will get a ReferenceError. In the same way, if a variable cannot be found in the scope chain for a RHS lookup, a ReferenceError will be thrown. If the RHS lookup is successful, but your action on the value is impossible, the engine will throw a TypeError. In the words of YDKJS:

ReferenceError is Scope resolution-failure related, whereas TypeError implies that Scope resolution was successful, but that there was an illegal/impossible action attempted against the result.

So, anytime the ReferenceError pops up, it is related to a scope failure. The more you know.


Puh, that was quite the load. When I came home I read chapter 17 in “Enlightenment Now” named “Quality of life” and it gave me a broad smile. I started reading chapter 18, about happiness, but it made me outright miserable. Go figure.

Anyhow, that is a wrap. Snakkes.