ES6 Arrow Functions: The Modern Way to Write Functions

The Problem That Arrow Functions Were Built to Solve

Suppose you have an array of IRCTC train ticket fares, in rupees, and every fare needs a flat convenience fee of ₹30 added before it can be shown to the passenger. You already know how to write a function that transforms one value into another, and you already know that .map() runs a function once for every element of an array and collects the results into a new array. Here is the straightforward way to do it, using a function expression as the argument to .map():

const fares = [560, 1240, 875, 2100];

const withFee = fares.map(function(fare) {
  return fare + 30;
});

console.log(withFee); // [590, 1270, 905, 2130]

That code is completely correct. But look at how much of it is scaffolding rather than logic. The actual idea being expressed is tiny — "take a fare, add 30" — yet it takes the keyword function, a pair of parentheses, a pair of curly braces, and an explicit return statement to say it. When you write dozens of these short, throwaway functions in a program — one for every .map(), every .filter(), every .reduce() — the repeated scaffolding becomes visual noise that hides the actual logic underneath it.

ES6 (officially ECMAScript 2015, the JavaScript language update from 2015) introduced a new, shorter syntax for exactly this situation: the arrow function. Here is the identical computation written as one:

const withFeeArrow = fares.map(fare => fare + 30);

console.log(withFeeArrow); // [590, 1270, 905, 2130]

Same input, same output, same order of operations — just far less scaffolding around the one idea that actually matters. This chapter builds up arrow function syntax piece by piece, and then covers the one behavioural difference that makes arrow functions more than "just shorter" — how they handle the keyword this, which regular functions and arrow functions treat in fundamentally different ways.

From a Function Expression to an Arrow Function, One Step at a Time

Rather than memorising arrow syntax as a new set of rules, it helps to see it as a mechanical rewriting of a function expression you already know. Start with a plain function that squares a number:

const square = function(n) {
  return n * n;
};

Step 1 — drop the word function and put an arrow after the parameter list. The arrow, =>, is why these are called "arrow functions" — it is literally drawn as an arrow made from an equals sign and a greater-than sign.

const square = (n) => {
  return n * n;
};

Step 2 — if there is exactly one parameter, its parentheses become optional. This is a small convenience, not a required change:

const square = n => {
  return n * n;
};

Step 3 — if the entire body is a single return statement, you can drop the curly braces, drop the word return, and just write the expression. JavaScript understands that a one-line arrow function body is automatically the value to be returned:

const square = n => n * n;

console.log(square(6)); // 36

Trace that last line: square(6) calls the arrow function with n bound to 6. The body is the expression n * n, which evaluates to 6 * 6 = 36. Because there is no block (no curly braces), JavaScript treats that expression's value as the function's return value automatically — this is called an implicit return, and it is the single biggest reason arrow functions read as "shorter." No function, no parentheses (for one parameter), no braces, no return — just the transformation itself.

Anatomy of an Arrow Function

Before going further, it is worth slowing down and naming every piece of the syntax precisely, because the exam-style questions on this topic usually test whether you can identify each part correctly.

Three rules to fix firmly, because they are the most common source of syntax errors when students first switch to arrow syntax:

• Zero parameters need empty parentheses — you cannot omit them. const greet = () => "Namaste!"; is valid; const greet = => "Namaste!"; is not.
• Exactly one parameter can drop the parentheses, but does not have to. n => n * n and (n) => n * n are both valid and behave identically.
• Two or more parameters always need parentheses, exactly like a normal parameter list. const add = (a, b) => a + b; is required; const add = a, b => a + b; is a syntax error.

const add = (a, b) => a + b;
console.log(add(15, 27)); // 42

const greet = () => "Namaste!";
console.log(greet()); // Namaste!

Concise Body vs. Block Body — and Why the Return Keyword Sometimes Comes Back

Everything so far has used a concise body — a single expression with an implicit return. But plenty of real logic needs more than one line: intermediate variables, conditionals, multiple steps. For that, arrow functions support a block body, written with curly braces exactly like a regular function, and inside a block body the implicit return disappears — you must write return explicitly, or the function returns undefined.

