RizTech Academy logo
RizTech Academy
Getting StartedLesson 2 of 320 min

The console and browser devtools

You do not need to install anything to start writing JavaScript. The browser already in front of you has a full JavaScript environment built in, and a place to type into it. That place is the console, and you will spend more hours of your career in it than in any tutorial.

Opening it

Platform Shortcut
Windows, Linux F12 or Ctrl + Shift + I
macOS Cmd + Option + I
Any Right-click the page, then Inspect
Straight to the console Ctrl + Shift + J, or Cmd + Option + J on macOS

Devtools opens as a panel attached to the page. On a laptop screen it is worth dragging it to the right-hand side rather than the bottom — the three-dot menu in the devtools toolbar has a "Dock side" option. You will be reading code and the page at the same time constantly.

Everything below is Chrome, because that is what most people reading this have. Firefox and Edge have the same panels under very slightly different names, and Safari hides devtools until you tick Develop in its Advanced settings.

What the panels are for

You will use two of these heavily and the rest occasionally. Worth knowing they exist so you can come back.

Panel What it is for
Console Running JavaScript, reading errors and your own log output.
Elements The live structure of the page. Inspect and edit it, see the CSS applied.
Sources The actual files loaded. Set breakpoints and step through code — module 9.
Network Every request the page made, with timing, status and response body.
Application Stored data — localStorage, cookies. Module 7.
Performance Why something feels slow. Later than this course.

The console runs JavaScript immediately

Click into the Console panel and type this, then press Enter:

2 + 2
4

It answered. No file, no save, no build step. Try a few more:

145 * 2
"Priya".toUpperCase()
"toor dal".length
290
'PRIYA'
8

This is the fastest way to answer "what does this actually do", and the habit of checking rather than assuming is most of what separates people who get unstuck quickly from people who do not.

The undefined that frightens everybody

Now type this:

console.log("Toor dal: 145 per kg")
Toor dal: 145 per kg
undefined

Two lines. Almost everyone's first reaction is that something went wrong.

Nothing went wrong. The console does two separate things with what you type: it runs it, and then it shows you what the expression evaluated to. Those are different.

  • console.log(...) printed your text. That is its job.
  • console.log(...) then evaluated to nothing at all — it has no answer to give back. JavaScript's word for "no value" is undefined, so the console reported undefined.

Compare with 2 + 2, which printed nothing of its own but evaluated to 4.

In the console, the last line is the value of what you typed, not part of your output. Once you know that, the greyed-out undefined becomes invisible. Until you know it, it looks like a failure on every single line.

Typing more than one line

Pressing Enter runs what you have typed. To write several lines before running them, end each with Shift + Enter:

const rate = 145;
const kg = 2;
console.log(rate * kg);
290

For anything longer than about five lines, stop using the console and put it in a file — that is the next lesson. The console is for questions, not for programmes.

The console methods worth knowing

console.log is not the only one, and two of the others will save you real time.

Call What it does
console.log(x) The everyday one. Takes any number of arguments.
console.warn(x) Same, styled as a warning. Filterable.
console.error(x) Same, styled as an error, with a stack trace.
console.table(rows) Renders an array of objects as a sortable table.
console.count(label) Prints how many times this line has run.
console.time(label) / console.timeEnd(label) Measures elapsed time between the two.
console.group(label) / console.groupEnd() Indents everything between into a collapsible block.
console.dir(el) Shows a DOM element as an object rather than as markup.

console.table is the one people wish they had known about earlier. Give it an array of objects:

console.table([
  { item: 'Toor dal', kg: 2, rate: 145 },
  { item: 'Sugar', kg: 1, rate: 44 },
  { item: 'Mustard oil', kg: 1, rate: 168 },
]);

You get a real table with a column per property, one row per item, and clickable column headers that sort it. For checking twenty rows of data that is enormously better than twenty console.log lines.

console.count is the quickest way to answer "is this running twice?", which is a question you will have more often than you expect:

console.count('render');
console.count('render');
render: 1
render: 2

Reading an error

Type something broken on purpose:

totl
Uncaught ReferenceError: totl is not defined

Three pieces of information, and each matters:

  • Uncaught — nothing in the code dealt with this, so it stopped.
  • ReferenceError — the kind of problem. This one means a name was used that does not exist. You will meet TypeError and SyntaxError constantly too.
  • totl is not defined — the specific thing. Usually a typo, as here.

