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, 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 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.
- Master Yuan-Ma, The Book of Programming
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 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:
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.
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.
Top comments (12)
You may be interested in undefined vs. null revisited.
In Chapter 2 pay particular attention to:
It's a subtlety that lots of people overlook about the language and the reason why that section prefers the term binding over the more commonly used variable.
MDN: Primitive:
These are some fantastic follow-ups, thanks for sharing. I'm almost done chapter two and I have noticed how the author particularly references bindings. It's a good way of looking at it.
I would say go through "You don't know JS" by Kyle Simpson also, if you want to excel and make a firm grip over JS. I loved the books and the syllabus and it is most informative.
Yes Ashish, I've been meaning to read that series too. Perhaps after I finish Eloquent Javascript! Would you recommend reading the older books or wait until Kyle has finished writing the new editions?
The 1st Edition books (other than ES6 & Beyond) are ES5.1 based and are due to JavaScript's backward compatibility still relevant. That said ES2016 through ES2022 have added capabilities (also ES5 to ESNext) some of which will have an impact on the 2nd Edition. While modern JavaScript may have de-emphasized some pre-ES2015 features and practices, fundamental JavaScript behaviour hasn't changed - there is just more of it. Short of being deprecated outright, one also has to be careful of assuming that older features are displaced. For example all too often people seem to ignore promises (ES2015) because of the introduction of async functions (ES2017) when understanding promises makes it much easier to understand potential issues with async/await (Creating a JavaScript promise from scratch, await vs return vs return await).
FYI: Before diving into async programming (i.e. before Chapter 11) make sure to watch The Event Loop - perhaps multiple times; after the chapter read Tasks, microtasks, queues and schedules and perhaps watch Scheduling Tasks - HTTP 203.
In my opinion the biggest impact of ES2015 wasn't classes but modules. I'm not suggesting to ignore classes but I do believe they are often over-emphasized (How to decide between classes v. closures in JavaScript). An awful lot can be accomplished with just functions, objects and modules - i.e. don't assume that everything has to be a class by default, use them when they provide tangible value.
Some other resources that may be worthy of attention at some point of time:
This isn't a must read list, more like - there is something of value here. But be prepared to live in the MDN Web Docs.
Interestingly with its 1000+ pages PJfWD4e still doesn't get into the ubiquitous parts of the tool chain like npm, node.js, bundlers etc. Given how quickly the ecosystem moves anything beyond online docs and short tutorials just gets stale way too quickly. Unfortunately Modern JavaScript Explained For Dinosaurs is getting a bit long in the tooth (and I would only recommend webpack if the relevant framework ecosystem standardized on it).
Practice as much as you can by taking advantage of places like exercism or codewars.
Man! Very nice of you for sharing your experience and laying path for us. Thanks for sharing!
If you want I have first edition set as pdf. Second edition will take time to complete, in present I think only two books are out.
I would love to read your summaries as I don't have enough time to read the whole book now but I always wanted to read this book.
Thanks Kumar! Will try to do it justice then.
I have recently started out on chapter one of the book. Its a great piece I must say, and your summary is spectacular. Great job 👍
Thanks a lot @usenmfon_uko ! Hopefully we both finish the book and learn something new together.
Good one!