Here is a function that computes a CBSE-style grade band from marks obtained out of a maximum:

const cbseGrade = (marksObtained, maxMarks) => {
  const percentage = (marksObtained / maxMarks) * 100;
  if (percentage >= 91) return "A1";
  if (percentage >= 81) return "A2";
  return "B1";
};

console.log(cbseGrade(456, 500)); // A1

Trace it: 456 / 500 = 0.912, multiplied by 100 gives 91.2. That is >= 91, so the first if matches and the function returns the string "A1" immediately — the two lines after it never run. Notice the braces are doing real work here: they mark the start of a block containing three separate statements, so JavaScript needs an explicit return to know which value comes out of the function. This is the rule to hold onto: concise body (no braces) → implicit return. Block body (braces) → you must write return yourself. Mixing these up is the single most common arrow-function bug, and it deserves its own section.

The Object-Literal Trap — A Genuine, Verifiable Misconception

Suppose you want an arrow function that builds and returns an object in one line — a very natural thing to want, since object literals also use curly braces. A student might write this, expecting the concise-body implicit return to hand back an object:

const makeItem = price => { price: price };

console.log(makeItem(499)); // undefined

This does not throw an error, and it does not return an object — it prints undefined, and understanding exactly why is one of the best ways to see how a JavaScript parser actually reads your code. When the parser sees => {, it has to decide instantly whether that opening brace begins a block body or an object literal. The rule it follows is simple and unforgiving: a { immediately after => is always read as the start of a block body, never as an object. So JavaScript parses the inside of those braces as ordinary statements, not as key-value pairs.

Inside a block, price: followed by an expression is legal JavaScript — it is a rarely-used feature called a labelled statement (the same mechanism used with break label; in nested loops). So price: price; is read as "a label named price, attached to the expression statement price" — it evaluates the parameter and throws the value away, since labels are not object keys. The block then ends with no return statement anywhere in it, so the function falls off the end and implicitly returns undefined — exactly as any block-body arrow function does when it lacks a return.

Now here is the part that surprises even more students: if you add a second property to try to make it look more like a real object, the code does not fail the same quiet way — it refuses to run at all:

const makeItem = (id, price) => { id: id, price: price };

console.log(makeItem(7, 499)); // SyntaxError — this line never executes

id: still parses fine as a label. But after a label, JavaScript expects a single statement — and id, price: price cannot be read as one. The comma tries to form a comma-operator expression out of id and price, but then hits the bare colon in price: in the middle of that expression, where a colon has no legal meaning. There is no line break for automatic semicolon insertion to rescue the situation, so the parser gives up before your program ever starts running: SyntaxError: Unexpected token ':'. The console.log line is never reached — the whole file fails to load.

Both versions fail for related but distinct reasons, and both come from the same root mistake: writing an object literal directly after =>. The fix is identical in every case — wrap the object in an extra pair of parentheses, so the parser sees an expression, not a block:

const makeItem = (id, price) => ({ id: id, price: price });

console.log(makeItem(7, 499)); // { id: 7, price: 499 }

The parentheses tell the parser "this { is the start of an expression I am about to return," which rules out the block-body interpretation entirely. This single habit — parenthesise an object you want an arrow function to return — is worth memorising on its own, because the two failure modes above (silent undefined, or an outright SyntaxError) are genuinely difficult to debug from the error message alone if you do not already know this rule.

Arrow Functions with map, filter, and reduce

Arrow functions are used constantly with array methods because the function passed to them is almost always short and disposable — exactly the case arrow syntax was designed for. Consider a list of UPI transaction amounts, in rupees:

const transactions = [250, 15000, 999, 5000, 120];

const highValue = transactions.filter(amount => amount > 1000);
console.log(highValue); // [15000, 5000]

const total = transactions.reduce((sum, amount) => sum + amount, 0);
console.log(total); // 21369

.filter() keeps only the elements for which the arrow function returns a truthy value — here, 15000 > 1000 and 5000 > 1000 are both true, while 250, 999, and 120 are not, so exactly two elements survive, in their original order. .reduce() is slightly different: its arrow function takes two parameters — an accumulator (sum, starting at the 0 given as the second argument to reduce) and the current element (amount) — and its return value becomes the accumulator for the next call. Tracing it: 0+250=250, 250+15000=15250, 15250+999=16249, 16249+5000=21249, 21249+120=21369. The final accumulator, 21369, is what reduce returns.

The Real Difference: How Arrow Functions Treat this

Everything covered so far has been about syntax — arrow functions look shorter. But if that were the entire story, arrow functions would just be a stylistic preference. The genuine, behavioural reason JavaScript introduced them is how they handle the keyword this, and this is where the most important, most commonly tested misconception lives.

Misconception to correct directly: "Arrow functions are just a shorter way to write the same function." This is false. A regular function gets its own, freshly-decided value of this every time it is called, based on how it was called. An arrow function has no this of its own at all — it looks outward, to whatever this meant in the code surrounding it when the arrow function was written. This is called lexical this, and it solves a real, extremely common bug.

Consider an object representing a shopping cart that needs to print each item alongside the store name:

const cart = {
  items: ["Notebook", "Pen", "Eraser"],
  store: "Local Kirana",
  listItems: function() {
    this.items.forEach(function(item) {
      console.log(this.store + ": " + item);
    });
  }
};

cart.listItems();
// undefined: Notebook
// undefined: Pen
// undefined: Eraser

This is a classic, real bug. listItems itself is called as cart.listItems(), so inside listItems, this correctly refers to cart, and this.items correctly finds the array. But the function passed to .forEach() is a completely separate, plain function. .forEach() calls it on its own, with no object in front of the dot — so its this is decided fresh, and it does not point at cart at all. this.store inside that inner function looks for a store property somewhere else entirely, and finds nothing — hence undefined, three times over, even though cart.store clearly holds "Local Kirana".

Now replace only the inner callback with an arrow function:

const cart2 = {
  items: ["Notebook", "Pen", "Eraser"],
  store: "Local Kirana",
  listItems: function() {
    this.items.forEach((item) => {
      console.log(this.store + ": " + item);
    });
  }
};

cart2.listItems();
// Local Kirana: Notebook
// Local Kirana: Pen
// Local Kirana: Eraser

Nothing else changed — same object, same method, same call. The only difference is that the callback passed to .forEach() is now an arrow function, which has no this of its own. So when it reads this.store, it looks outward to the nearest enclosing regular function — listItems — and borrows its this, which is cart2, exactly as intended. This is not a smaller version of the same feature; it is a different rule for resolving this altogether, and it is the actual engineering reason arrow functions exist, not merely a syntax convenience.

Two Places Where Arrow Functions Should NOT Be Used

Because arrow functions borrow this from their surroundings instead of getting their own, there are two situations where using one causes a bug rather than fixing one.

1. As a method directly on an object. A method needs its own this, decided by how it is called — which is exactly what a regular function provides and an arrow function does not:

const bike = {
  brand: "Hero",
  describe: () => {
    console.log(this.brand);
  }
};

bike.describe(); // undefined

Because describe is an arrow function, it has no this of its own — it looks outward to whatever this meant in the surrounding scope where the object literal itself was written (at the top level of a module, well outside bike). It never sees bike at all, no matter how it is called, so this.brand is not "Hero". Writing describe: function() { console.log(this.brand); } — or the ES6 shorthand method syntax describe() { console.log(this.brand); } — fixes it, because both of those get a fresh this bound to bike at call time.

2. As a constructor, with new. Regular functions can be used as constructors because JavaScript creates a brand-new object and binds this to it specifically for that call. Arrow functions cannot participate in this at all, because — again — they have no this of their own for new to bind:

const Robot = (name) => { this.name = name; };
const r1 = new Robot("Chitti"); // TypeError: Robot is not a constructor

JavaScript does not even attempt to run the body — it rejects the new call outright, because arrow functions are explicitly marked as non-constructible. If you need a constructor, it must be a regular function or, in modern JavaScript, a class.

A closely related, smaller difference worth knowing: arrow functions do not get their own arguments object either — the same lexical lookup that applies to this applies to arguments too. If an arrow function refers to arguments, it finds whichever regular function encloses it:

function outer() {
  const arrow = () => {
    console.log(arguments);
  };
  arrow(99, 100);
}

outer(1, 2, 3); // [Arguments] { '0': 1, '1': 2, '2': 3 }

Even though arrow was called with 99, 100, the arguments it prints belongs to outer, called with 1, 2, 3 — because the arrow function has no arguments of its own and looks outward, exactly as it does for this. When an arrow function genuinely needs to collect its own variable number of arguments, the fix is the rest parameter syntax, (...args) => { /* args is a real array here */ }, which works normally inside arrow functions.

Practice Questions

1. Rewrite this function expression as an arrow function with a concise body: const cube = function(n) { return n * n * n; };
2. What does the following print, and why? const shout = message => { message.toUpperCase(); }; console.log(shout("namaste"));
3. A student writes const isEven = n => n % 2 === 0; and calls isEven(17). What is the returned value, and what type is it?
4. What happens when this code runs? const makeItem = (id, price) => { id: id, price: price }; console.log(makeItem(7, 499));
5. A teacher's object has a method written as an arrow function: const teacher = { name: "Meera Ma'am", greet: () => console.log("I am " + this.name) };. What does teacher.greet() print, and why doesn't it print the teacher's name?
6. Given const marks = [78, 45, 92, 60, 88];, write one line using .filter() and an arrow function to get only the marks that are 60 or above.

Answer Key

1. const cube = n => n * n * n; — one parameter (parentheses optional), single expression body, implicit return.
2. It prints undefined. The arrow function has a block body (curly braces), and message.toUpperCase(); is only an expression statement — its result is never captured or returned. Since there is no return keyword anywhere in the block, the function falls off the end and implicitly returns undefined. This is a block-body implicit-return trap, distinct from the object-literal trap, but caused by the same rule: block bodies never auto-return.
3. It returns false, a boolean. 17 % 2 is 1 (the remainder when 17 is divided by 2), and 1 === 0 is false, which is what the concise body implicitly returns.
4. This throws a SyntaxError: Unexpected token ':' before the program even starts running — console.log never executes. id: parses as a labelled statement, but the parser then tries to read id, price: price as a single statement and cannot legally place a bare : there. The fix is to wrap the object in parentheses: (id, price) => ({ id: id, price: price }).
5. It prints I am undefined (or throws, depending on what this resolves to outside the object, but it never prints "Meera Ma'am" either way). Because greet is an arrow function, it has no this of its own bound to teacher — it looks outward to the surrounding scope's this, which is not the teacher object no matter how teacher.greet() is called. Using a regular function (greet: function() { ... } or shorthand greet() { ... }) would fix it.
6. const passing = marks.filter(mark => mark >= 60); — this returns [78, 92, 60, 88], in original order, since 45 is the only mark below 60.

Summary

• An arrow function replaces the function keyword with => after the parameter list. Zero parameters need (); exactly one parameter can drop the parentheses; two or more always need them.
• A concise body (no curly braces) implicitly returns the value of its single expression. A block body (curly braces) behaves like a normal function body and needs an explicit return, or it silently returns undefined.
• A { written directly after => is always read as the start of a block, never an object literal — attempting to return an object literal directly causes either a silent undefined (one property, parsed as a label) or a SyntaxError (two or more properties). Wrap the object in parentheses to fix both: () => ({ key: value }).
• The real, behavioural reason arrow functions exist is lexical this: an arrow function has no this of its own and borrows it from the enclosing scope, which is exactly what you want inside callbacks like .forEach() passed from inside a method. Regular functions instead get a fresh this decided by how they are called, which is why they lose track of the surrounding object inside a callback.
• Because of lexical this, arrow functions should not be used as object methods (they never see the object they belong to) or as constructors with new (they have no this for new to bind, and JavaScript rejects the call outright with a TypeError).
• Arrow functions also have no arguments object of their own — a reference to arguments inside one resolves to the nearest enclosing regular function's arguments, if any. Use rest parameters (...args) when an arrow function needs to collect its own arguments.

Think About It

Think about this: How would you explain es6 arrow functions: the modern way to write functions to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.