When an error comes from a file rather than the console, the right-hand side of the message is a file name and line number, and it is a link. Click it and devtools opens Sources at that line.

Read the whole message before changing anything. Beginners skim the red and start editing. The message almost always names the problem exactly, and the habit of reading it is worth more than any amount of guessing.

The trap: the console is not a faithful model of a script

This one causes hours of confusion, and almost nobody is told about it.

Devtools consoles deliberately relax some of the language's rules, because strictness is annoying when you are poking at something. So code can behave differently in the console than in a file. Two examples you will actually hit:

In a .js file, declaring the same name twice with let is a hard error:

let total = 100;
let total = 200;
SyntaxError: Identifier 'total' has already been declared

Current Chrome and Firefox consoles let you re-run a let line as many times as you like, because re-typing a line while experimenting is normal. Convenient — but it means the console will not warn you about a mistake a file would reject.

Second, await at the top level works in the console. In a plain script it does not, and you get a SyntaxError that makes no sense given it just worked. Module 8 explains the real rule.

So the console is where you check what a value is, not where you confirm your code is correct. When something works in the console and fails in your file, do not assume you are going mad — assume this, and move the code into the file to test it properly.

One related thing: variables you type into the console are gone on reload. That is not a bug either.

One shortcut worth the memory

$0 in the console is whatever element is currently selected in the Elements panel. Click a button in Elements, type $0 in the Console, and you have a reference to it — no selector needed. $1 is the one selected before that.

That pairing of the two panels is how you will inspect a page in practice: find it visually in Elements, then interrogate it in the Console.

Before you ship

console.log left in code that real people use is a small but genuine problem. It is visible to anyone who opens devtools, so a log of a user's details is a leak, and a page logging hundreds of lines on a slow phone is measurably slower.

Use it freely while building. Take it out before it goes anywhere, and use breakpoints instead once module 9 has shown you how.

To clear the console, Ctrl + L. To keep logs across page loads, tick "Preserve log" in the console's settings — essential when debugging something that reloads, and confusing if you leave it on and forget.

Check your work

console.log("hello") shows two lines. hello is your output; the greyed undefined underneath is the value the expression evaluated to. console.log prints and returns nothing, and the console always reports the value of what you typed. Nothing is wrong.

2 + 2 shows one line and console.log(2 + 2) shows two. 2 + 2 evaluates to 4, which the console reports. console.log(2 + 2) prints 4 itself and then evaluates to undefined.

"toor dal".length is 8. Seven letters plus the space. Length counts every character, spaces included.

totl gives Uncaught ReferenceError: totl is not defined. A ReferenceError means the name does not exist — nearly always a typo or a variable used before it was created.

Re-running let total = 100; twice. In the console, it is accepted. In a file, the second one is SyntaxError: Identifier 'total' has already been declared. The console relaxes the rule on purpose, which is exactly why it cannot be trusted to validate your code.

console.count called twice with the same label prints render: 1 then render: 2. It counts calls per label.

Practice

  1. Open devtools on any page and dock it to the right-hand side. Find all six panels from the table above and open each one once.
  2. In the console, work out the total for 2 kg of toor dal at ₹145, 1 kg of sugar at ₹44 and 1 litre of mustard oil at ₹168. Do it as one expression.
  3. Run console.log("anything") and say out loud what each of the two lines is. Do not move on until the undefined looks boring.
  4. Use Shift + Enter to write three lines that declare two const values and log their product, then run them together.
  5. Build the kirana stock array from the console.table example and sort it by rate by clicking the column header.
  6. Cause three different errors deliberately: a typo'd variable name (ReferenceError), calling a number as though it were a function like (5)() (TypeError), and an unclosed bracket (SyntaxError). Read each message and name which of the three pieces of information is which before you fix it.
  7. Select an element in the Elements panel, then type $0 in the console and look at what comes back. Then try $0.textContent.
  8. Prove the trap. Type let total = 100; and run it twice — the console accepts it. You cannot test the file half yet; note it down and come back after the next lesson, when you have a file to put it in. The point is to see the two environments disagree with your own eyes.

Next: getting JavaScript out of the console and into files — with a script tag in a page, and with Node on your machine.

Stuck on this lesson?

Being stuck is part of it — but being stuck alone for three days is not. Our internship programme pairs this curriculum with code review and one-to-one help from working developers, and it is free.

About the internship