I did not know that I didn't know javascript—weird right? After all, it was my first programming language which I have been coding in for over 6 years, but this does not mean that I am a professional js scripter. I just learned how to use JS to solve my problems. So while working on a task in my place of work, my current CTO asked a javascript-related question which I thought I knew but of course, you should have figured out by now that I did not 🤨 . Funny right 🤣, how do we sometimes think we know everything? This got me thinking about whether I really do know JS. Fortunately, I remember coming across Kyle Simpson's book 'YDKJS series' once and I never thought I will have to read this book in my life since I thought I knew Javascript so well.

Ok, with that being said. The point of this article is to open your eyes to some of the key takeaways I learned from the first part of the series also there will certainly be links that I will add to this article at the end. I will be breaking this article into bullet points so that you can easily digest it. Ok let's get right at it

• Javascript Code

  Usually, JS is thought of as an interpreted language just because the source code is processed each time it runs but it's not entirely accurate. JS engine actually compiles that code on the fly and then runs the compiled code. It does not generally have to create an executable file so it can be called a compile language. Think about it. If you disagree please you can add your reason in the comment section after all we are all learning.

• Value And Types

  The concept of literals is just values existing in a JS source code for example

    let title  = "You don't know JS"
    console.log(title) // "You don't know JS"
    let n = 34; // n - 34
  

  Assuming there was a compiled version of JS in another reality which of course does not exist this will have been hard coded alongside the compiled version. The same goes for numbers, booleans.

  Types in JS often involve the implicit and explicit coercion which some people may have referred to as casting which is certainly wrong in the JS domain.

  Coercion can be learned even though people tend to say it is dangerous but we will talk about this in a later part.

Comments

Code is like humor. When you have to explain it, it’s bad. – Cory House

Found the above in a Twitter discussion here. Obviously, this is right and also wrong. Code is sometimes meant to be explanatory in that it explains itself like a story but also not all stories are self-explanatory. For this reason :

1. Code without comment is suboptimal

2. Too many comments are an indicator of a poorly written code

3. Comment should explain why and not what the code is doing.

Essentially these are the key takeaways for the first part of the discussion of this series.

So as not to be boring, this article will be broken down into parts which will be released in sequence.

Please share your thought about the article and if you find it interesting you can follow me on LinkedIn here