How to write your first JavaScript program

A frequent source of confusion for those new to the language stems from a failure to recognize that JavaScript code does not execute in a vacuum. It always runs within a specific host environment. While the core language-its syntax, operators, control structures, and standard built-in objects like Array, Date, and Math-is defined by the ECMAScript specification, the environment provides additional functionalities, often called host objects, that are not part of the core language. Understanding the distinction between the two primary environments is crucial for writing effective and predictable code.

The first and most familiar environment is the web browser. Here, JavaScript’s primary role is to create dynamic and interactive user experiences. To facilitate this, the browser exposes a set of APIs for manipulating the web page content, known as the Document Object Model (DOM), and for interacting with the browser itself, known as the Browser Object Model (BOM). The global object in a browser environment is window, and any code that interacts with the page, such as finding an element by its ID, relies on these browser-specific APIs.

// This code is valid only in a browser environment.
// 'document' is a host object provided by the browser.
const pageHeader = document.getElementById('main-header');

The second major environment is Node.js, a runtime that allows JavaScript to be used for server-side and command-line applications. Its purpose is fundamentally different from a browser’s. Instead of manipulating web pages, Node.js applications typically interact with the server’s file system, manage network connections, and handle database operations. Consequently, it provides a different set of host objects and modules. For instance, it offers a built-in fs module for file system access, something a browser environment explicitly forbids for security reasons.

// This code is valid only in a Node.js environment.
// 'require' and 'fs' are specific to the Node.js runtime.
const fs = require('fs');
const fileContents = fs.readFileSync('./config.json', 'utf8');

This duality implies that code written for one environment is not guaranteed to work in the other if it depends on host-specific objects. Attempting to access document or window in a Node.js script will result in a runtime error, as these objects simply do not exist in that context.

Make console.log your most trusted tool

Given the non-obvious nature of JavaScript execution environments and the language’s dynamic typing, it becomes imperative to have a reliable method for inspecting the state of your program as it runs. The most fundamental, universally available, and effective tool for this purpose is console.log. While not formally part of the ECMAScript specification, the console object is a host object provided by virtually every modern JavaScript environment, including all web browsers and Node.js. Its primary role is to provide a logging mechanism to a developer console, offering a non-intrusive window into your code’s behavior.

Its most basic use is to confirm that a piece of code is being executed or to print the value of a variable at a specific point in time. Unlike older, more disruptive methods like the browser’s alert(), which halts all script execution, console.log operates asynchronously in the background, allowing your program to continue running unimpeded.

console.log('Initializing application...');

let score = 0;
console.log('Initial score:', score);

// ... some operations happen that modify the score ...
score = 150;

console.log('Final score:', score);

This simple act of logging variable states before and after operations is the cornerstone of debugging. It allows you to verify your assumptions about how values are changing. Where console.log becomes truly powerful, however, is in its handling of complex data types. When passed an object or an array, most developer consoles will not simply print a flattened string representation. Instead, they provide an interactive, explorable view of the data structure. This allows you to drill down into nested objects and inspect their properties in detail.

const book = {
  title: 'Structure and Interpretation of Computer Programs',
  authors: ['Harold Abelson', 'Gerald Jay Sussman'],
  publicationYear: 1984,
  metadata: {
    isbn: '978-0262510875',
    pages: 657
  }
};

console.log(book);

Logging the book object above in a browser’s developer console would yield a collapsible tree, allowing you to examine the authors array and the nested metadata object. Be aware, however, of a subtle but important implementation detail in some browsers: the console may display a live, mutable reference to the object. This means if the object is modified *after* the console.log call, expanding the object in the console later might show the modified state, not the state at the moment of logging. To capture a true snapshot, it is sometimes necessary to log a deep copy of the object, for instance by using JSON.parse(JSON.stringify(object)).

Employing console.log is also the most direct way to trace the flow of execution through conditional logic and loops. By placing log statements at the entry and exit points of functions or within different branches of an if statement, you can build a precise narrative of what your code is doing.

