Adapted, not copied

Original notes for JavaScript360.org — topic order inspired by Eloquent JavaScript (4th ed.) by Marijn Haverbeke. See the full attribution note.

Chapter 13: JavaScript and the Browser

Estimated time: ~25 minutes · Chapter type: Concept

This chapter is a short, deliberately light one — a map of the territory before we get hands-on with the DOM, events, and canvas in the chapters that follow.

What you'll learn

• The (very abbreviated) journey from typing a URL to a running web page
• How <script> tags load and execute your JavaScript
• Why the browser sandbox exists, and what it restricts

Networks and the web, briefly

When you visit a URL, your browser sends an HTTP request across the internet to a server, which sends back a response — typically an HTML document, plus references to CSS and JavaScript files the browser will fetch next. Chapter 18 covers the HTTP protocol itself in more depth; for now, the important part is simply that HTML, CSS, and JavaScript are three separate files (or embedded blocks) that the browser combines to produce what you see and interact with:

• HTML describes structure and content — the what.
• CSS describes presentation — the how it looks.
• JavaScript describes behavior — the how it responds.

Getting your script onto the page

A <script> tag is how JavaScript gets attached to an HTML page, either inline or via src:

<script src="app.js"></script>

Where you place that tag — and which attribute you add — controls when it runs relative to the rest of the page loading:

<script src="app.js"></script>              <!-- blocks HTML parsing until it downloads and runs -->
<script src="app.js" defer></script>          <!-- downloads in parallel, runs after HTML parsing finishes, in order -->
<script src="app.js" async></script>          <!-- downloads in parallel, runs the instant it's ready — order not guaranteed -->

For most application code, defer is the right default: it doesn't block the page from rendering, and it guarantees your script only runs once the full DOM (Chapter 14) is available to manipulate. async is useful for independent scripts (like analytics) that don't need to touch the page and don't depend on load order.

The sandbox

Running arbitrary code from every website you visit would be catastrophically unsafe if that code could do anything it wanted to your computer. Browsers solve this by running JavaScript inside a strict sandbox:

• Scripts can't read or write arbitrary files on your disk.
• Scripts can't directly access other browser tabs, windows, or applications.
• The same-origin policy restricts a script from one site (https://a.com) from reading data belonging to a different site (https://b.com) — including cookies, local storage, and most network responses — unless that other site explicitly opts in (via a mechanism called CORS).

This sandbox is precisely why a script can manipulate the page it's running on (that's the whole point of client-side JavaScript) but can't reach out and touch your file system or another site's private data. Understanding this boundary matters the moment you start making network requests (Chapter 18) — a request that gets silently blocked is very often a same-origin policy issue, not a bug in your code.

A brief note on compatibility

Different browsers (Chrome, Firefox, Safari, Edge) are built by different organizations, on different rendering engines, and historically didn't always agree on how to implement web standards — the source of the (largely, though not entirely, historical) "browser wars" folklore you may have heard referenced. Modern browsers have converged dramatically thanks to shared standards bodies (like the W3C and WHATWG) and evergreen, auto-updating release cycles, but checking a resource like caniuse.com before relying on a brand-new API is still good practice for anything shipping to the public.

Key takeaways

• HTML, CSS, and JavaScript are separate concerns — structure, presentation, and behavior — that the browser combines.
• defer is the sensible default for loading application scripts; async suits independent, order-agnostic scripts.
• The browser sandbox (including the same-origin policy) exists to protect users from malicious scripts, and it directly shapes what your own code is and isn't allowed to do.

Try it yourself

1. Create a minimal HTML file with a <script defer> tag pointing at a JavaScript file that logs document.title — confirm it runs only after the page has parsed.
2. Look up what the crossorigin attribute on a <script> tag does, and when you'd need it.
3. In your own words, explain why a script running on https://your-bank.example.com should not be able to read cookies set by https://evil.example.com, and vice versa.

Hints

1. document.title will correctly reflect the page's <title> even from a <script defer> placed in the <head>, because it waits for parsing to finish.
2. It controls whether the browser sends credentials with a cross-origin script request, and whether detailed error information is exposed to your code for that script.
3. Without the same-origin policy, any site you visit could silently read your session cookies or private data from every other site you're logged into.

Summary

The browser is a hostile-by-design execution environment, and that's a feature, not a limitation — it's what lets you safely visit any website without worrying it'll read your files. With that context in place, we're ready to open the actual door JavaScript is given into a page: the Document Object Model.

 

Up nextCh. 14 — The Document Object Model~40 min