What JavaScript is, and where it runs

You have already run JavaScript today. Every website you opened ran some, in your browser, without asking you. Before you write any, it is worth ten minutes on what it is, where it runs, and — the part most tutorials skip — what it will never do for you.

What JavaScript actually is

JavaScript is a programming language. You write plain text, and something reads it and carries out the instructions.

What makes it unusual is not the language. It is the position it holds: every web browser in the world runs JavaScript, and no browser runs anything else. If you want code to execute inside a web page — respond to a tap, validate a form, update a total without reloading — JavaScript is not the best option available. It is the only one.

That is worth being clear-eyed about. Python is popular because people chose it. JavaScript is unavoidable because of a decision made in 1995, when Netscape gave one engineer ten days to add a scripting language to their browser. Ten days is not long enough to design a language carefully, and you will meet the consequences in module 2.

None of that makes it a bad language to learn. It makes it an honest one to explain.

JavaScript is not Java

The name was a marketing decision. Java was popular in 1995, so Netscape borrowed the word.

The two languages are unrelated — different creators, different companies, different design, different uses. A Java developer reading JavaScript recognises the curly braces and almost nothing else. If you search for a JavaScript problem and land on Java answers, you have not found a dialect of your language; you have found a different one.

Where it runs

Two places matter to you, and they are genuinely different environments.

In the browser. Chrome, Firefox, Safari on somebody's mid-range Android on patchy mobile data. Here JavaScript can read and change the page, react to taps and typing, and fetch data over the network. It cannot read files off the person's phone or open a database connection, and that restriction is a security feature, not a limitation to work around.

In Node.js. Node took the JavaScript engine out of Chrome and let it run on a server or your laptop. Here JavaScript can read files, listen on a port, and talk to PostgreSQL — but there is no page to change, so none of the browser instructions exist.

The same language, two sets of surroundings. A lot of beginner confusion is one line of code being pasted into the wrong one of these. We use both in this course and always say which.

Beyond those two: VS Code is a JavaScript application. So is WhatsApp Desktop. React Native builds mobile apps from it. Google Sheets automates with it. The language spread far past the browser, largely because so many people already knew it.

What it is not for

Three honest exclusions, so you do not spend six months going the wrong way.

Native mobile apps. Android is Kotlin, iOS is Swift. React Native does build real apps from JavaScript and real companies ship them, but if a native mobile app is your actual goal, start with the Kotlin course on this site instead and come back here later.

Data analysis and machine learning. This is Python's territory and the gap is not close. Pandas, PyTorch and scikit-learn have no serious JavaScript equivalent.

Anything that must stay secret. This one catches beginners and it matters. Code you send to a browser is code you have given away. Anyone can open devtools and read it, change it, or skip it. So a price calculated in the browser, a discount rule checked in the browser, a password compared in the browser — all of these are suggestions, not controls. Never trust the client. Validation in the browser is for being kind to users; validation on the server is for being correct. You will hear this again in the async module and in every backend course here.

Why it has a reputation for confusing people

Some of that reputation is deserved. Three things are genuinely hard, and this course confronts each rather than hoping you absorb it.

First, the language converts types behind your back:

console.log("5" - 2);
console.log("5" + 2);

3
52

Subtracting turned the text "5" into the number 5. Adding turned the number 2 into the text "2" and joined them. Both lines are valid, neither warns you, and on a billing page that is a wrong total rather than an error. Module 2 explains exactly why and gives you the rule that avoids it.

Second, this changes meaning depending on how a function was called — not where it was written. Module 3 spends a whole lesson on it.

Third, most useful work is asynchronous: you ask for data and carry on before it arrives. Get this wrong and your function returns undefined for reasons that appear supernatural. Module 8 takes it slowly, and it is the most important module in the course.

None of these are things you grow out of by writing more code. People write JavaScript for years while avoiding them. Learning them properly now is most of the value here.

ECMAScript, ES6, and dating a tutorial

ECMAScript is the written standard; JavaScript is what browsers implement from it. In practice people use the names interchangeably.

Name	Year	What it brought
ES5	2009	The old baseline. `var`, no classes, no modules.
ES6 / ES2015	2015	The big one: `let`, `const`, arrow functions, classes, promises, modules, template literals.
ES2016–ES2019	yearly	`async`/`await`, `includes`, object spread.
ES2020+	yearly	Optional chaining `?.`, nullish coalescing `??`, `Array.at`.

Since 2015 there has been a small release every year, so "ES6" has drifted into meaning "modern JavaScript" rather than one specific version. Everything in this course is modern — roughly ES2020 and later, which every browser in use in India today supports.

You will find a great deal of obsolete JavaScript online, and it is worth being able to spot it in about five seconds:

var on every line instead of let and const
$(document).ready or any $ — that is jQuery, a library from a time when browsers disagreed with each other
XMLHttpRequest rather than fetch
Deeply indented function(err, data) callbacks instead of async/await

Code like that mostly still runs. It will teach you habits you then have to unlearn, which is more expensive than finding a better tutorial.

No framework in this course

React, Vue and Angular are what most JavaScript jobs actually use, and this course teaches none of them.

That is deliberate. A framework hides the language behind its own ideas, and when something misbehaves you cannot tell which layer is responsible. People who learn React on shaky JavaScript spend a year unable to answer "is this React being strange, or me?"

Name the cost honestly: doing the DOM by hand is more verbose than React. In module 7 you will write ten lines that React would have given you for free, and it will feel like the long way round. It is a cost you pay once. Afterwards every framework reads as a convenience rather than magic, because you know what it is being convenient about.

Where this course takes you

By module 10 you will have built an order tracker for a tiffin service, running in a browser with no framework: record each day's orders, plates and rate in rupees, a running monthly total that is correct to the paisa, validation that rejects a bad phone number, data that survives a reload, and a deployed URL you can send someone.

Along the way you get the parts tutorials skip — how to read a devtools error, why your total is ₹0.30000000000000004, and what to do when the network on a mid-range phone is slower than your laptop ever showed you.

Check your work

No code to run yet, but four questions with definite answers.

Why is JavaScript unavoidable for web front-ends? Because browsers run nothing else. It is the only language that executes inside a web page — a consequence of history, not a judgement about quality.

What does "5" + 2 produce, and what does "5" - 2 produce? "52" and 3. + joins text when either side is text; - has no meaning for text, so both sides are converted to numbers first. No warning either way.

Name one thing JavaScript should never be trusted with. Anything that must stay secret or cannot be tampered with — prices, discounts, permissions, password checks. Browser code is fully visible and fully editable by the person using it. Validate in the browser for kindness, on the server for correctness.

Which should you learn first if your goal is an Android app? Kotlin, not this. React Native is real, but a native language is the honest starting point, and the Kotlin course is built for it.

Practice

No code for this one. Three things instead.

Open devtools on a site you use every day and find the Sources or Debugger panel. You are looking at somebody's actual JavaScript, shipped to you. Note that you can read all of it. That is the "never trust the client" rule made concrete, and it is worth seeing once with your own eyes rather than taking on trust.
Search for "javascript array tutorial" and date the first three results. Use the list above: var everywhere, a $, XMLHttpRequest. Being able to reject a stale tutorial in five seconds will save you more time on this course than any single lesson.
Write down, in one sentence, what you want to build. Specific beats ambitious: "a page that tracks who has paid their share of the flat rent" is worth more than "learn web development". Keep it somewhere visible. In module 8, when a promise resolves in the wrong order and nothing makes sense, that sentence is what brings you back to the keyboard.

Next: the console — where you will run your first JavaScript, with nothing to install.