function processItems(items) {
  console.log('Processing started for', items.length, 'items.');
  for (let i = 0; i < items.length; i++) {
    const item = items[i];
    console.log(--&gt; Analyzing item at index ${i}:, item); if (item.value > 10) { console.log(Item ${item.id} meets high value criteria.); // ... perform some action ... } else { console.log(Item ${item.id} does not meet criteria.); } } console.log('Processing complete.'); }

This pattern of instrumentation is not a crude hack; it is a legitimate and highly effective diagnostic technique. It requires no complex debugger setup and works consistently across different environments. Mastering the strategic placement of log statements is arguably one of the most critical skills for becoming a productive JavaScript programmer, as it provides direct, unambiguous feedback about the runtime behavior of your code. It transforms the black box of execution into a transparent process, allowing you to compare the actual behavior against your intended logic.

Prefer const for immutability by default

The introduction of ES2015 (often referred to as ES6) brought two new keywords for declaring variables, let and const, intended to supersede the problematic, function-scoped var. While both let and const are block-scoped and address the hoisting issues associated with var, they serve distinct purposes related to mutability. A disciplined approach to their use is a hallmark of robust code. The most effective strategy is to default to const for all variable declarations and only use let when reassignment is explicitly required.

The keyword const stands for “constant,” but its meaning is more nuanced than the name might suggest. It does not create an immutable value; rather, it creates an immutable *binding*. This means that once a variable is declared with const, its identifier cannot be reassigned to point to a different value. Attempting to do so will result in a TypeError.

const PI = 3.14159;
PI = 3; // Uncaught TypeError: Assignment to constant variable.

let counter = 0;
counter = 1; // This is perfectly valid.

This behavior is straightforward for primitive types like numbers, strings, and booleans. Where the distinction becomes critical is with objects and arrays. A common misconception is that declaring an object with const makes the object itself immutable. This is incorrect. The const declaration prevents the variable from being reassigned to a *new* object, but it does nothing to prevent the modification of the object’s internal state-its properties.

// 'user' is a constant reference to an object.
const user = {
  id: 101,
  name: 'Alex'
};

// Modifying a property of the constant-referenced object is allowed.
user.name = 'Alexandra'; // This works.

// Attempting to reassign the 'user' variable to a new object fails.
user = { id: 102, name: 'Bob' }; // Uncaught TypeError: Assignment to constant variable.

The same principle applies to arrays. You can freely modify the contents of an array declared with const, but you cannot assign a new array to the variable.

const permissions = ['read', 'write'];

permissions.push('execute'); // This is fine.
console.log(permissions); // Outputs: ['read', 'write', 'execute']

permissions.pop(); // Also fine.

permissions = ['admin']; // Uncaught TypeError: Assignment to constant variable.

Adopting a “const by default” policy yields significant benefits for code clarity and maintainability. When a developer encounters a variable declared with const, it serves as a clear signal that this identifier is not intended to be reassigned within its scope. This reduces the cognitive load required to track the state of variables, as you can be certain its reference will not change. Conversely, when you see a let, it acts as a flag, indicating that reassignment is expected and you should pay closer attention to how and where that variable’s value might be updated. This practice effectively minimizes the number of moving parts in your code, making it easier to reason about and less prone to bugs arising from accidental reassignments. The rule is simple: start with const. Only if you find a legitimate need to reassign the variable-such as in a loop counter or for a variable that tracks state that must be swapped out entirely-should you deliberately change the declaration to let. This makes mutability an explicit choice rather than an implicit default.

Recognize that scripts execute sequentially

A core characteristic of JavaScript’s execution model is that it is, by its fundamental nature, single-threaded and synchronous. This means that statements within a script are executed one at a time, in the order they appear in the source code. The JavaScript engine processes a script from top to bottom, and it will not move on to the next statement until the current one has completed its execution. This sequential, blocking behavior is a foundational concept that must be internalized to accurately predict program flow.

Consider the following trivial script. Its output is entirely predictable because each line is executed in sequence, and each subsequent line can rely on the state established by the ones preceding it.

let a = 10;
console.log('Initial value of a:', a);

let b = a * 2;
console.log('Value of b:', b);

a = a + 5;
console.log('Final value of a:', a);

The output will invariably be:

Initial value of a: 10
Value of b: 20
Final value of a: 15

This is because the engine first processes the declaration of a, then executes the first console.log, then calculates and assigns b, then executes the second console.log, and so on. There is no ambiguity; the flow is strictly linear.

This principle extends to function calls. When the JavaScript engine encounters a function invocation, it pauses the execution of the current context, creates a new execution context for that function, and pushes it onto the call stack. The engine then begins executing the code within that function. If that function calls another function, the process repeats: the current execution is paused, and a new context for the nested function is pushed onto the top of the stack. The engine always executes the context at the top of the call stack. When a function completes (i.e., hits a return statement or the end of its body), its execution context is popped off the stack, and control returns to the context below it, which resumes execution from where it left off. This Last-In, First-Out (LIFO) behavior of the call stack is central to how JavaScript manages program flow.

function first() {
  console.log('Entering first()');
  second();
  console.log('Exiting first()');
}

function second() {
  console.log('  Entering second()');
  third();
  console.log('  Exiting second()');
}

function third() {
  console.log('    Executing third()');
}

console.log('Script start');
first();
console.log('Script end');

The execution of this script follows the call stack precisely. The initial “Script start” is logged. Then first() is called and pushed onto the stack. It logs “Entering first()” and then calls second(). Execution in first() pauses, and second() is pushed onto the stack. It logs “Entering second()” and calls third(). Execution in second() pauses, and third() is pushed onto the stack. third() logs its message and then completes, so it is popped off the stack. Control returns to second(), which resumes and logs “Exiting second()”. It then completes and is popped off the stack. Control returns to first(), which logs “Exiting first()” and is popped off. Finally, the main script resumes, logs “Script end”, and the program finishes. The strictly sequential nature of this process is what guarantees a predictable output.

Understanding this single-threaded, synchronous model is critical because it reveals a potential bottleneck. If any statement or function call takes a significant amount of time to complete-a complex calculation, a synchronous network request, or a large file operation-it will block the entire execution thread. No other code can run until that long-running task is finished. In a browser environment, this is particularly detrimental, as the single thread is responsible for not only executing JavaScript but also for handling user interactions and rendering updates to the page. A blocked thread means a frozen user interface, leading to an unresponsive and frustrating user experience. It is this fundamental limitation that necessitates the asynchronous patterns (like callbacks, Promises, and async/await) that are pervasive in modern JavaScript, as they provide mechanisms to handle long-running operations without blocking the main execution thread. These patterns do not violate the sequential nature of the engine; rather, they are sophisticated conventions built on top of it, managed by the host environment’s event loop. Before one can effectively wield these asynchronous tools, however, one must first possess an unwavering grasp of the synchronous, one-thing-at-a-time reality of the underlying script execution.