Most bugs I see around JavaScript functions aren’t about syntax—they’re about timing and scope. You wire up a callback, the app ships, and suddenly a handler throws because the function wasn’t available when you expected it to be. Or you build a little factory to keep state private, and now a refactor breaks because the function name you used in a stack trace no longer exists. These are the kinds of problems that push you to understand function expressions at a deeper level.
Function expressions are the workhorses of modern JavaScript. They’re the small, flexible units you can pass around, store, and invoke when you decide—not when the engine decides. When I’m building UI behavior, worker pipelines, or small event-driven utilities, I reach for function expressions first because they make control flow explicit.
In the sections that follow, I’ll walk through what function expressions are, how they behave with hoisting, why named expressions matter, and where they shine in real systems. I’ll also call out the traps I still see in production code, plus the patterns I recommend in 2026 when you’re working alongside TypeScript and AI-assisted tooling.
What a Function Expression Really Is
A function expression is a function created as part of an expression. In practice, that means you assign it to a variable, pass it directly to another function, or wrap it so it runs immediately. The key idea is that the function is treated like a value. This makes it easy to store, reuse, and hand off.
The most common pattern looks like this:
const greet = function(name) {
return Hello, ${name}!;
};
console.log(greet("Steven"));
In that snippet, the function is anonymous and assigned to greet. The variable is what you call; the function itself is just a value stored in that variable. The same function could be stored in an object, returned from another function, or used only once.
I like to think of function expressions as “on-demand tools.” You define them where you need them, and they come to life when you invoke them. That mental model also explains why they are so common in callbacks, closures, and small behavior blocks inside larger systems.
Basic Syntax Pattern
const fName = function(params) {
// function body
};
fNameholds the function value.function(params)defines the function, with optional parameters.- The block contains the logic that runs when you call
fName().
If you’ve worked mostly with function declarations in the past, this is the main shift: the declaration becomes a value rather than a standalone statement.
Hoisting and Timing: Why Order Matters
Function expressions are not hoisted the way function declarations are. That statement is simple, but there’s nuance that matters in real codebases.
A function declaration is fully hoisted, so you can call it before its definition. A function expression is different because the variable exists before the function value is assigned. The timing depends on how you declare the variable:
console.log(runTask); // undefined
var runTask = function() {
return "Task ran";
};
console.log(runTask()); // "Task ran"
With var, the variable is hoisted and initialized to undefined, so calling it before assignment throws a TypeError because undefined isn’t callable. With let or const, the variable exists in the temporal dead zone, so accessing it before assignment throws a ReferenceError.
console.log(startServer); // ReferenceError
const startServer = function() {
return "Server started";
};
This is why I put function expressions near the point of use. It reduces the risk of accidental early calls and makes module boundaries clear. When I see an expression defined at the bottom of a file and called at the top, it’s a red flag: someone expects declaration-style behavior and will eventually get burned.
If you need call-before-definition behavior, use a function declaration. If you want explicit control of when a function becomes available, use an expression. In practice, I use declarations for module-level utilities and expressions for behavior that should exist only within a limited scope.
The “Initializing Variable” Trap
A sneaky bug shows up when developers see a variable name and assume it always holds a function. Consider:
let onReady;
if (config.enabled) {
onReady = function() {
console.log("Feature enabled");
};
}
onReady(); // TypeError if config.enabled is false
This is not a hoisting problem—it’s a control flow problem. The variable exists, but nothing guarantees it holds a function. I fix this by defaulting it to a no-op or by guarding the call:
const onReady = config.enabled
? function onReady() { console.log("Feature enabled"); }
: function onReady() {};
onReady();
or
if (typeof onReady === "function") onReady();
Named vs Anonymous Expressions: Debugging and Recursion
Function expressions can be anonymous or named. The name choice affects recursion and debugging, so I treat it as a design decision rather than a cosmetic one.
Anonymous expression:
const sum = function(a, b) {
return a + b;
};
console.log(sum(5, 3));
Named expression:
const factorial = function fact(n) {
if (n === 0) return 1;
return n * fact(n - 1);
};
console.log(factorial(5));
A named expression gives you a stable internal reference for recursion. It also shows up in stack traces, which is invaluable when you’re debugging asynchronous flows. I recommend named expressions for anything non-trivial, especially if the function will call itself or be part of a complex call chain.
One subtle detail: the name you give to a function expression is scoped to the function body itself. That means fact in the example above isn’t in the outer scope. If you try to call fact(3) outside, it fails. That’s usually what you want: you get recursion inside, without polluting the outer scope.
In practice, I use anonymous expressions for short handlers that are unlikely to appear in logs. For anything more than a few lines or any function that might throw, I use named expressions for cleaner traces.
Debugging and Stack Trace Clarity
If you’ve ever stared at a stack trace that says at , you already understand why names matter. When async errors bubble, the call chain is often long and cross-cutting. A name like parseInvoice or retryWithBackoff is a breadcrumb you can follow. It also helps when you pipe logs into a monitoring system and rely on function names for grouping.
Where Function Expressions Shine in Real Systems
I see function expressions in four recurring roles: callbacks, event handlers, factories that create closures, and one-off initialization blocks.
1) Callbacks and async flows
Callbacks are the most common home for function expressions. They allow you to define behavior exactly where it will run.
setTimeout(function delayNotice() {
console.log("This message appears after 3 seconds.");
}, 3000);
When I read that snippet, I immediately know the behavior is local to that timer. It doesn’t need a global function name, and it doesn’t need to exist anywhere else.
A slightly more realistic async example:
const fetchWithTimeout = function fetchWithTimeout(url, ms) {
return new Promise(function executor(resolve, reject) {
const controller = new AbortController();
const timer = setTimeout(function onTimeout() {
controller.abort();
reject(new Error("Request timed out"));
}, ms);
fetch(url, { signal: controller.signal })
.then(function onResponse(res) {
clearTimeout(timer);
resolve(res);
})
.catch(function onError(err) {
clearTimeout(timer);
reject(err);
});
});
};
Each function expression is scoped to the promise executor. That keeps everything localized and avoids polluting the module scope.
2) Event handlers
UI code often uses function expressions directly in event listeners. I like this when the logic is short and local to the element.
document.querySelector("button").addEventListener("click", function onClick() {
console.log("Button clicked!");
});
If the handler grows, I extract it, but I still keep it as a function expression because it keeps the scoping tight.
A pattern I like for larger handlers is to keep the handler as an expression but extract helpers inside:
const handleSubmit = function handleSubmit(event) {
event.preventDefault();
const data = readForm(event.target);
validate(data);
submit(data);
};
form.addEventListener("submit", handleSubmit);
This strikes a balance: the handler is still a value, but it’s readable and testable.
3) Closures and factories
Function expressions are a natural fit for closures because you can create stateful behavior without exposing internal variables.
const createCounter = function() {
let count = 0;
return function increment() {
count += 1;
return count;
};
};
const visits = createCounter();
console.log(visits()); // 1
console.log(visits()); // 2
This pattern gives you encapsulation without a class. I still use it for lightweight state machines or per-request counters in server code.
A more applied example is a debounce factory:
const createDebounce = function createDebounce(ms) {
let timer = null;
return function debounce(fn) {
return function debounced(...args) {
if (timer) clearTimeout(timer);
timer = setTimeout(function run() {
fn(...args);
}, ms);
};
};
};
const debounce = createDebounce(250);
const onInput = debounce(function onInput(value) {
console.log("Search:", value);
});
Each returned function expression closes over timer, giving you per-instance behavior without a class or external state.
4) Immediately invoked function expressions
IIFEs are less common today, but they’re still useful when you need to isolate scope in scripts.
(function initApp() {
const env = "production";
console.log(Booting in ${env});
})();
In 2026, modules and block scope reduce the need for IIFEs, but in mixed environments or legacy scripts, I still reach for them.
Arrow Functions: A Variant with Sharp Edges
Arrow functions are still function expressions, just with a different syntax and a different this behavior. They are excellent for short callbacks, but I avoid them when I need dynamic this or when I want a named function in stack traces.
const total = (items) => items.reduce((sum, price) => sum + price, 0);
If the function is a method that relies on this, an arrow function can be a trap because arrows capture this from the surrounding scope. In UI frameworks, that’s often a benefit, but in plain objects it can cause confusing bugs.
const cart = {
items: [12, 9, 20],
total: function calculateTotal() {
return this.items.reduce((sum, price) => sum + price, 0);
}
};
console.log(cart.total());
If total were an arrow, this.items would be undefined in many contexts. I recommend regular function expressions for methods and arrows for short callbacks or inline transformations.
Traditional vs Modern callbacks
When I compare older callback patterns to today’s style, I use a quick table so you can see the intent difference at a glance:
Modern Method
—
setTimeout(function() { console.log("Saved"); }, 200); setTimeout(() => console.log("Saved"), 200);
items.map(function(item) { return item.id; }); items.map(item => item.id);
api.fetch(function(response) { return response.json(); }); api.fetch(response => response.json());Both are function expressions, but the modern style trades verbosity for clarity. I still fall back to the traditional form when the body needs multiple lines or I want a named function for debugging.
Function Expression vs Declaration: Practical Guidance
Developers often ask me which style to choose. I don’t treat this as a theoretical debate; I look at where the function lives and how it is used.
Here’s the comparison I give when I want someone to make a clear decision:
Modern (Expression-centric)
—
Available only after the assignment runs
Strong for local behavior and callbacks
Named only if you choose to name it
Can be scoped narrowly inside blocks
Readable when behavior is tied to a specific lineIf you’re building a module with exported helpers, declarations make the file feel like a list of capabilities. If you’re coding event-driven behavior or closures, expressions keep the footprint smaller and your intent clearer.
When I’m mentoring teams, I set a rule of thumb: use declarations at module boundaries, expressions inside modules. That gives you a consistent map of the public surface while still keeping local behavior contained.
Common Mistakes I Still See in Production
Even experienced teams fall into a few recurring traps. Here’s what I watch for during reviews.
Mistake 1: Expecting declaration-style hoisting
I often see code like this in rushed refactors:
processRequest();
const processRequest = function() {
// ...
};
That fails because the function doesn’t exist yet. Fix it by moving the call below the definition or switching to a declaration when call-before-definition is intentional.
Mistake 2: Forgetting the function name in recursive expressions
When you rely on recursion, an anonymous function expression leaves you without a stable internal reference. The fix is easy: name the function.
const walkTree = function walk(node) {
if (!node) return 0;
return 1 + walk(node.left) + walk(node.right);
};
Mistake 3: Overusing inline expressions in large handlers
Long inline expressions inside event listeners or promises can hide complexity and make testing harder. If the handler exceeds about 10–15 lines, I extract it into a named expression and then pass the variable. You still get expression behavior, but you regain readability.
Mistake 4: Misusing arrow functions with this
This shows up in classes and objects that need dynamic context. If you expect this to be set at call time, use a regular function expression. If you want this captured from outside, use an arrow. I encourage teams to standardize this to reduce surprises.
Mistake 5: Using the Function constructor for dynamic creation
Yes, you can build functions from strings, but it breaks tooling, blocks static analysis, and can introduce security holes. In 2026, I only allow this in tightly controlled plugin systems, and even then with strict input validation and isolated execution contexts.
Performance and Memory Considerations
Function expressions are cheap, but they aren’t free. The main cost is allocation and closure retention. In a tight loop, creating a new function per iteration can add overhead and keep data alive longer than expected.
For example, creating thousands of new functions per second in a UI animation loop can add latency that users notice. I’ve seen loops add 5–12ms of overhead on mid-range hardware when function creation is unnecessary. The fix is usually to hoist the function expression outside the loop so it’s created once, then reused.
Closures also keep references alive. When you close over large objects, they stay in memory as long as the function does. I recommend keeping closures small and passing only the data you need. In Node services, this can prevent incremental memory growth that shows up as GC spikes in the 20–40ms range.
The key is not to fear function expressions, but to use them intentionally. When you keep them scoped and avoid excessive creation, they remain fast and predictable.
When I Avoid Function Expressions
Even though I rely on them heavily, there are cases where I avoid function expressions and use declarations or classes instead.
- Public APIs: For exported module functions, declarations provide a clear list of available capabilities.
- Large multi-step logic: A declaration with a descriptive name makes code easier to scan in long files.
- Libraries with strict tree-shaking: Named declarations can be easier for tooling to analyze, though modern bundlers handle expressions well too.
- Teaching code: When I’m writing examples for beginners, declarations reduce the timing issues that distract from the core idea.
If you find yourself naming everything and placing it at module scope, a declaration might be a better fit. If the function exists only to serve a small local purpose, a function expression keeps it out of the global noise.
Modern Workflow Notes for 2026
In 2026, most teams use TypeScript, linting, and AI-assisted code review. These tools shape how I write function expressions.
- Type inference: When you assign a function to a
const, TypeScript infers the type from the function signature, which makes expressions feel natural. I recommend explicit types only when the function is part of a public API. - AI hints: AI assistants often suggest inline expressions for quick fixes. I accept them for short handlers, but I still extract and name functions when logic grows.
- Lint rules: Many teams enforce
func-namesorprefer-arrow-callback. I tune those rules instead of disabling them. Named expressions improve debugging, and I allow regular functions whenthisis important.
Function Expressions in Modules and Exports
A practical question I get often is: can I still use function expressions for exports? Yes—and in many cases it’s clean and readable.
const calculateTax = function calculateTax(amount, rate) {
return amount * rate;
};
export { calculateTax };
That gives you a named function for debugging plus an explicit export. If you prefer default exports, you can still keep the name:
const formatInvoice = function formatInvoice(invoice) {
return ${invoice.id}:${invoice.total};
};
export default formatInvoice;
This is a nice compromise: local clarity and clean export surfaces.
Scoping and Block-Level Expressions
Another strength of function expressions is how easily they fit inside block scope. When you need a helper only inside a conditional branch or loop, an expression keeps it contained.
if (featureFlags.experimentA) {
const buildPayload = function buildPayload(data) {
return { ...data, variant: "A" };
};
send(buildPayload(input));
}
With a declaration, buildPayload would leak into the outer scope. With an expression, it stays where it belongs.
Edge Cases: Parameters, Defaults, and Rest
Function expressions handle default parameters and rest parameters just like declarations, but there are a few readability tips I follow.
const formatUser = function formatUser(name, role = "member", ...tags) {
return ${name} (${role}) [${tags.join(", ")}];
};
When defaults or rest are involved, I avoid anonymous expressions so stack traces stay readable. It’s a minor choice, but in messy production bugs, it’s one less mystery.
The “Arguments” Object Surprise
Regular function expressions have an arguments object; arrow functions do not. If you rely on arguments, avoid arrows.
const sumAll = function sumAll() {
let total = 0;
for (let i = 0; i < arguments.length; i += 1) {
total += arguments[i];
}
return total;
};
If you prefer modern syntax, just use rest parameters:
const sumAll = function sumAll(...nums) {
return nums.reduce((a, b) => a + b, 0);
};
Function Expressions in Object Literals
Function expressions are still the most explicit way to put behavior on objects when you need this.
const logger = {
prefix: "[app]",
log: function log(message) {
console.log(${this.prefix} ${message});
}
};
In 2026, shorthand method syntax is common, but I still use expressions when I want a named function for debugging:
const logger = {
prefix: "[app]",
log: function log(message) {
console.log(${this.prefix} ${message});
}
};
If you use shorthand, the function name might still appear, but it’s less explicit and can vary between tools. For production logs, I prefer explicit names.
Function Expressions and Recursion Beyond Basics
We already covered the basic recursion pattern, but there’s a deeper reason to use named expressions here: it protects your function from being reassigned externally.
const fibonacci = function fib(n) {
if (n <= 1) return n;
return fib(n - 1) + fib(n - 2);
};
const original = fibonacci;
fibonacci = function() { return 0; };
console.log(original(5)); // still works because fib is internal
The internal name fib continues to point to the original function body, even if the variable fibonacci is reassigned. That’s a subtle but useful property in larger systems.
Function Expressions in Async/Await Pipelines
I see a lot of use cases where a function expression becomes a small building block inside async flows. This keeps code readable and keeps each piece in scope.
const loadUser = function loadUser(id) {
return fetch(/api/users/${id}).then(function onRes(r) { return r.json(); });
};
const enrichUser = function enrichUser(user) {
return { ...user, displayName: ${user.first} ${user.last} };
};
const getUserView = function getUserView(id) {
return loadUser(id).then(function onUser(user) {
return enrichUser(user);
});
};
You can also express this with async/await while keeping functions as expressions:
const getUserView = async function getUserView(id) {
const res = await fetch(/api/users/${id});
const user = await res.json();
return { ...user, displayName: ${user.first} ${user.last} };
};
Both approaches keep the function as a value, which matters when you pass it into other utilities or compose them.
Composition Patterns with Function Expressions
Function expressions shine in composition-heavy code. When you pass behavior as data, expressions are the cleanest way to do it.
Here’s a small middleware chain that uses expressions to keep behavior modular:
const withLogging = function withLogging(next) {
return function logged(request) {
console.log("Start", request.id);
const result = next(request);
console.log("End", request.id);
return result;
};
};
const withAuth = function withAuth(next) {
return function authorized(request) {
if (!request.user) throw new Error("Unauthorized");
return next(request);
};
};
const handleRequest = function handleRequest(request) {
return { ok: true, id: request.id };
};
const handler = withLogging(withAuth(handleRequest));
Each function expression is a composable unit. This is a core technique in functional-style JavaScript, and it scales well for pipelines or request processing.
Error Handling Patterns with Function Expressions
One reason I prefer expressions in error-prone areas is the clarity around which code handles which errors. A named expression for each stage makes logs more readable.
const parseConfig = function parseConfig(text) {
try {
return JSON.parse(text);
} catch (err) {
err.message = Invalid config: ${err.message};
throw err;
}
};
When that throws, you can see the function name in the stack. In event-driven systems, that clarity pays for itself quickly.
Practical Scenario: UI Component Behavior
Imagine a small UI component that needs to handle click, hover, and teardown. Function expressions keep the behavior local.
const createTooltip = function createTooltip(element) {
let visible = false;
const show = function show() {
if (visible) return;
visible = true;
element.classList.add("tooltip-visible");
};
const hide = function hide() {
if (!visible) return;
visible = false;
element.classList.remove("tooltip-visible");
};
const destroy = function destroy() {
element.removeEventListener("mouseenter", show);
element.removeEventListener("mouseleave", hide);
};
element.addEventListener("mouseenter", show);
element.addEventListener("mouseleave", hide);
return { destroy };
};
Everything is in one scope, names are explicit, and cleanup is easy. This is exactly the sort of structure where function expressions feel natural.
Practical Scenario: Data Processing Pipeline
Here’s a data processing example that mixes expressions and composition:
const normalize = function normalize(record) {
return { ...record, name: record.name.trim() };
};
const validate = function validate(record) {
if (!record.name) throw new Error("Missing name");
return record;
};
const transform = function transform(record) {
return { id: record.id, label: record.name.toUpperCase() };
};
const processRecord = function processRecord(record) {
return transform(validate(normalize(record)));
};
Each step is a named expression, making the pipeline easy to read and test. It’s a clean pattern for ETL-style tasks in Node or the browser.
Alternative Approaches and Tradeoffs
Function expressions are not the only way to express behavior. Here are a few alternatives and when I choose them.
1) Function Declarations
Best when you want hoisting or a clear list of helpers at module scope. I use them for exports and top-level utilities.
2) Classes and Methods
Classes are great when you need shared state across many methods or want to model a domain concept. I avoid them for small, single-purpose behavior because they add ceremony.
3) Object Literals with Methods
Good for grouping related behavior. If the object is just a namespace, I often prefer named expressions and explicit exports instead, because it keeps the module tree-shakeable.
4) Higher-Order Functions
These are built from function expressions. The tradeoff is readability: too many nested expressions can become hard to parse. I keep higher-order usage to one or two layers and extract to named expressions when logic grows.
Testing Function Expressions
Testing expressions is straightforward because they’re values. The main risk is not having a stable reference. I fix that by naming the variable and the function.
const calculateDiscount = function calculateDiscount(price, rate) {
return price - price * rate;
};
// In tests:
expect(calculateDiscount(100, 0.2)).toBe(80);
For inline expressions in callbacks, I usually extract if the logic is testable. If it’s a one-liner, I leave it inline.
Linting, Style, and Team Conventions
Consistency matters more than ideology. I recommend a style guide that answers these questions:
- When do we use named expressions versus anonymous?
- Do we prefer arrows for callbacks?
- Are methods allowed to be arrows?
- Where do we allow function declarations?
On most teams I work with, we use:
- Declarations for exported module functions
- Named expressions for anything non-trivial or error-prone
- Arrow functions for short callbacks or array transforms
- Regular functions for methods needing
this
This makes behavior predictable across the codebase.
Practical Pitfall: “Leaky” Closures
A function expression that closes over large data can keep that data alive longer than expected. Here’s a subtle example:
const createSearcher = function createSearcher(bigIndex) {
return function search(query) {
return bigIndex.find(query);
};
};
If bigIndex is huge and you keep the returned search around forever, that index can’t be garbage collected. Sometimes that’s intended, but often it isn’t. A fix is to pass in only what you need or release references when you’re done.
let index = buildIndex();
const search = createSearcher(index);
// later
index = null; // allow GC if nothing else references it
Practical Pitfall: Capturing a Loop Variable
Old-style var loops can surprise you if you capture the loop variable in a function expression.
const handlers = [];
for (var i = 0; i < 3; i += 1) {
handlers.push(function onClick() {
console.log(i); // always 3
});
}
Use let or an IIFE to capture the value per iteration:
const handlers = [];
for (let i = 0; i < 3; i += 1) {
handlers.push(function onClick() {
console.log(i); // 0, 1, 2
});
}
Function Expressions with Default Exported Values
If you’re exporting a function expression as default and want reliable stack traces, I recommend naming it explicitly:
const buildReport = function buildReport(data) {
return data.map(x => x.id);
};
export default buildReport;
This avoids the “anonymous” stack trace issue and keeps the function identity stable.
Production Considerations: Monitoring and Logging
Function names often appear in logs, especially when errors are captured by monitoring tools. Named expressions make those logs far more useful.
I’ve seen production incidents go from 90 minutes to 15 minutes just because stack traces were readable. That’s not a small gain. Naming a function costs you a few characters; debugging time is priceless.
Practical Heuristics I Use Daily
Here are the personal heuristics I use when deciding how to write a function:
- If it’s exported or public: declaration or named expression
- If it’s a callback longer than 3–5 lines: named expression
- If it needs
this: regular function expression - If it’s a one-liner transform: arrow function
- If it’s recursive: named expression
- If it’s only used once: inline expression
These rules aren’t sacred, but they keep my code consistent and predictable.
A Deeper Comparison Table: Expression vs Declaration vs Arrow
Here’s a more detailed comparison to help you make a quick call:
Function Declaration
Arrow Function Expression
—
—
Fully hoisted
Variable hoisted, value not
this binding Dynamic
Lexical
arguments object Yes
No
Yes
Often anonymous
Public APIs, utilities
Short callbacks, transforms
Strong
Weaker unless namedThis isn’t about right or wrong; it’s about matching the tool to the situation.
Function Expressions in TypeScript
TypeScript makes expressions even more attractive because inference is so strong. A function expression assigned to a const is often fully typed without explicit annotations.
const isValidUser = function isValidUser(user: { id: string, role: string }) {
return user.role === "admin" || user.role === "editor";
};
When the type gets complex, I sometimes annotate the variable instead of the function:
type Validator = (user: User) => boolean;
const isValidUser: Validator = function isValidUser(user) {
return user.role === "admin" || user.role === "editor";
};
This keeps the function signature clean while still enforcing the contract.
Advanced Pattern: Self-Defining Function Expressions
Sometimes I use a function expression that rewrites itself after the first call. This is rare but useful for one-time initialization.
let getConfig = function getConfig() {
const config = loadConfig();
getConfig = function getConfig() {
return config;
};
return config;
};
This pattern avoids repeated work without introducing extra caching layers. It should be used carefully, but it’s a real-world technique that belongs in your toolkit.
Advanced Pattern: Partial Application with Expressions
Function expressions are natural for creating partially applied helpers:
const multiply = function multiply(a) {
return function by(b) {
return a * b;
};
};
const double = multiply(2);
console.log(double(6)); // 12
This is more flexible than it looks. You can use it to build validators, formatters, and request builders.
Practical Scenario: Node Server Middleware
Here’s a small example showing how expressions create a clean middleware chain:
const withTiming = function withTiming(next) {
return function timed(req, res) {
const start = Date.now();
const result = next(req, res);
const elapsed = Date.now() - start;
console.log("Elapsed:", elapsed);
return result;
};
};
const withJson = function withJson(next) {
return function json(req, res) {
res.setHeader("Content-Type", "application/json");
return next(req, res);
};
};
const handler = function handler(req, res) {
res.end(JSON.stringify({ ok: true }));
};
const composed = withTiming(withJson(handler));
Everything is a function expression; each stage is clearly defined and easy to test.
Practical Scenario: Browser Storage Adapter
Function expressions work well when you want to inject dependencies for easier testing:
const createStorage = function createStorage(storage) {
return {
get: function get(key) {
return storage.getItem(key);
},
set: function set(key, value) {
storage.setItem(key, value);
}
};
};
const storage = createStorage(window.localStorage);
storage.set("theme", "dark");
If you replace storage with a mock in tests, everything still works.
Practical Scenario: Retry with Backoff
Here’s a more involved example that shows how named expressions make recursion and async logic readable:
const retryWithBackoff = function retryWithBackoff(fn, retries, delayMs) {
return function attempt(...args) {
return fn(...args).catch(function onError(err) {
if (retries <= 0) throw err;
return new Promise(function wait(resolve) {
setTimeout(function afterDelay() {
resolve();
}, delayMs);
}).then(function onWait() {
return retryWithBackoff(fn, retries - 1, delayMs * 2)(...args);
});
});
};
};
It’s not the simplest code, but every function is named, and each stage reads like a sentence. That’s the payoff of expressions done well.
The Human Factor: Readability and Maintainability
The biggest reason I favor function expressions is not technical—it’s cognitive. When a function is defined next to where it’s used, the reader doesn’t have to jump around the file. When it’s named, the intent is clear. When it’s scoped, the surface area is small.
These aren’t abstract goals; they translate into fewer bugs and faster onboarding. I’ve watched new engineers ramp in half the time when the codebase uses expressions consistently and names functions intentionally.
Summary: The Practical Mental Model
If you remember nothing else, remember this:
- A function expression is a value you control.
- It exists only after the assignment runs.
- It can be named for better recursion and debugging.
- It thrives in callbacks, closures, and localized behavior.
The moment you treat function expressions as values rather than declarations, the language becomes more predictable. You can see where behavior is defined, where it becomes available, and how it flows through your system.
In 2026, with TypeScript, linting, and AI-assisted tooling, function expressions are still the most flexible way to express local behavior. Use them intentionally, name them when they matter, and keep them close to where they’re used. That’s the difference between code that merely runs and code that scales with your team and your product.
Final Checklist (Quick Reference)
Here’s a practical checklist I keep in my head when I’m working:
- Use expressions for callbacks, event handlers, and closures
- Name expressions that are non-trivial or recursive
- Avoid calling expressions before assignment
- Use regular functions when you need dynamic
this - Prefer arrows for short, pure callbacks
- Extract large inline expressions for readability and tests
- Keep closures small to avoid memory retention
If you stick to that, function expressions will feel like a superpower rather than a source of subtle bugs.
