Functions That Remember: Rethinking Currying in JavaScript

At first glance, currying feels like an unnecessary complication.

You take a function that accepts multiple arguments…

and turn it into a chain of functions that take one argument at a time.

What used to look simple:

add(2, 3)

Becomes something that feels almost excessive:

add(2)(3)

So the reaction is natural:

Why make it harder than it needs to be?

But that question assumes something subtle—

that functions are only meant to run, not to evolve.

The Moment a Function Stops Being Static

In most code, a function is treated like a one-time action.

You give it everything it needs.

It gives you a result.

Done.

But not all information is available at the same time.

Sometimes:

• part of the context is known early
• the rest comes later

And that’s where currying quietly changes the model.

Instead of executing immediately, the function begins to wait.

It accepts one piece of information…

and returns a new function that remembers it.

A Function That Learns in Stages

Consider this shift:

const greet = (greeting) => (name) => `${greeting}, ${name}`

You’re no longer just calling a function.

You’re shaping it.

const sayHello = greet("Hello")

At this point, the function already knows something.

It doesn’t need to be told again.

When you later call:

sayHello("Rishi")

It completes the picture.

Not because everything was passed at once—

but because the function carried part of the context forward.

This Isn’t About Syntax

It’s tempting to think currying is just about splitting arguments.

But that misses what’s actually happening.

The real shift is this:

From:

A function that needs everything now

To:

A function that can be built over time

Each step:

• captures a piece of context
• returns a more specific function

Until eventually, nothing is missing.

Where It Starts to Feel Useful

This becomes more meaningful when repetition appears.

Take something like an API call.

Without much thought, you might write:

fetchData(baseUrl, endpoint, token)

Every call repeats:

• the same base URL
• the same token

With currying, that repetition disappears—not by removing it, but by relocating it.

const createFetcher = (baseUrl) => (token) => (endpoint) => { ... }

Now the function can be shaped step by step:

const api = createFetcher("https://api.com")
const authorizedApi = api(token)

At this point, the function already carries its environment.

Calling:

authorizedApi("users")

feels less like assembling inputs…

and more like using a tool that’s already been prepared.

But There’s a Cost

This is where the tension appears.

Currying improves structure—

but it doesn’t always improve readability.

A single line like:

createFetcher("api.com")(token)("users")

can feel harder to follow than its non-curried version.

Not because it’s wrong—

but because it introduces layers.

And layers demand attention.

Two Kinds of Readability

This is where things become clearer.

There isn’t just one kind of readability.

There’s:

Local readability

How easy a line is to understand in isolation

And:

Structural readability

How easy a system is to extend, reuse, and evolve

Currying often trades the first for the second.

It makes individual lines slightly harder to parse—

but makes the overall system more flexible.

When It Starts to Break Down

Currying becomes a problem when it’s used without purpose.

When there’s no real separation of concerns.

When everything is already known at once.

When functions are split simply because they can be.

Or when too many layers are introduced without meaning:

fn(a)(b)(c)(d)

At that point, the structure no longer clarifies.

It obscures.

The Role of Naming

There’s one detail that quietly determines whether currying feels elegant or confusing.

Naming.

Compare:

createFetcher("api.com")(token)("users")

With:

const api = createFetcher("api.com")
const authorizedApi = api(token)

authorizedApi("users")

The logic hasn’t changed.

But the second version gives each step a role.

It reduces the mental effort required to follow the flow.

Currying doesn’t stand on its own—

it depends on how you present it.

A More Balanced Approach

In practice, many developers don’t fully curry everything.

They stop halfway.

const createFetcher = (baseUrl, token) => (endpoint) => { ... }

This keeps:

• some structure
• less nesting

A compromise between flexibility and clarity.

And often, that balance is what makes code feel natural.

A Different Way to Think About It

Currying isn’t about breaking functions apart.

It’s about deferring decisions.

Instead of asking for everything upfront…

it allows information to arrive when it’s available.

A function doesn’t just execute.

It accumulates context.

A Final Thought

At the surface, currying looks like extra layers.

But underneath, it’s about something more subtle.

Not how functions run—

but how they adapt.

Because sometimes, the most useful function isn’t the one that does everything immediately.

It’s the one that can wait…

remember…

and become exactly what you need, step by step.