Understanding JavaScript promises and callbacks

JavaScript often waits for work outside the current instruction: a server request, database query, file upload, or timer. Callbacks and promises describe what happens when that work finishes. A callback is a function passed to other code for later execution; a promise is an object representing a future outcome. Both support asynchronous programming, but they make control flow and error handling easier to read when used deliberately.

Australian products make the issue familiar. A transport app in Melbourne may check a Myki balance and train times while a shopper in Sydney completes a checkout; a customer in regional Queensland may use a slower connection. The interface should accept input while those operations run. Understanding the event loop also explains why a delayed response can appear after a newer interaction.

Why waiting needs a deliberate flow

JavaScript’s main thread runs one piece of code at a time. When code invokes a browser API for network data or schedules a timer, the host handles the operation and the thread remains free to process input and render the page. The result returns later through a callback or promise reaction. This non-blocking model lets a program wait for I/O without occupying the thread in a busy loop.

That distinction appears in a restrained, nature-inspired page such as the visual landing page, where typography, imagery, and spacing are arranged for quick scanning. Its font, photograph, and stylesheet may still arrive separately on a phone. A desktop preview can look complete while a mobile user sees a gap; asynchronous loading states acknowledge that delay without making every element unusable.

Callbacks and promises do not change the one-threaded model. They change the shape of the code around delayed work. A callback says, “run this function when the request ends”; a promise says, “here is a result that will settle, and attach handlers for its value or failure.” That difference becomes important when several operations must be coordinated.

Callbacks in an event-driven runtime

A callback function is an instruction passed along for later use. In a timer, setTimeout(() => updateClock(), 1000) registers work rather than returning the future clock value. The callback receives no useful result automatically; it must capture what it needs or receive it as an argument. Event listeners use the same idea, with a click handler running after the browser dispatches the event.

Callbacks suit one-to-one continuations and event-driven code. A subscription can expose onMessage, onOpen, and onError callbacks for distinct events. The difficulty grows when a request must authenticate, load a profile, and then calculate a delivery fee. Nesting each continuation inside the previous one creates deeply indented code, often called callback hell, where an early return or error is easy to miss.

Ordered work resembles an everyday reading routine. A guide to reading more books offers a non-code example of choosing manageable steps and following them in sequence. The parallel with software is not that a book triggers a network call; it is that unfinished steps benefit from a visible order, a clear owner, and a recovery path when one step does not complete.

Promises as a stateful result

A promise begins in a pending state. The function creating it receives resolve and reject, then uses them to settle it as fulfilled or rejected. Its value is delivered to handlers registered with then. A promise settles once, so later calls to resolve or reject cannot rewrite the outcome. That single, observable transition gives delayed work a more stable contract than a bare callback.

then is also a composition point. Returning a promise from a handler makes the next handler wait for that work; returning an ordinary value passes it forward. catch handles rejection, and finally performs cleanup after success or failure. These methods build a pipeline, but they do not make side effects inherently safe: a handler that sends a request still needs a policy for duplicate execution.

async functions and await resemble sequential code without removing the wait. An await pauses the current async function, not the whole browser thread. Resumed functions enter the microtask queue, which runs before the next timer or user event. This ordering explains a familiar surprise: promise continuations can run before a zero-delay callback, even when both were scheduled at nearly the same time.

Error propagation and cleanup

Callback APIs often use an error-first convention, such as callback(error, result), or depend on a thrown exception reaching a surrounding try block. Those patterns can work, but every callback must preserve the convention. With promises, a rejection travels down the chain until catch handles it. A throw inside a then handler creates a new rejection, allowing an error to be transformed, logged, or passed onward without losing its place in the flow.

Cleanup deserves the same attention as success. A cancelled request may leave a spinner, subscription, or temporary record behind if no finally block or cancellation signal exists. AbortController can signal that no result is needed, while Promise.allSettled reports every outcome in a batch instead of stopping at the first failure. These tools separate an operation that failed from one that was abandoned, which are different states in a user interface.

Good asynchronous code records enough context to diagnose a failure. An Australian checkout incident is easier to investigate when the request identifier, payment step, and elapsed time are attached without exposing sensitive card details. Conference and community material, such as SEIMC 2022 resources, can help teams compare implementation patterns and observability practices before adopting a convention. Consistent vocabulary makes errors actionable across services and time zones.

Choosing a style for the job

Neither callback functions nor promises are obsolete. A callback fits an API that reports one event, a stream subscription, or a hook that must run at a particular moment. A promise fits work that returns a value, may fail, or needs composition with other work. Modern libraries often expose both: an event mechanism may use callbacks underneath, while a wrapper returns a promise that callers can await.

The choice should follow the workflow. If three independent services must respond before a result is ready, Promise.all makes the shared completion condition clear. If the first response should determine the outcome, Promise.race expresses that rule; if the first successful response should win, Promise.any does. Promise.allSettled preserves every result for a dashboard. A callback chain can coordinate the same work, but its rules tend to hide in nesting and shared variables.

Local integrations provide useful examples. An ABN lookup, Australia Post delivery quote, or payment gateway can each be represented as a promise around an HTTP request. In a consumer app, a rejection should produce a message suited to the Australian market: a customer needs to know whether a fee is unavailable, a delivery date cannot be confirmed, or retrying is reasonable. The operation is asynchronous even when the interface feels immediate.

Building reliable Australian experiences

A reliable implementation separates waiting from deciding. Show a meaningful loading state, keep navigation available, and avoid updating the screen after a request has been cancelled or superseded. For a consumer-facing service, the Australian Consumer Law requires accurate representations and appropriate remedies when goods or services fail, so an error message should not imply that a failed authorisation completed an order. Clear status language supports compliance and everyday trust.

Personal information deserves equally careful treatment. If a form collects names, addresses, delivery details, or payment-related identifiers, teams should assess obligations under the Privacy Act 1988 and relevant Australian Privacy Principles, then minimise what is logged or retained. A generic promise rejection may be safe to display, while an upstream server error should not reveal internal endpoints. These choices matter on public transport in Sydney or Melbourne, where intermittent connections are ordinary.

Local gambling products offer another test of state and randomness. The journal’s pokies RTP simulator can exercise front-end code that models outcomes, updates totals, and explains results without suggesting that a random sequence is predictable. In Australia, pokies and online betting are shaped by different state and territory rules, so legal review matters before publishing a feature or promotion. A calculated return must never be presented as a guaranteed win.

Taken together, callbacks report events, promises expose future state, and the event loop determines when continuations run. When that model is respected, Australian products can remain responsive through busy shopping periods, slow regional connections, and compliance reviews without making asynchronous behaviour feel fragile.