An Introduction to JavaScript

Before you write a single line, it helps to know what you’re actually holding. This first lesson maps the territory: where JavaScript came from, how it runs, what it’s allowed to touch, and why — decades later — it’s still the language every browser speaks natively.

What is JavaScript?

JavaScript was born with one job: to make web pages do things. A static page of HTML just sits there. Add a script and suddenly it can respond to a click, validate a form, animate a menu, or fetch fresh data without reloading.

Programs written in this language are called scripts. You can write them directly inside a page’s HTML, and they run on their own as the page loads — no separate launch step, no “compile then execute” ritual that you manage by hand.

That last point is the heart of it: scripts ship and run as plain text. The browser receives ordinary source code and runs it. There’s no build artifact you have to produce first, the way you would with a compiled language.

For a long time the browser was the only place JavaScript could live. That’s no longer true. It now runs on servers, on desktops, on embedded devices — anywhere you can install a piece of software called a JavaScript engine.

A browser ships with an engine built in. You’ll sometimes hear it called a “JavaScript virtual machine.” It’s the part that reads your code and makes it happen.

Different engines carry different codenames:

• V8 — powers Chrome, Opera, and Edge.
• SpiderMonkey — powers Firefox.
• Others include “Chakra” (older Internet Explorer), and “JavaScriptCore” / “Nitro” / “SquirrelFish” in Safari.

Those names are worth filing away, because developer articles use them as shorthand. If you read that “feature X is supported in V8,” you can translate that to “it works in Chrome, Opera, and Edge.”

What can in-browser JavaScript do?

JavaScript in the browser is deliberately a “safe” language. It gives you no direct handle on raw memory or the CPU, because the browser never needed to hand that power to random pages downloaded from the internet.

What a script can reach depends heavily on where it runs. This is the single most important idea to carry forward: the language is the same everywhere, but the surrounding environment decides which extra abilities are on the table. Node.js, for example, hands scripts the power to read and write files anywhere on disk and to open arbitrary network connections — powers a browser page would never grant.

Inside a browser, JavaScript’s world is the page, the user, and the server the page came from. Within that world it can:

• Inject new HTML, rewrite existing content, and restyle elements.
• React to what the user does — clicks, pointer movement, key presses.
• Talk to remote servers over the network to download and upload data (the techniques historically labeled AJAX and COMET).
• Read and set cookies, prompt the visitor with questions, show messages.
• Store data on the user’s own machine using local storage.

What CAN’T in-browser JavaScript do?

The flip side of “safe” is a set of hard walls. A page you visit is code written by a stranger, running on your machine. The browser’s job is to make sure that stranger can’t rifle through your files, spy on you, or reach into your other tabs. So it fences JavaScript in.

Here’s what those fences block:

• No free access to your disk or OS. A page can’t quietly read, write, copy, or run files, and it can’t call operating-system functions. Modern browsers do let scripts work with files — but only ones the user hands over deliberately, by dropping a file onto the page or picking it through an <input> element. The same gate applies to the camera and microphone: a script can use them, but only after the user grants explicit permission. No page can silently switch on your webcam and stream your living room somewhere.

• Tabs don’t casually see each other. Two pages open in separate tabs generally have no idea the other exists. There’s one narrow exception — when a page uses JavaScript to open another window it holds a reference to it — but even then, if the two pages come from different origins (a different domain, protocol, or port), neither can read the other’s contents. This rule is the Same-Origin Policy. When two pages genuinely need to share data across origins, both sides have to opt in with cooperating code. Without it, a page on http://anysite.example.com could crack open your http://gmail.example.com tab and steal what’s there.

• Cross-site network requests are restricted. A script can freely talk to the server its own page came from. Reaching out to a different server is another matter: it’s possible, but the remote server has to say “yes” explicitly through HTTP headers. Same reasoning — the browser won’t let one site silently pull your data out of another.

None of these walls exist when JavaScript runs outside a browser — on a server, say, where your code is the trusted code. And even in the browser, installed plugins and extensions can request extended permissions that ordinary page scripts never get.

What makes JavaScript unique?

Plenty of languages can do impressive things. JavaScript’s edge in the browser comes from a specific combination that nothing else matches:

No other browser technology checks all three boxes at once. That’s the whole reason JavaScript became — and stayed — the default tool for building things people interact with in a browser.

Its reach doesn’t stop there. The same language powers servers, mobile apps, desktop apps, and more. But the browser is where its combination of traits is genuinely unrivaled.

Languages “over” JavaScript

JavaScript’s syntax doesn’t please everyone, and no single set of features fits every team. Different projects want different things — stricter typing, terser syntax, a language they already know from somewhere else.

So a whole family of languages grew up around JavaScript. You write in one of them, and a tool transpiles (translates) your source into JavaScript before it reaches the browser. Modern tooling makes that translation fast and nearly invisible: you code in language X, and JavaScript comes out the other side automatically.

A few you’ll run into:

• CoffeeScript — syntactic sugar over JavaScript, with a shorter, cleaner syntax that often appeals to Ruby developers.
• TypeScript — adds strict data types to make large systems easier to build and maintain. Created by Microsoft, and by far the most widely used of the bunch today.
• Flow — also adds typing, with a different approach. Created by Facebook.
• Dart — a standalone language with its own engine for non-browser environments like mobile apps, which can also transpile to JavaScript. Created by Google.
• Brython — translates Python into JavaScript, so you can write browser apps in pure Python.
• Kotlin — a concise, safe modern language that can target the browser or Node.

There are more. But here’s the catch worth remembering: even when you write in one of these, it becomes JavaScript before it runs. To really understand what your program does — and to debug it when it misbehaves — you still need to know JavaScript underneath. That’s what the rest of this course gives you.

Summary

• JavaScript started as a browser-only language and has since spread to servers, mobile, desktop, and beyond — anywhere a JavaScript engine can run.
• In the browser it holds a genuinely unique spot: the only technology that integrates fully with HTML/CSS, keeps simple things simple, and ships enabled by default in every major browser.
• Its browser powers are fenced in for safety — no free disk access, no peeking into other origins, no silent cross-site requests — and those fences are exactly what make the web safe to browse.
• A family of languages transpiles down to JavaScript. They’re worth a look once you’re comfortable with the language itself, but JavaScript remains the thing they all become.