This content originally appeared on DEV Community and was authored by Alex Kharouk
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.
This content originally appeared on DEV Community and was authored by Alex Kharouk
Alex Kharouk | Sciencx (2021-07-03T16:19:27+00:00) Book Club: Eloquent Javascript – Chapter One. Retrieved from https://www.scien.cx/2021/07/03/book-club-eloquent-javascript-chapter-one/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.