Environments & Execution

JavaScript Environments & Execution

This guide details where to write JavaScript code, how to view the output, and how web browsers handle scripts differently based on their placement and loading strategies.

1. Where to Write JavaScript

There are three primary locations where JavaScript can be written and executed within the context of a web browser.

A. Inline/Internal Scripts (`<script>` tag)

You can write JavaScript directly inside an HTML file using the <script> tag. This is often used for small snippets or loading-critical logic.

Example:

<!DOCTYPE html>
<html>
<body>
    <h1>Hello World</h1>

    <script>
        // JS written directly inside HTML
        let message = "I am inside the HTML file!";
        console.log(message);
    </script>
</body>
</html>

B. External Scripts (`.js` file)

The standard industry practice is to write code in a separate file with a .js extension and link it to the HTML.

Example (logic.js):

let message = "I am in a separate file!";
console.log(message);

Linking in HTML:

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

C. The Browser Console

Every modern browser (Chrome, Firefox, Edge, Safari) has built-in Developer Tools. You can write and execute JavaScript line-by-line here.

How to access: Press F12 or Right-click -> Inspect -> Click the Console tab.
Use case: Debugging, testing small logic, or inspecting variables on a live site.

2. Where to Get the Output

Unlike HTML (which outputs visual structure) or CSS (which outputs style), JavaScript logic often happens in the background. Here is where the results appear:

A. The Browser Console

This is the most common output destination for developers. It does not affect the visible web page.

Method: console.log(), console.error(), console.table()
Result: Text appears in the Developer Tools Console panel.

B. The DOM (The Web Page)

To show output to the user, JavaScript must manipulate the Document Object Model (DOM).

Method: document.getElementById('id').innerText = "Result"
Result: The text or HTML elements on the webpage actually change.

C. Dialog Windows (Blocking)

These are system-level popups. They pause the entire browser script execution until the user clicks "OK".

Method: alert("Hello"), prompt("Enter name"), confirm("Are you sure?")
Result: A popup box overlaying the browser.

3. How Browsers Treat Scripts (Internal vs. External)

When a browser loads a website, it reads the HTML from top to bottom (parsing). The way it handles JavaScript depends on how and where it is included.

The Parsing Process (The "Render Blocking" Issue)

By default, JavaScript is synchronous and blocking.

The browser parses HTML lines.
It encounters a <script>.
It stops parsing HTML completely.
It downloads the script (if external) and executes it.
Only after the script finishes does it resume parsing the rest of the HTML.

Scenario A: Scripts in the `<head>`

If you put a standard <script> in the <head>, the browser runs it before the body exists.

Problem: If your script tries to find an HTML element (like a button), it will fail because that button hasn't been rendered yet.
Result: The user sees a blank white screen until the script downloads and runs.

Scenario B: Scripts at the end of `<body>`

This is the classic "safe" method.

Behavior: The browser renders all HTML and CSS first. The script is the last thing to run.
Benefit: The user sees the page content immediately, and the script can safely manipulate DOM elements.

Scenario C: External Files and Caching

This is the major difference between Internal and External scripts.

Internal (Inline): The browser must re-read this code every single time the user visits the page.
External (.js): The browser downloads the file once and saves it (Caches it). On the next visit, the browser loads the file from memory instantly, making the website significantly faster.

4. Modern Execution Control (`async` vs `defer`)

In modern development, we put scripts in the <head> but use attributes to tell the browser not to pause HTML parsing.

`defer` (Recommended)

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

Behavior: The script downloads in the background while the HTML parses. It waits to execute until the HTML is fully finished.
Order: Scripts execute in the exact order they appear in the code.
Best for: Standard website logic dependent on the DOM.

`async`

<script src="analytics.js" async></script>

Behavior: The script downloads in the background. It pauses HTML parsing the moment it finishes downloading to execute immediately, then resumes HTML parsing.
Order: Not guaranteed. Whichever script downloads first runs first.
Best for: Independent scripts like Google Analytics or Ads that don't care about the rest of your page.

Summary Table

Feature

Internal (Inline)

External File

Location

Inside HTML file

Separate .js file

Caching

No (Reloads every time)

Yes (Cached by browser)

Maintainability

Low (Clutters HTML)

High (Separation of concerns)

Performance

Faster for tiny snippets

Faster for large applications

Usage

Quick hacks, critical CSS/JS

Standard Application Logic

PreviousJavaScript NextDOM vs. BOM

Last updated 10 days ago

hashtagJavaScript Environments & Execution

hashtag1. Where to Write JavaScript

hashtagA. Inline/Internal Scripts (<script> tag)

hashtagB. External Scripts (.js file)

hashtagC. The Browser Console

hashtag2. Where to Get the Output

hashtagA. The Browser Console

hashtagB. The DOM (The Web Page)

hashtagC. Dialog Windows (Blocking)

hashtag3. How Browsers Treat Scripts (Internal vs. External)

hashtagThe Parsing Process (The "Render Blocking" Issue)

hashtagScenario A: Scripts in the <head>

hashtagScenario B: Scripts at the end of <body>

hashtagScenario C: External Files and Caching

hashtag4. Modern Execution Control (async vs defer)

hashtagdefer (Recommended)

hashtagasync

hashtagSummary Table