JS Custom Actions: Functions vs Classes

For custom actions in JavaScript, use functions by default—they are simpler, more predictable, and cover the vast majority of cases. Classes are only worth choosing when you need to maintain state across multiple action invocations or want to bundle related actions with shared configuration. This article explains the trade-offs, shows concrete examples, and gives you a clear decision process.

Formula

The calculator above estimates the total time spent running a custom action multiple times. The formula is simply:

Total time = duration × number of invocations

Where:

• duration (t) is the time one action takes, in milliseconds.
• number of invocations (n) is how many times the action runs.
• Total time is the result, shown in milliseconds and minutes.

This is useful when you’re deciding whether a class-based action with setup overhead is worth it compared to a simple function that runs many times.

Worked Example

Using the default values: duration = 1000 ms, invocations = 10.

1. Total time = 1000 × 10 = 10,000 ms.
2. Convert to minutes: 10,000 / 60,000 = 0.17 minutes.

The calculator shows 10,000 ms and 0.17 min, matching the formula.

Background: Why This Question Comes Up

JavaScript offers multiple ways to define reusable logic: plain functions, arrow functions, classes, and factory functions. For custom actions—user-defined operations in a library, plugin, or framework—the choice matters because it affects readability, performance, and how the action integrates with the host system.

The confusion often comes from seeing examples of both styles in documentation. Some libraries show actions as simple functions, while others use classes with methods like execute() or run(). Beginners may wonder if classes are “more professional” or if functions are “too simple.”

How Functions Work for Custom Actions

A function action is just a callable that takes an input and returns an output. It can be synchronous or async, and it can be passed directly as a callback.

// Simple function action
const myAction = (context) => {
  return context.value * 2;
};

// Using it in a hypothetical framework
registerAction('double', myAction);

Functions are ideal when the action is stateless—each call is independent. They are also easy to test, compose, and replace. You can use arrow functions for brevity or regular functions if you need a dynamic this.

How Classes Fit In

A class action typically has a constructor that receives configuration, and one or more methods that perform the work. This is useful when the action needs to remember something between calls, like a counter, a cached result, or a connection.

class RetryAction {
  constructor(maxRetries) {
    this.maxRetries = maxRetries;
    this.attempts = 0;
  }

  run() {
    this.attempts++;
    if (this.attempts > this.maxRetries) {
      throw new Error('Max retries exceeded');
    }
    return `Attempt ${this.attempts}`;
  }
}

const retry = new RetryAction(3);
registerAction('retry', retry);

Classes also make it easy to group multiple related actions into one object—for example, a file handler with read, write, and delete methods. If your framework expects an object with a specific method signature, a class fits naturally.

How to Choose: A Practical Decision Tree

Ask yourself these questions in order:

1. Does the action need to remember state between calls? Yes → class. No → function.
2. Do you have multiple related actions that share configuration? Yes → class or a factory function that returns an object. No → function.
3. Will you need to subclass or extend the action? Yes → class. No → function.
4. Is the action a one-off callback? Yes → function.

If you’re still unsure, start with a function. You can always refactor to a class later without breaking the public API if you keep the same call signature.

Common Problems and Misconceptions

One common mistake is assuming classes are always faster. In modern JavaScript engines, the performance difference is negligible for most use cases. The real cost is in complexity: classes introduce this binding issues, especially when methods are passed as callbacks. You may need to bind or use arrow functions, which can confuse beginners.

Another misconception is that functions cannot hold state. They can—via closures:

function createCounter() {
  let count = 0;
  return () => ++count;
}
const counter = createCounter();
counter(); // 1
counter(); // 2

This is often simpler than a class for a single stateful action.

Comparing Functions and Classes

• Readability: Functions are shorter and more direct. Classes add structure that can be overkill.
• State: Classes make state explicit; closures hide it. Choose what your team finds clearer.
• Composition: Functions compose easily with higher-order functions. Classes require careful design to combine.
• Testing: Both are testable, but functions are trivial to mock and call directly.
• Framework expectations: Some frameworks require a specific shape. Check the docs first.

Costs and Performance Considerations

Creating a new class instance for every action invocation adds allocation overhead. If you’re running an action thousands of times per second, a plain function that avoids object creation may be slightly faster. However, the difference is usually micro-optimization. Measure with your own benchmarks before changing your design.

On the other hand, classes can reduce memory usage if you reuse a single instance across many calls, because you avoid re-creating closures. But again, the impact is rarely significant.

Alternatives to Both

Besides functions and classes, you can use:

• Factory functions: return an object with methods, without using new or this. They combine the clarity of classes with the simplicity of functions.
• Async functions: for actions that await promises, just mark the function async.
• Generators: if your action yields multiple values over time, a generator function may be more appropriate.

These are not replacements for every case, but they expand your toolkit.

Frequently Asked Questions

Can I use arrow functions as custom actions?

Yes, arrow functions work fine as long as you don’t need a dynamic this. They are shorter and often preferred for callbacks. Just remember they are not hoisted and cannot be used as constructors.

When should I avoid classes for actions?

Avoid classes when the action is stateless, when you don’t need inheritance, or when the framework you’re using expects a plain function. Classes add boilerplate and can make simple logic harder to read.

How do I handle asynchronous actions?

Make the function or method async and return a promise. Both functions and classes support this equally. The framework will likely await the returned promise.

Is there a performance penalty for classes?

In most real-world applications, no. Modern JavaScript engines optimize both patterns well. The main cost is the overhead of creating a new instance if you do it per call. Reuse a single instance if you’re concerned.

Can I mix functions and classes in the same project?

Absolutely. Use functions for simple, stateless actions and classes for complex, stateful ones. Consistency is good, but not at the expense of clarity.

What if my framework requires a specific signature?

Follow the framework’s documentation. Some frameworks expect a function, others an object with a method. If it’s flexible, use the simplest option that meets the requirement.

Related

• Noise Canceling vs Noise Isolating: Which Is Better?
• Why Avoid Phones with Razor-Thin Bezels?
• Linux Distros Beginners Should Avoid

in t | Action duration (ms) | ms | 1000 | 1 | 60000
in n | Number of invocations | - | 10 | 1 | 1000
out total | Total time (ms) | ms | t * n | 0
out minutes | Total time (min) | min | (t * n) / 60000 | 2