JS – UP and Going (chapter 1)

here is some notes about You Don’t Know JS Book, i hope this article helps you with some new information about JS. there are another blogs about the book i divide each part of the book in an article.


Let’s start from the beginning.

A program, often referred to as *source code* or just *code*, is a set of special instructions to tell the computer what tasks to perform. Usually code is saved in a text file, although with JavaScript you can also type code directly into a developer console in a browser, which we’ll cover shortly.

The rules for valid format and combinations of instructions is called a *computer language*, sometimes referred to as its *syntax*.


In a computer language, a group of words, numbers, and operators that performs a specific task is a *statement*. In JavaScript, a statement might look as follows:
a = b * 2;

  • The characters `a` and `b` are called *variables*.
  • the `2` is just a value itself, called a *literal value* the `2` is just a value itself, called a *literal value*,
  • The `=` and `*` characters are *operators*
  • most JS statements ended by semicolon.


Statements are made up of one or more *expressions*. An expression is any reference to a variable or value, or a set of variable(s) and value(s) combined with operators.

For example:   a = b * 2;

This statement has four expressions in it:

  1.   ‘2` is a *literal value expression*
  2.  `b` is a *variable expression*, which means to retrieve its current value
  3.  `b * 2` is an *arithmetic expression*, which means to do the multiplication
  4.  `a = b * 2` is an *assignment expression*, which means to assign the result of the  `b * 2` expression to the variable `a` (more on assignments later)

A general expression that stands alone is also called an *expression statement*   (b * 2);

a more common expression statement is a *call expression* statement, as the entire statement is the function call expression itself:

alert( a );

Executing a Program

For some computer languages, the translation of commands is typically done from top to bottom, line by line, every time the program is run, which is usually called *interpreting* the code.

For other languages, the translation is done ahead of time, called *compiling* the code, so when the program *runs* later, what’s running is actually the already compiled computer instructions ready to go.

It’s typically asserted that JavaScript is *interpreted*, because your JavaScript source code is processed each time it’s run. But that’s not entirely accurate. The JavaScript engine actually *compiles* the program on the fly and then immediately runs the compiled code.

Converting Between Types

If you use the `==` loose equals operator to make the comparison `”99.99″ == 99.99`, JavaScript will convert the left-hand side `”99.99″` to its `number` equivalent `99.99`. The comparison then becomes `99.99 == 99.99`, which is of course `true`.

Code Comments

//  This is a single-line comment

/* But this is
a multiline

The `//` single-line comment is appropriate if you’re going to put a comment right above a single statement, or even at the end of a line. Everything on the line after the `//` is treated as the comment (and thus ignored by the compiler), all the way to the end of the line. There’s no restriction to what can appear inside a single-line comment.

The `/* .. */` multi-line comment is appropriate if you have several lines worth of explanation to make in your comment.


In some programming languages, you declare a variable (container) to hold a specific type of value, such as `number` or `string`. *Static typing*, otherwise known as *type enforcement*, is typically cited as a benefit for program correctness by preventing unintended value conversions.

Other languages emphasize types for values instead of variables. *Weak typing*, otherwise known as *dynamic typing*, allows a variable to hold any type of value at any time. It’s typically cited as a benefit for program flexibility by allowing a single variable to represent a value no matter what type form that value may take at any given moment in the program’s logic flow.

JavaScript uses the latter approach, *dynamic typing*, meaning variables can hold values of any *type* without any *type* enforcement.

As mentioned earlier, we declare a variable using the `var` statement — notice there’s no other *type* information in the declaration.



your program will almost certainly want to break up the code’s tasks into reusable pieces, instead of repeatedly repeating yourself repetitiously (pun intended!). The way to do this is to define a `function`.

A function is generally a named section of code that can be “called” by name, and the code inside it will be run each time.



*scope* (technically called *lexical scope*).

In JavaScript, each function gets its own scope. Scope is basically a collection of variables as well as the rules for how those variables are accessed by name. Only code inside that function can access that function’s *scoped* variables.

A variable name has to be unique within the same scope — there can’t be two different `a` variables sitting right next to each other. But the same variable name `a` could appear in different scopes.


Also, a scope can be nested inside another scope, just like if a clown at a birthday party blows up one balloon inside another balloon. If one scope is nested inside another, code inside the innermost scope can access variables from either scope.


Lexical scope rules say that code in one scope can access variables of either that scope or any scope outside of it.

Summary of chapter 1

  1. You need *operators* to perform actions on values.
  2. You need values and *types* to perform different kinds of actions like math on `number`s or output with `string`s.
  3. You need *variables* to store data (aka *state*) during your program’s execution.
  4. You need *conditionals* like `if` statements to make decisions.
  5. You need *loops* to repeat tasks until a condition stops being true.
  6. You need *functions* to organize your code into logical and reusable chunks.

Code comments are one effective way to write more readable code, which makes your program easier to understand, maintain, and fix later if there are problems.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s