# Stop Using Function Parameters Now

Published 2022-04-28 · https://www.justjeb.com/post/stop-using-function-parameters-now

Why you shouldn't be using function parameters in JavaScript and what the alternative is.

Functions in JavaScript can be many things, but first and foremost it’s a contract. When we define a function we essentially define a contract between a caller and the implementor.

The contract says “given parameters X, Y, Z” you’ll get a result “R”.

**The thing is, contracts tend to change over time (and boy, do they).**

## The Problem

Let’s take a look at a very simple example:

```ts
// Receives a name and returns a greeting message
// TypeScript
function greet(name: string): string {
  return `Hello, ${name}`; 
}

// JavaScript
function greet(name) {
  return `Hello, ${name}`; 
}
```

The contract is simple — provided a name, the function will return a greeting message. A name is all we’ve got and all we need at the moment.

In a few months though, when the function is already used all over the code base, we find ourselves in a need of adding a last name to the greeting message.

We could, of course, just use the name parameter for the last name as well, but since we’re deeply aware of the differences between [Internationalization and Localization](https://www.w3.org/International/questions/qa-i18n) we know that in some countries the last name can come first. We want our product to be the best fit for our users around the globe, so we want to support this use case.

Since the function is already used in many places across the code base we want to make sure it’s backwards compatible.

Let’s do this, again, in a very naive way:

```ts
// TypeScript
function greet(firstName: string, lastName?: string, lastNameFirst: boolean = false): string {
  if (!lastName) {
    return `Hello, ${firstName}`;
  }
  return `Hello, ${lastNameFirst ? lastName + ' ' + firstName : firstName + ' ' + lastName}`;
}

// JavaScript
function greet(firstName, lastName, lastNameFirst = false) {
  if (!lastName) {
    return `Hello, ${firstName}`;
  }
  return `Hello, ${lastNameFirst ? lastName + ' ' + firstName : firstName + ' ' + lastName}`;
}
```

Thus, for the backwards compatibility, if the function isn’t provided with the last name it will just greet the old way, but if it is, it will look at the ordering and greet accordingly.

So far so good, let’s take a look at all the possible usages of this function:

```ts
// First name only - the old way
greet('John');
// First name and last name
greet('John', 'Doe');
// First name and last name but last name first :D 
greet('John', 'Doe', true);
```

There is one slight problem you can notice here and it is the readability. For example, we can guess by the usage that the first parameter is the name and the second is the last name. However, without knowing the implementation we can’t say or possibly know what the `true` stands for.

Not the biggest problem we have though, at the end of the day we have autocompletion and signature description in almost any IDE.

Let’s give it a few more months to spread across the code base and then realize that there is also a name prefix and (hell, why not!) a middle name.

And the ordering… oh boy, we better not talk about the implementation.

Anyways, back to the signature. We want to support name prefixes (**Mr.**, **Mrs.**, **Ms.** etc.) and middle names. The signature should be changed again, and once again it should be backwards compatible:

```ts
// TypeScript
function greet(
  firstName: string,
  lastName?: string,
  lastNameFirst: boolean = false,
  middleName?: string,
  prefix?: string,
): string {
  let greeting: string = '';
  // some implementation
  return greeting;
}

// JavaScript
function greet(firstName, lastName, lastNameFirst = false, middleName, prefix) {
  let greeting = '';
  // some implementation
  return greeting;
}
```

It is backwards compatible, meaning the invocations we saw previously would still work without issues:

```ts
// First name only - the old way
greet('John');
// First name and last name
greet('John', 'Doe');
// First name and last name but last name first :D 
greet('John', 'Doe', true);
```

But what if we try to use the new API in all these use cases? Since you can’t just pass an argument without passing all the previous arguments it would look like that:

```ts
// Name with prefix
greet('John', undefined, false, undefined, 'Mr.');
// Name and last name with prefix
greet('John', 'Doe', false, undefined, 'Mr.');
// Name and last name with prefix but last name first
greet('John', 'Doe', true, undefined, 'Mr.');
// Finally a name, a last name, a middle name and a prefix
greet('John', 'Doe', false, 'Christopher', 'Mr.');
```

If you use TypeScript then it’s ugly but relatively safe. If you use plain JavaScript it’s ugly and unsafe, since the chance of passing a wrong argument in a wrong place is increasing with every new parameter added to the function signature.

## The Solution

All this could have been easily avoided if we used a single object as a function parameter and seized the great power of [object destructuring](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#object_destructuring).

Let’s reiterate on our example.

A function that receives a name and returns a greeting message:

```ts
// TypeScript
interface GreetingParams {
  name: string;
}

function greet({ name }: GreetingParams) {
  return `Hello, ${name}`;
}

// JavaScript
function greet({ name }) {
  return `Hello, ${name}`;
}

// Invocation
greet({ name: 'John' });
```

Backwards compatible function that works with name and last name for all countries:

```ts
// TypeScript
interface GreetingParams {
  name?: string; // keep this for backward compatibility
  firstName?: string; // replaces name
  lastName?: string;
  lastNameFirst?: boolean;
}

function greet({
  name,
  firstName = name, // if firstName not provided, use name as firstName
  lastName,
  lastNameFirst = false,
}: GreetingParams) {
  if (!lastName) {
    return `Hello, ${firstName}`;
  }
  return `Hello, ${lastNameFirst ? lastName + ' ' + firstName : firstName + ' ' + lastName}`;
}

// JavaScript
function greet({
  name,
  firstName = name, // if firstName not provided, use name as firstName
  lastName,
  lastNameFirst = false,
}) {
  if (!lastName) {
    return `Hello, ${firstName}`;
  }
  return `Hello, ${lastNameFirst ? lastName + ' ' + firstName : firstName + ' ' + lastName}`;
}

// Backward compatible with old signature
greet({ name: 'John' });
// New signature with first name only
greet({ firstName: 'John' });
// New signature with first name and last name
greet({ firstName: 'John', lastName: 'Doe' });
// New signature with first name and last name, last name first
greet({ firstName: 'John', lastName: 'Doe', lastNameFirst: true });
```

Backwards compatible function that works with name, last name, middle name and prefix:

```ts
// TypeScript
interface GreetingParams {
  name?: string; // keep this for backward compatibility
  firstName?: string; // replaces name
  lastName?: string;
  lastNameFirst?: boolean;
  middleName?: string;
  prefix?: string;
}

function greet({
  name,
  firstName = name, // if firstName not provided, use name as firstName
  lastName,
  lastNameFirst = false,
  middleName,
  prefix,
}: GreetingParams) {
  let greeting: string = '';
  // Some implementation
  return greeting;
}

// JavaScript
function greet({
  name,
  firstName = name, // if firstName not provided, use name as firstName
  lastName,
  lastNameFirst = false,
  middleName,
  prefix,
}) {
  let greeting = '';
  // Some implementation
  return greeting;
}

// Backward compatible with old signature and prefix
greet({ name: 'John', prefix: 'Mr.' });
// New signature with first name and prefix
greet({ firstName: 'John', prefix: 'Mr.' });
// New signature with first name, last name and prefix
greet({ firstName: 'John', lastName: 'Doe', prefix: 'Mr.' });
// New signature with first name, last name, middle name and prefix
greet({ firstName: 'John', lastName: 'Doe', middleName: 'Christopher', prefix: 'Mr.' });
```

Ain’t that great?!

## Wait, but what about the disadvantages?

##### Flexibility

The destructuring approach is flexible and sometimes it’s too flexible.

For instance, in our example `lastNameFirst` doesn’t make any sense without `lastName` and while with ordered parameters approach it actually cannot be passed without `lastName` being passed, with destructuring approach you can pass it even if `lastName` isn’t passed. While it doesn’t pose any problem with the current implementation, it could be problematic in some cases.

Arguably though, the problem is not with the approach itself but with the definition of contract. When we define an interface like in the example, we declare that any parameter can be passed optionally. If we want to create a bond between two parameters we should reflect this bond in the contract, for example like this (or in any one of dozens of ways it can be solved):

```ts
interface GreetingParams {
  name?: string; // keep this for backward compatibility
  firstName?: string; // replaces name
  lastName?: {
    value: string;
    shouldComeFirst?: boolean;
  };
  middleName?: string;
  prefix?: string;
}
```

##### Rest parameters

Although this is a very specific use case it’s worth mentioning.

> The [**rest parameter**](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/rest_parameters) syntax allows a function to accept an indefinite number of arguments as an array, providing a way to represent [variadic functions](https://en.wikipedia.org/wiki/Variadic_function) in JavaScript.

For example `sum(...numbersToSum)`. This can’t be done with the object destructuring pattern.

Other than that I can’t think of examples where the ordered approach would beat the destructuring approach.

## Performance

Many will argue that if we pass the parameters as an object then the creation of this object every time we invoke the function would negatively impact the performance of the app.

First, let’s admit something — for 99% of JavaScript applications out there it’s simply irrelevant; unless it is a very specific use case when a single function is invoked thousands/millions of times you won’t feel the difference.

Next, let’s actually run some benchmark and see how big the difference is (if at all).

I used [PerfLink](https://perf.link/) JS playground to run and compare invocations of ordered parameters vs named parameters in a loop and here are the results:

- [**10000** invocations](https://perf.link/#eyJpZCI6Imwwcmo3ejdzOHllIiwidGl0bGUiOiJJbnZva2luZyBmdW5jdGlvbiB3ICYgdy9vIG9iamVjdCBjcmVhdGlvbiAxMDAwMDAiLCJiZWZvcmUiOiJjb25zdCBzaXplID0gMTAwMDA7XG5cbmNvbnN0IG5hbWVzID0gbmV3IEFycmF5KHNpemUpLmZpbGwoMCkubWFwKChfLCBpbmRleCkgPT4gYG5hbWUke2luZGV4fWApO1xuXG5jb25zdCBzdXJuYW1lcyA9IG5ldyBBcnJheShzaXplKS5maWxsKDApLm1hcCgoXywgaW5kZXgpID0%2BIGBzdXJuYW1lJHtpbmRleH1gKTsiLCJ0ZXN0cyI6W3sibmFtZSI6Ik9yZGVyZWQgcGFyYW1ldGVycyIsImNvZGUiOiJmdW5jdGlvbiBncmVldChuYW1lLCBzdXJuYW1lKSB7XG4gIHJldHVybiBgJHtuYW1lfSAke3N1cm5hbWV9YFxufVxuXG5cbmZvcihsZXQgaSA9IDA7IGkgPCBzaXplOyBpKyspe1xuICBncmVldChuYW1lc1tpXSwgc3VybmFtZXNbaV0pO1xufSIsInJ1bnMiOlsxMjAwLDE3MDAsMTgwMCwxNTAwLDE2MDAsMTkwMCwyMDAwLDE3MDAsMTcwMCwxNzAwLDE5MDAsMTcwMCwxNjAwLDE3MDAsMTkwMCwyMDAwLDIxMDAsMjEwMCwxNzAwLDIwMDAsMTkwMCwxNzAwLDE3MDAsMTgwMCwxNDAwLDE2MDAsMTQwMCwxNzAwLDE5MDAsMjAwMCwyMDAwLDEzMDAsMTUwMCwxNDAwLDEzMDAsMTAwMCwxNjAwLDE1MDAsMTgwMCwxOTAwLDE4MDAsMTYwMCwxNjAwLDIwMDAsMTkwMCwxOTAwLDE4MDAsMTgwMCwxODAwLDIwMDAsMjIwMCwxOTAwLDE5MDAsMTcwMCwxOTAwLDIwMDAsMTkwMCwxNzAwLDE5MDAsMTUwMCwxOTAwLDIyMDAsMjAwMCwxOTAwLDE0MDAsMTkwMCwyMjAwLDE5MDAsMTcwMCwxNjAwLDE1MDAsMTQwMCwxNzAwLDE1MDAsMTQwMCwxMzAwLDE0MDAsMTMwMCwxNzAwLDE2MDAsMTUwMCwxNTAwLDE3MDAsMjEwMCwxOTAwLDE3MDAsMTIwMCw0MDAsNTAwLDE0MDAsMTMwMCwxNzAwLDE2MDAsMTYwMCwxODAwLDIwMDAsMjAwMCwxODAwLDE5MDAsMjAwMF0sIm9wcyI6MTY5OH0seyJuYW1lIjoiTmFtZWQgcGFyYW1ldGVycyIsImNvZGUiOiJmdW5jdGlvbiBncmVldCh7bmFtZSwgc3VybmFtZX0pIHtcbiAgcmV0dXJuIGAke25hbWV9ICR7c3VybmFtZX1gXG59XG5cbmZvcihsZXQgaSA9IDA7IGkgPCBzaXplOyBpKyspe1xuICBncmVldCh7bmFtZTogbmFtZXNbaV0sIHN1cm5hbWU6IHN1cm5hbWVzW2ldfSk7XG59IiwicnVucyI6WzgwMCwxMDAwLDEyMDAsMTIwMCwxNTAwLDE0MDAsMTUwMCwxNjAwLDE0MDAsMTcwMCwxNDAwLDE1MDAsMTMwMCwxNDAwLDE2MDAsMTcwMCwxNTAwLDE1MDAsMTUwMCwxNzAwLDE2MDAsMTUwMCwxNTAwLDExMDAsMTIwMCwxMDAwLDExMDAsMTIwMCwxNjAwLDE1MDAsMTQwMCw5MDAsMTAwMCwxMDAwLDEwMDAsMTAwMCwxMTAwLDEwMDAsMTQwMCwxNDAwLDE2MDAsMTQwMCwxMjAwLDE2MDAsMTUwMCwxNTAwLDEyMDAsMTQwMCwxNzAwLDE1MDAsMTYwMCwxNTAwLDE2MDAsMTUwMCwxNTAwLDE3MDAsMTYwMCwxNDAwLDEzMDAsMTEwMCwxODAwLDE2MDAsMTUwMCwxMzAwLDEwMDAsMTYwMCwxNTAwLDE1MDAsMTYwMCwxMTAwLDEzMDAsMTQwMCwxNDAwLDEyMDAsMTEwMCwxMjAwLDEzMDAsMTAwMCwxMzAwLDE0MDAsMTEwMCwxMzAwLDE0MDAsMTcwMCwxNjAwLDE2MDAsMTAwMCwyMDAsMjAwLDEyMDAsOTAwLDExMDAsMTIwMCwxMTAwLDE0MDAsMTcwMCwxNTAwLDE0MDAsMTQwMCwxNTAwXSwib3BzIjoxMzM5fV0sInVwZGF0ZWQiOiIyMDIyLTAzLTIwVDExOjI2OjQ4LjQ4M1oifQ%3D%3D) — **1698 ops/s** for ordered (no object) vs **1339 ops/s** for named (creating a new object on each invocation). That makes it **22%** difference.

- [**100000** invocations](https://perf.link/#eyJpZCI6ImhnMDhkd2Z0ZmY2IiwidGl0bGUiOiJJbnZva2luZyBmdW5jdGlvbiB3ICYgdy9vIG9iamVjdCBjcmVhdGlvbiAxMDAwMDAiLCJiZWZvcmUiOiJjb25zdCBzaXplID0gMTAwMDAwO1xuXG5jb25zdCBuYW1lcyA9IG5ldyBBcnJheShzaXplKS5maWxsKDApLm1hcCgoXywgaW5kZXgpID0%2BIGBuYW1lJHtpbmRleH1gKTtcblxuY29uc3Qgc3VybmFtZXMgPSBuZXcgQXJyYXkoc2l6ZSkuZmlsbCgwKS5tYXAoKF8sIGluZGV4KSA9PiBgc3VybmFtZSR7aW5kZXh9YCk7IiwidGVzdHMiOlt7Im5hbWUiOiJPcmRlcmVkIHBhcmFtZXRlcnMiLCJjb2RlIjoiZnVuY3Rpb24gZ3JlZXQobmFtZSwgc3VybmFtZSkge1xuICByZXR1cm4gYCR7bmFtZX0gJHtzdXJuYW1lfWBcbn1cblxuXG5mb3IobGV0IGkgPSAwOyBpIDwgc2l6ZTsgaSsrKXtcbiAgZ3JlZXQobmFtZXNbaV0sIHN1cm5hbWVzW2ldKTtcbn0iLCJydW5zIjpbMjQwLDI5NiwyOTYsMzMzLDM1MSwzMTQsMjc3LDIwMywxODUsMjc3LDI3NywyNzcsMjU5LDI3NywyNTksMjIyLDkyLDEyOSwyMjIsMjQwLDU1LDI5NiwyNTksMjk2LDI1OSwyNzcsMzE0LDI5NiwyNTksMjU5LDI0MCwyNTksMzE0LDI1OSwzMTQsMzE0LDI5NiwyMjIsMjU5LDIwMywyNzcsMjc3LDMxNCwzMTQsMzE0LDI3NywyMjIsMTI5LDI3NywyOTYsMjU5LDIwMywxNjYsMjc3LDMxNCwyNzcsMzE0LDMxNCwzMTQsMjk2LDMxNCwxMjksMjk2LDIyMiwyNDAsMzE0LDI3NywxNDgsNTUsMTExLDIyMiwyOTYsMjQwLDI3NywyOTYsMjAzLDI5NiwyNDAsMTQ4LDI5NiwzMTQsMjc3LDI5NiwyOTYsMTg1LDIwMywyNDAsMTg1LDI1OSwyNTksMjU5LDI1OSwyNTksMjk2LDI0MCwxNjYsMjk2LDU1LDI0MCwyOTZdLCJvcHMiOjI1Mn0seyJuYW1lIjoiTmFtZWQgcGFyYW1ldGVycyIsImNvZGUiOiJmdW5jdGlvbiBncmVldCh7bmFtZSwgc3VybmFtZX0pIHtcbiAgcmV0dXJuIGAke25hbWV9ICR7c3VybmFtZX1gXG59XG5cbmZvcihsZXQgaSA9IDA7IGkgPCBzaXplOyBpKyspe1xuICBncmVldCh7bmFtZTogbmFtZXNbaV0sIHN1cm5hbWU6IHN1cm5hbWVzW2ldfSk7XG59IiwicnVucyI6WzIyMiwyNzcsMjk2LDMzMywzMTQsMjk2LDE4NSwyOTYsMjU5LDI1OSwyNTksMjU5LDIyMiwyNzcsMjQwLDIyMiwzNywxMjksMjIyLDI0MCwyMDMsMjc3LDI0MCwyNzcsMjU5LDI5NiwyNzcsMjc3LDI1OSwxMjksMjU5LDI0MCwyOTYsMjIyLDI5NiwyOTYsMjQwLDE2NiwyNTksMTY2LDI1OSwyOTYsMzE0LDI5NiwyOTYsMjU5LDIyMiwxMTEsMTY2LDI1OSwxMjksMTg1LDE0OCwyNDAsMjQwLDI3NywyNzcsMjk2LDI5NiwyNzcsMjk2LDExMSwxNDgsMjQwLDI0MCwyNzcsMjc3LDIyMiwzNywxMTEsMjAzLDIwMywyMjIsNTUsMjIyLDI0MCwyNzcsMjQwLDIyMiwxNDgsMjk2LDI1OSwyNTksMjc3LDE4NSwxODUsMjIyLDE4NSwyNTksMjc3LDI1OSwyNzcsMjU5LDI1OSwyNDAsMTY2LDI5Niw5MiwyMDMsMjc3XSwib3BzIjoyMzN9XSwidXBkYXRlZCI6IjIwMjItMDMtMjBUMTA6NDM6NTguMDIxWiJ9) — **252 ops/s** for ordered vs **233 ops/s** for named which is **8%** difference

- [**1000000** invocations](https://perf.link/#eyJpZCI6InRkbHM5NmJ5MWtnIiwidGl0bGUiOiJJbnZva2luZyBmdW5jdGlvbiB3ICYgdy9vIG9iamVjdCBjcmVhdGlvbiAxMDAwMDAwIiwiYmVmb3JlIjoiY29uc3Qgc2l6ZSA9IDEwMDAwMDA7XG5cbmNvbnN0IG5hbWVzID0gbmV3IEFycmF5KHNpemUpLmZpbGwoMCkubWFwKChfLCBpbmRleCkgPT4gYG5hbWUke2luZGV4fWApO1xuXG5jb25zdCBzdXJuYW1lcyA9IG5ldyBBcnJheShzaXplKS5maWxsKDApLm1hcCgoXywgaW5kZXgpID0%2BIGBzdXJuYW1lJHtpbmRleH1gKTsiLCJ0ZXN0cyI6W3sibmFtZSI6Ik9yZGVyZWQgcGFyYW1ldGVycyIsImNvZGUiOiJmdW5jdGlvbiBncmVldChuYW1lLCBzdXJuYW1lKSB7XG4gIHJldHVybiBgJHtuYW1lfSAke3N1cm5hbWV9YFxufVxuXG5cbmZvcihsZXQgaSA9IDA7IGkgPCBzaXplOyBpKyspe1xuICBncmVldChuYW1lc1tpXSwgc3VybmFtZXNbaV0pO1xufSIsInJ1bnMiOlszNSwzNSwzOSwzMiwzOSwzOSwzOSwzOSwzNSwzNSwzNSwzOSwzNSwzOSw0NiwzOSwzNSwzOSwzMiwzOSwzOSwzNSwzOSwzOSwzOSwzMiwyOCwyNSwyNSwzMiwzMiwyOCwxMCwyOCwyNSwxNCwxNywyOCwzNSwyOCwzOSwzOSwzOSwzOSwzNSwzOSwyNSwzOSwzOSwzOSwzNSwzOSwzOSwzOSwzOSwzNSwzNSwzNSwzOSwzOSwzOSwzMiwzMiwzNSwzNSwyNSwzNSwzMiwzMiwzNSwxNyw0MiwyOCwyNSwzOSwzMiwzNSwzOSwyOCwyMSwzNSwzOSwzNSwyOCwzOSwzOSwzNSwxNywyNSwyOCwxNCwxNywyNSwyMSwzNSwzNSwzNSwzNSwzNSwzMl0sIm9wcyI6MzN9LHsibmFtZSI6Ik5hbWVkIHBhcmFtZXRlcnMiLCJjb2RlIjoiZnVuY3Rpb24gZ3JlZXQoe25hbWUsIHN1cm5hbWV9KSB7XG4gIHJldHVybiBgJHtuYW1lfSAke3N1cm5hbWV9YFxufVxuXG5mb3IobGV0IGkgPSAwOyBpIDwgc2l6ZTsgaSsrKXtcbiAgZ3JlZXQoe25hbWU6IG5hbWVzW2ldLCBzdXJuYW1lOiBzdXJuYW1lc1tpXX0pO1xufSIsInJ1bnMiOlszNSwzNSwzOSwyOCwzNSwzOSwzNSwzNSwzMiwzNSwzNSwzOSwzNSwzOSw0MiwzNSwzMiwzNSwzMiwzOSwzOSwzNSwzOSwzOSwzOSwzMiwyOCwyMSwyNSwzMiwzMiwyOCwxMCwyNSwyMSwxNCwxNCwzMiwzNSwyOCwzOSwzOSwzNSwzNSwzNSwzNSwyNSwzNSwzOSwzOSwzNSwzOSwzNSwzOSwzOSwzNSwzMiwzMiwzOSwzOSwzOSwzMiwzMiwzMiwzNSwyOCwzNSwyOCwyOCwzNSwxNyw0MiwyOCwyNSwzNSwzMiwzNSwzOSwyOCwyMSwzNSwzNSwzMiwyOCwzOSwzNSwzNSwxNywyNSwyNSw3LDIxLDIxLDI1LDM1LDM1LDM1LDM1LDM1LDMyXSwib3BzIjozMn1dLCJ1cGRhdGVkIjoiMjAyMi0wMy0yMFQxMDo0NDo0Mi45MjRaIn0%3D) — **33 ops/s** for ordered vs **32 ops/s** for named which is 3% difference

- [**10000000** invocations](https://perf.link/#eyJpZCI6IjgyMHlrczBqOGdrIiwidGl0bGUiOiJJbnZva2luZyBmdW5jdGlvbiB3ICYgdy9vIG9iamVjdCBjcmVhdGlvbiAxMDAwMDAwMCIsImJlZm9yZSI6ImNvbnN0IHNpemUgPSAxMDAwMDAwMDtcblxuY29uc3QgbmFtZXMgPSBuZXcgQXJyYXkoc2l6ZSkuZmlsbCgwKS5tYXAoKF8sIGluZGV4KSA9PiBgbmFtZSR7aW5kZXh9YCk7XG5cbmNvbnN0IHN1cm5hbWVzID0gbmV3IEFycmF5KHNpemUpLmZpbGwoMCkubWFwKChfLCBpbmRleCkgPT4gYHN1cm5hbWUke2luZGV4fWApOyIsInRlc3RzIjpbeyJuYW1lIjoiT3JkZXJlZCBwYXJhbWV0ZXJzIiwiY29kZSI6ImZ1bmN0aW9uIGdyZWV0KG5hbWUsIHN1cm5hbWUpIHtcbiAgcmV0dXJuIGAke25hbWV9ICR7c3VybmFtZX1gXG59XG5cblxuZm9yKGxldCBpID0gMDsgaSA8IHNpemU7IGkrKyl7XG4gIGdyZWV0KG5hbWVzW2ldLCBzdXJuYW1lc1tpXSk7XG59IiwicnVucyI6WzMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDIsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDIsMiwyLDMsMywzLDMsMywzLDMsMiwzLDIsMywzLDMsMywyLDMsMywzLDMsMiwzLDNdLCJvcHMiOjJ9LHsibmFtZSI6Ik5hbWVkIHBhcmFtZXRlcnMiLCJjb2RlIjoiZnVuY3Rpb24gZ3JlZXQoe25hbWUsIHN1cm5hbWV9KSB7XG4gIHJldHVybiBgJHtuYW1lfSAke3N1cm5hbWV9YFxufVxuXG5mb3IobGV0IGkgPSAwOyBpIDwgc2l6ZTsgaSsrKXtcbiAgZ3JlZXQoe25hbWU6IG5hbWVzW2ldLCBzdXJuYW1lOiBzdXJuYW1lc1tpXX0pO1xufSIsInJ1bnMiOlszLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywzLDMsMywyLDIsMiwyLDMsMywzLDMsMywzLDIsMywyLDMsMywzLDMsMiwzLDMsMywzLDIsMywzXSwib3BzIjoyfV0sInVwZGF0ZWQiOiIyMDIyLTAzLTIwVDEwOjU4OjE3LjM4NloifQ%3D%3D) — **2 ops/s** for ordered vs **2 ops/s** for named, which is no difference at all.

My take on this (and please correct me if I’m wrong): the more intensive the program, the less performance difference it makes, which, in turn, means that the object creation relative impact on the app is negligible.

## Conclusion

Using ordered function parameters is:

- Less readable

- Less maintainable

- Error prone

Using single parameter and object destructuring is:

- Clear and concise

- Easy to keep backwards compatible

- Explicit, hence less room for mistakes