featured

These 10 amazing features were all about writing shorter, safer, and more expressive code.

1. Private methods and fields

We need our privacy. There’s no two ways about it.

And so do OOP classes; but in JavaScript it was once impossible to strictly declare private members.

It was once impossible to declare private members in a JavaScript class.

A member was traditionally prefixed with an underscore (_) to indicate that it was meant to be private, but it could still be accessed and modified from outside the class.

JavaScriptCopied!

class Person {
  _firstName = 'Coding';
  _lastName = 'Beauty';

  get name() {
    return `${this._firstName} ${this._lastName}`;
  }
}

const person = new Person();
console.log(person.name); // Coding Beauty

// Members intended to be private can still be accessed
// from outside the class
console.log(person._firstName); // Coding
console.log(person._lastName); // Beauty

// They can also be modified
person._firstName = 'Debugging';
person._lastName = 'Nightmares';

console.log(person.name); // Debugging Nightmares

With ES2022, we can now add private fields and members to a class, by prefixing it with a hashtag (#). Trying to access them from outside the class will cause an error:

JavaScriptCopied!

class Person {
  #firstName = 'Coding';
  #lastName = 'Beauty';

  get name() {
    return `${this.#firstName} ${this.#lastName}`;
  }
}

const person = new Person();
console.log(person.name);

// SyntaxError: Private field '#firstName' must be
// declared in an enclosing class
console.log(person.#firstName);
console.log(person.#lastName);

Note that the error thrown here is a syntax error, which happens at compile time; the code doesn’t run at all; the compiler doesn’t expect you to even try to access private fields from outside a class, so it assumes you’re trying to declare one.

“Ergonomic brand” checks for private fields

With private fields come a new keyword to safely check if a class object contains a particular one — the in keyword:

JavaScriptCopied!

class Car {
  #color;
  hasColor() {
    return #color in this;
  }
}
const car = new Car();
console.log(car.hasColor()); // true;

It correctly distinguishes private fields with the same names from different classes:

JavaScriptCopied!

class Car {
  #color;
  hasColor() {
    return #color in this;
  }
}
class House {
  #color;
  hasColor() {
    return #color in this;
  }
}

const car = new Car();
const house = new House();
console.log(car.hasColor()); // true;
console.log(car.hasColor.call(house)); // false
console.log(house.hasColor()); // true
console.log(house.hasColor.call(car)); // false

And don’t ask me about the name; I also have no idea why they’re called that (do you?).

Ergonomics as far as I’m concerned is all about keeping good sitting posture while using your computer (?) 🤔.

Although I guess you could twist this definition to allow for this new feature — or any new feature for that matter. They’re all about comfort, right? Less pain writing code.

But I guess English isn’t a closed language and you can always add new words and additional definitions (just ask Shakespeare).

2. Immutable sort(), splice(), and reverse()

ES2023 came fully packed with immutable versions of these 3 heavily used array methods.

Okay maybe splice() isn’t used as much as the others, but they all mutate the array in place.

JavaScriptCopied!

const original = [5, 1, 3, 4, 2];

const reversed = original.reverse();
console.log(reversed); // [2, 4, 3, 1, 5] (same array)
console.log(original); // [2, 4, 3, 1, 5] (mutated)

const sorted = original.sort();
console.log(sorted); // [1, 2, 3, 4, 5] (same array)
console.log(original); // [1, 2, 3, 4, 5] (mutated)

const deleted = original.splice(1, 2, 7, 10);
console.log(deleted); // [2, 3] (deleted elements)
console.log(original); // [1, 7, 10, 4, 5] (mutated)

Immutability gives us predictable and safer code; debugging is much easier as we’re certain variables never change their value.

Arguments are exactly the same, with splice() and toSpliced() having to differ in their return value.

JavaScriptCopied!

const original = [5, 1, 3, 4, 2];

const reversed = original.toReversed();
console.log(reversed); // [2, 4, 3, 1, 5] (copy)
console.log(original); // [5, 1, 3, 4, 2] (unchanged)

const sorted = original.toSorted();
console.log(sorted); // [1, 2, 3, 4, 5] (copy)
console.log(original); // [5, 1, 3, 4, 2] (unchanged)

const spliced = original.toSpliced(1, 2, 7, 10);
console.log(spliced); // [1, 7, 10, 4, 5] (copy)
console.log(original); // [5, 1, 3, 4, 2] (unchanged)

3. Top-level await

Did you know: F# was the first language to introduce async/await? As far back as 2007! But it took JavaScript 10 good years to catch up.

await pauses execution in the async context until a Promise resolves.

Previously we could only use this operator in an async function, but it could never work in the global scope.

JavaScriptCopied!

function setTimeoutAsync(timeout) {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve();
    }, timeout);
  });
}

// SyntaxError: await is only valid in async functions
await setTimeoutAsync(3000);

With ES2022, now we can:

JavaScriptCopied!

function setTimeoutAsync(timeout) {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve();
    }, timeout);
  });
}

// ✅ Waits for timeout - no error thrown
await setTimeoutAsync(3000);

4. Promise.any()

If you know Promise.all(), then you can easily guess what this does: wait for one Promise to resolve and return the result.

JavaScriptCopied!

async function getHelpQuickly() {
  const response = await Promise.any([
    cautiousHelper(),
    kindHelper(),
    wickedHelper(),
  ]);
  console.log(response); // Of course!
}

async function cautiousHelper() {
  await new Promise((resolve) => {
    setTimeout(() => {
      resolve('Uum, oohkaay?');
    }, 2000);
  });
}

async function kindHelper() {
  return 'Of course!';
}

function wickedHelper() {
  return Promise.reject('Never, ha ha ha!!!');
}

Point to note: Promise.any() still waits for *all* the promises in the current async context to resolve, even though it only returns the result of the first one.

JavaScriptCopied!

await getHelpQuickly(); // outputs "Of course!" immediately
// Still waits for 2 seconds

5. Array find from last

Array find() searches for an array element that passes a specified test condition, and findIndex() gets the index of such an element.

While find() and findIndex() both start searching from the first element of the array, there are instances where it would be preferable to start the search from the last element instead.

There are scenarios where we know that finding from the last element might achieve better performance. For example, here we’re trying to get the item in the array with the value prop equal to y. With find() and findIndex():

JavaScriptCopied!

const letters = [
  { value: 'v' },
  { value: 'w' },
  { value: 'x' },
  { value: 'y' },
  { value: 'z' },
];

const found = letters.find((item) => item.value === 'y');
const foundIndex = letters.findIndex((item) => item.value === 'y');

console.log(found); // { value: 'y' }
console.log(foundIndex); // 3

This works, but as the target object is closer to the tail of the array, we might be able to make this program run faster if we use the new ES2022 findLast() and findLastIndex() methods to search the array from the end.

JavaScriptCopied!

const letters = [
  { value: 'v' },
  { value: 'w' },
  { value: 'x' },
  { value: 'y' },
  { value: 'z' },
];

const found = letters.findLast((item) => item.value === 'y');
const foundIndex = letters.findLastIndex((item) => item.value === 'y');

console.log(found); // { value: 'y' }
console.log(foundIndex); // 3

Another use case might require that we specifically search the array from the end to get the correct item.

If we’re finding the last even number in a list of numbers, find() and findIndex() produces a totally wrong result:

JavaScriptCopied!

const nums = [7, 14, 3, 8, 10, 9];

// gives 14, instead of 10
const lastEven = nums.find((value) => value % 2 === 0);

// gives 1, instead of 4
const lastEvenIndex = nums.findIndex((value) => value % 2 === 0);

console.log(lastEven); // 14
console.log(lastEvenIndex); // 1

We could call the reverse() method on the array to reverse the order of the elements before calling find() and findIndex(). But this approach would cause unnecessary mutation of the array; reverse() reverses the elements of an array in place.

The only way to avoid this mutation would be to make a new copy of the entire array, which could cause performance problems for large arrays.

Also findIndex() still wouldn’t on the reversed array, as reversing the elements would also mean changing the indexes they had in the original array. To get the original index, we would need to perform an additional calculation, which means writing more code.

JavaScriptCopied!

const nums = [7, 14, 3, 8, 10, 9];

// Copying the entire array with the spread syntax before
// calling reverse()
const reversed = [...nums].reverse();

// correctly gives 10
const lastEven = reversed.find((value) => value % 2 === 0);

// gives 1, instead of 4
const reversedIndex = reversed.findIndex((value) => value % 2 === 0);

// Need to re-calculate to get original index
const lastEvenIndex = reversed.length - 1 - reversedIndex;

console.log(lastEven); // 10
console.log(reversedIndex); // 1
console.log(lastEvenIndex); // 4

It’s cases like where the findLast() and findLastIndex() methods come in handy.

JavaScriptCopied!

const nums = [7, 14, 3, 8, 10, 9];

const lastEven = nums.findLast((num) => num % 2 === 0);
const lastEvenIndex = nums.findLastIndex((num) => num % 2 === 0);

console.log(lastEven); // 10
console.log(lastEvenIndex); // 4

This code is shorter and more readable. Most importantly, it produces the correct result.

6. String replaceAll()

We already had replace() for quickly replace a substring within a string.

JavaScriptCopied!

const str =
  'JavaScript is so terrible, it is unbelievably terrible!!';

const result = str.replace('terrible', 'wonderful');

console.log(result);
// JavaScript is so wonderful, it is unbelievably terrible!!
// Huh?

But it only does so for the first occurrence of the substring unless you use a regex; now we have replaceAll() to replace every single instance of that substring.

JavaScriptCopied!

const str =
  'JavaScript is so terrible, it is unbelievably terrible.';

const result = str.replaceAll('terrible', 'wonderful');

console.log(result);

// JavaScript is wonderful, it is unbelievably wonderful.
// Now you're making sense!

7. Array with() and at()

at() came first and with() came a year after that in 2023.

They are the functional and immutable versions of single-element array modification and access.

JavaScriptCopied!

const colors = ['pink', 'purple', 'red', 'yellow'];

console.log(colors.at(1)); // purple

console.log(colors.with(1, 'blue'));
// ['pink', 'blue', 'red', 'yellow']

// Original not modified
console.log(colors);
// ['pink', 'purple', 'red', 'yellow']

The cool thing about these new methods is how they let you get and change element values with negative indexing.

JavaScriptCopied!

// index -N is same as index arr.length - N

const fruits = ['banana', 'apple', 'orange', 'butter???'];

console.log(fruits.at(-3)); // apple
console.log(fruits.at(-1)); // butter???

console.log(fruits.with(-1, 'watermelon'));
// ['banana', 'apple', 'orange', 'watermelon'] ✅

8. static static static

Static class fields, static private methods (2022).

Static methods access other private/public static members in the class using the this keyword; instance methods with this.constructor:

JavaScriptCopied!

class Person {
  static #count = 0;
  static getCount() {
    return this.#count;
  }
  // Instance method
  constructor() {
    this.constructor.#incrementCount();
  }
  static #incrementCount() {
    this.#count++;
  }
}
const person1 = new Person();
const person2 = new Person();
console.log(Person.getCount()); // 2

Static blocks.

Executed only once when the *class* is created. It’s like static constructors in other OOP languages like C# and Java.

JavaScriptCopied!

class Vehicle {
  static defaultColor = 'blue';
}
class Car extends Vehicle {
  static colors = [];
  static {
    this.colors.push(super.defaultColor, 'red');
  }
  static {
    this.colors.push('green');
  }
}
console.log(Car.colors); // [ 'blue', 'red', 'green' ]

When they’re multiple static blocks, they’re executed in the order they’re declared, along with any static fields in between. The super property in a static block to access properties of the superclass.

9. Logical assignment operators

They let a variable perform a logical operation with another variable and re-assign the result to itself.

We use them like this:

JavaScriptCopied!

left ??= right;
left ||= right;
left &&= right;

They’re as good as:

JavaScriptCopied!

// More like exactly the same as
left = (left ?? right);
left = (left || right);
left = (left && right);

??=. Quickly assign a value to a variable *if* it is null or undefined (“nullish”).

JavaScriptCopied!

user.preferredName ??= generateDumbUserName();

||=. Like ??=, but assigns the value for any falsy value (0, undefined, null, '', NaN, or false).

JavaScriptCopied!

user.profilePicture ||= "/angry-stranger.png";

And then &&=. Something like the reverse; only assigns when the value is truthy (not falsy).

JavaScriptCopied!

user.favoriteLanguage = await setFavoriteLanguage(input.value);

user.favoriteLanguage &&= 'Assembly'; // You're lying! It's Assembly!

10. Numerical separators

Tiny new addition to make big number literals more readable and human-friendly.

JavaScriptCopied!

const isItPi = 3.1_415_926_535;

const isItAvagadro = 602_214_076_000_000_000_000_000;

const isItPlanck = 6.626_070_15e-34;

const isItG = 6.674_30e-11;

// Works for other number bases too...

The compiler completely ignores those pesky underscores — they’re all for you, the human!

Final thoughts

These are the juicy new JavaScript features that arrived in the last 3 years. Use them to boost your productivity as a developer and write cleaner code with greater conciseness, expressiveness and clarity.

With the pipeline operator you’ll stop writing code like this:

and start writing code like this:

So refreshingly clean — and elegant! All those temporary variables are gone — not to mention the time it took to come up with those names *and* type them (not everyone types like The Flash, unfortunately).

You may have heard this partially true quote attributed to Phil Karlton: “There are only two hard things in computer science: cache invalidation and naming things“.

Using the JavaScript pipeline operator clears out the clutter to boost readability and write data transforming code (basically all code) in a more intuitive manner.

Verbosity should be avoided as much as possible, and this works so much better to compact code than reusing short-named variables:

Hopefully, almost no one codes like this on a regular basis. It’s a pretty horrible technique when done in a large scale; a perfect example showing why we embrace immutability and type systems.

Unlike the pipeline operator, there’s no certainty that the variable always contains the value you set at any given point; you’ll need to climb up the scope to look for re-assignments. We can have used the _ at an earlier point in the code; the value it has at various points in the code is simply not guaranteed.

Now we’re just using an underscore, so without checking out the right-hand side of those re-assignments you can’t quickly know what the type of the variable is, unless you have a smart editor like VS Code (although I guess you could say that doesn’t matter since they’re supposed to be “temporary” — at least until they’re not!).

All in all, poor readability. Fragile and Unstable. 5 times harder for someone new to understand. Also, some would say underscores are “ugly”, especially in languages like JavaScript where they hardly show up.

Okay, so why don’t we just avoid this infestation of temporary underscores, and nest them into one gigantic one-liner?

It’s a mess. The underscore is gone, but who in the world can understand this at a glance? How easy is it to tell how the data flows throughout this code, and make any necessary adjustments.

Understanding, at a glance — this is what we should strive for with every line of code we write.

The pipeline operator greatly outshines every other method, giving us both freedom from temporary variables and readability. It was designed for this.

Here the % only exists within this particular pipeline.

Method chaining?

Who hasn’t used and combined heavily popular array methods like map, filter, and sort? Very hard to avoid in applications involving any form of list manipulation.

This is actually great. There aren’t any temporary variables or unreadable nesting here either and we can easily follow the chain from start to finish.

The formatting lets us easily add more methods at any point in the chain; feature-packed editor like VS Code can easily swap the processing order of two methods, with the Ctrl + Up and Ctrl + Down shortcuts.

There’s a reason why libraries like core http and jQuery are designed like this:

The problem with method chaining is that, we simply can’t use it everywhere. If the class wasn’t designed like that we’re stuck and out in the cold.

It doesn’t work very well with generator methods, async/await and function/method calls outside the object, like we saw here:

But all this and more work with the pipeline operator; even object literals and async import function.

Could have been F# pipes

We would have been using the pipeline operator very similarly to F# pipes, with the above turning out like this instead:

There was an alternative design. But you can already see how this makes for an inferior alternative: Only single-function arguments are allowed and the operation is more verbose. Unless the operation is already a single-argument function call.

It’s weird handling of async/await was also a key reason why it got rejected — along with memory usage concerns. So, forget about F# pipes in JS!

Use the pipeline operator right now

Yes you can — with Babel.

Babel has a nice habit of implementing features before they’re officially integrated in the language; it did this for top-level await, optional chaining, and many others. The pipeline operator couldn’t be an exception.

Just use the @babel/plugin-proposal-pipeline-operator plugin and you’re good to.

It’s optional of course — but not for long.

Prettier the code formatter is already prepared.

Even though we can’t say the same about VS Code or Node.js.

Right now there’s even speculation that % won’t be the final symbol pass around in the pipeline; let’s watch and see how it all plays out.

Final thoughts

It’s always great to see new and exciting features come to the language. With the JavaScript pipeline operator, you’ll cleanse your code of temporary variables and cryptic nesting, greatly boost code readability, efficiency, and quality.

You will be an expert on JavaScript generators by the time you’re done reading this.

JavaScript generators are way more than just a fancy feature and we are going to discover many powerful use cases for them, including creating engaging animations, and streaming videos over the internet.

If you’ve never heard of them you may be missing out.

Generators are simply functions that you can pause and resume whenever you want — they don’t execute continuously.

The asterisk * marks the function as a generator, and yield generates values on demand from a .next() call, until the generator is done.

JavaScriptCopied!

function* myGenerator() {
  yield 'Hello';
  yield 'World';
}

const iterator = myGenerator();

console.log(iterator.next()); // {value: 'Hello', done: false}
console.log(iterator.next()); // {value: 'World', done: false}
console.log(iterator.next()); // {value: undefined, done: true}

It’s just like how a physical generator produces electricity not all at once, but as time goes on.

Instead of calling next() you can use the for..of loop, which is great for when the generator generates a lot of data.

JavaScriptCopied!

function* countTo100() {
  for (let i = 0; i < 100; i++) {
    yield i;
  }
}

for (const item of countTo100()) {
  console.log(item);
}
// 1, 2, ... 100

Lazy evaluation

“Calculate only when necessary.”

Much unlike regular functions in JavaScript that execute entirely and return the result.

Let’s say you want a sequence of numbers, but you’re not sure how many. Here’s how a generator helps:

JavaScriptCopied!

function* numberGenerator() {
  let number = 1;
  // infinite loop won't cause freeze in generator
  // -- execution pauses after `yield`
  while (true) {
    yield number++;
  }
}

const numbers = numberGenerator();

console.log(numbers.next().value); // 1
console.log(numbers.next().value); // 2
// you can continue this as long as you need

With generators, you get the next number only when you ask for it.

Better memory utilization

Generators don’t hold all the results in memory, they generate them on the fly.

Imagine you need a sequence of a million numbers. With a regular function, you’d need to store all these numbers in an array, using up significant memory.

A generator is much more efficient:

JavaScriptCopied!

function* bigNumberGenerator() {
  let number = 1;
  while (number <= 100000000) {
    yield number++;
  }
}

const bigNumbers = bigNumberGenerator();

const chunk = 10;
for (let i = 0; i < chunk; i++) {
  const value = bigNumbers.next().value;
  // Use next 10 values...
}

Handling asynchronous tasks

Did you know that Babel transpiles async/await to generators for JavaScript versions that don’t support it natively?

Babel tranforms this:

JavaScriptCopied!

this.it('is a test', async function () {
    const name = await 'coding beauty'
    const num = await new Promise(resolve => resolve(10));
    console.log(`Name: ${name}, Num: ${num}`);
});

To this:

JavaScriptCopied!

function _asyncToGenerator(fn) {
  return function () {
    var gen = fn.apply(this, arguments);
    return new Promise(function (resolve, reject) {
      function step(key, arg) {
        try {
          var info = gen[key](arg);
          var value = info.value;
        } catch (error) {
          reject(error);
          return;
        }
        if (info.done) {
          resolve(value);
        } else {
          return Promise.resolve(value).then(
            function (value) {
              return step('next', value);
            },
            function (err) {
              return step('throw', err);
            }
          );
        }
      }

      return step('next');
    });
  };
}

myFunc(
  'generator async/await example',
  _asyncToGenerator(function* () {
    const name = yield 'coding beauty'; // yield, not await
    const num = yield new Promise((resolve) => resolve(10));
    console.log(`Name: ${name}, Num: ${num}`);
  })
);

Typing animations

Typing animations grab the attention of users and make your website more visually appealing.

They add personality and character to a website by mimicking the typing behavior of a human to create a more human-like experience and establish a unique brand identity.

So with all these benefits you’re feeling excited about infusing your webpages with these energetic visual effects.

Here would be a decent way to go about it, using recursion and setTimeout():

JavaScriptCopied!

function typeAnimation(text, index = 0) {
  if (index < text.length) {
    document.body.innerHTML += text.charAt(index);
    index++;
    setTimeout(typeAnimation, 500);
  }
}

But, it’s cases like this where generators shine:

JavaScriptCopied!

function* typeAnimation(text) {
  for(let char of text) {
    yield char;
  }
}

Since we can generate values whenever we want, we can do this in time intervals using setInterval().

JavaScriptCopied!

const generatorInstance = typeGenerator("Coding Beauty");

function startTypingEffect(elementId, generatorInstance) {
  let element = document.getElementById(elementId);
  setInterval(() => {
    let result = generatorInstance.next();
    !result.done && element.innerHTML += result.value;
  }, 100);
}

startTypingEffect("type-here", generatorInstance);

JavaScriptCopied!

<div id="type-here"></div>

Asynchronous handling

Note: This is NOT the same as being the bedrock of async/await, like we saw earlier. We’re talking about async generators here.

JavaScriptCopied!

function* asyncGenerator() {
  yield new Promise(resolve => setTimeout(() => resolve('Task 1 completed'), 2000));
  yield new Promise(resolve => setTimeout(() => resolve('Task 2 completed'), 3000));
  // ...
}

And here’s how we can use this generator:

JavaScriptCopied!

const asyncGen = asyncGenerator();
asyncGen.next().value.then(console.log);
asyncGen.next().value.then(console.log);

This is such a powerful tool for streaming data in web app in a structured, readable manner — just look at this function that buffers and streams data for a video-sharing app like YouTube:

JavaScriptCopied!

async function* streamVideo({ id }) {
  let endOfVideo = false;
  const downloadChunk = async (sizeInBytes) => {
    const response = await fetch(
      `api.example.com/videos/${id}`
    );
    const { chunk, done } = await response.json();
    if (done) endOfVideo = true;
    return chunk;
  };
  while (!endOfVideo) {
    const bufferSize = 500 * 1024 * 1024;
    yield await downloadChunk(bufferSize);
  }
}

To consume this async generator, we’d use the for await..of loop:

JavaScriptCopied!

for await (const chunk of streamVideo({ id: 2341 })) {
  // process video chunk
}

redux-saga

redux-saga is a library for managing side effects in applications, boasting over 1 million weekly downloads.

Generators play a big role in this library, handling the redux actions to make testing and error handling easier.

Take a look at this simple saga:

JavaScriptCopied!

import { call, put, takeEvery } from 'redux-saga/effects';

function* fetchData(action) {
   try {
      const data = yield call(Api.fetchUser, action.payload.userId);
      yield put({type: "USER_FETCH_SUCCEEDED", data});
   } catch (e) {
      yield put({type: "USER_FETCH_FAILED", message: e.message});
   }
}

function* mySaga() {
  yield takeEvery("USER_FETCH_REQUESTED", fetchData);
}

JavaScriptCopied!

import createSagaMiddleware from 'redux-saga';
import { createStore, applyMiddleware } from 'redux';
import mySaga from './sagas';

const sagaMiddleware = createSagaMiddleware();
const store = createStore(
  reducer,
  applyMiddleware(sagaMiddleware)
);
sagaMiddleware.run(mySaga)

Whenever the USER_FETCH_REQUESTED action is dispatched, redux-saga runs the generator which in turn calls fetchData() to perform the asynchronous network request.

A note on return

What happens when you return a value in a generator function? Let’s see:

JavaScriptCopied!

function* soccerPlayers() {
  yield 'Ronaldo';
  yield 'Messi';
  return 'Neymar';
}

for (const player of soccerPlayers()) {
  console.log(player);
}

// Ronaldo
// Messi

Why isn’t Neymar part of the generated values?

Let’s use .next() to find out if the done property has something to do with it:

JavaScriptCopied!

function* soccerPlayers() {
  yield 'Ronaldo';
  yield 'Messi';
  return 'Neymar';
}

const playerGen = soccerPlayers();
console.log(playerGen.next());
console.log(playerGen.next());
console.log(playerGen.next());

/*
{ value: 'Ronaldo', done: false }
{ value: 'Messi', done: false }
{ value: 'Neymar', done: true }
*/

It turns out that return is not considered a generated value, so for..of doesn’t process it.

Do you remember our very first example:

JavaScriptCopied!

function* myGenerator() {
  yield 'Hello';
  yield 'World';
}

const iterator = myGenerator();

console.log(iterator.next()); // {value: 'Hello', done: false}
console.log(iterator.next()); // {value: 'World', done: false}
console.log(iterator.next()); // {value: undefined, done: true}

You can see that generators only produce values until, but not including when done is true.

So return completes the generator and terminates the function (like any other).

JavaScriptCopied!

function* myGenerator() {
    yield 'Hello';
    return 'End';
    yield 'This will not be executed';
}

Final thoughts

JavaScript generators offer powerful solutions for control flow, memory efficiency, and asynchronous handling. They enhance web development with dynamic animations, streaming data, and managing side effects.

Let’s embrace the versatility of generators for elegant and efficient JavaScript programming.

How common is this?

JavaScriptCopied!

function writeTransactionsToFile(transactions) {
  let writeStatus;

  try {
    fs.writeFileSync('transactions.txt', transactions);
    writeStatus = 'success';
  } catch (error) {
    writeStatus = 'error';
  }

  // do something with writeStatus...
}

It’s yet another instance where we want a value that depends on whether or not there’s an exception.

Normally, you’d most likely create a mutable variable outside the scope for error-free access within and after the try-catch.

But it doesn’t always have to be this way. Not with a functional try-catch.

A pure tryCatch() function avoids mutable variables and encourages maintainability and predictability in our codebase. No external states are modified – tryCatch() encapsulates the entire error-handling logic and produces a single output.

Our catch turns into a one-liner with no need for braces.

JavaScriptCopied!

function writeTransactionsToFile(transactions) {
  // 👇 we can use const now
  const writeStatus = tryCatch({
    tryFn: () => {
      fs.writeFileSync('transactions.txt', transactions);
      return 'success';
    },
    catchFn: (error) => 'error';
  });

  // do something with writeStatus...
}

The tryCatch() function

So what does this tryCatch() function look like anyway?

From how we used it above you can already guess the definition:

JavaScriptCopied!

function tryCatch({ tryFn, catchFn }) {
  try {
    return tryFn();
  } catch (error) {
    return catchFn(error);
  }
}

To properly tell the story of what the function does, we ensure explicit parameter names using an object argument – even though there are just two properties. Because programming isn’t just a means to an end — we’re also telling a story of the objects and data in the codebase from start to finish.

TypeScript is great for cases like this, let’s see how a generically typed tryCatch() could look like:

TypeScriptCopied!

type TryCatchProps<T> = {
  tryFn: () => T;
  catchFn: (error: any) => T;
};
function tryCatch<T>({ tryFn, catchFn }: TryCatchProps<T>): T {
  try {
    return tryFn();
  } catch (error) {
    return catchFn(error);
  }
}

And we can take it for a spin, let’s rewrite the functional writeTransactionsToFile() in TypeScript:

JavaScriptCopied!

function writeTransactionsToFile(transactions: string) {
  // 👇 returns either 'success' or 'error'
  const writeStatus = tryCatch<'success' | 'error'>({
    tryFn: () => {
      fs.writeFileSync('transaction.txt', transactions);
      return 'success';
    },
    catchFn: (error) => return 'error';
  });

  // do something with writeStatus...
}

We use the 'success' | 'error' union type to clamp down on the strings we can return from try and catch callbacks.

Asynchronous handling

No, we don’t need to worry about this at all – if tryFn or catchFn is async then writeTransactionToFile() automatically returns a Promise.

Here’s another try-catch situation most of us should be familiar with: making a network request and handling errors. Here we’re setting an external variable (outside the try-catch) based on whether the request succeeded or not – in a React app we could easily set state with it.

Obviously in a real-world app the request will be asynchronous to avoid blocking the UI thread:

JavaScriptCopied!

async function comment(comment: string) {
  type Status = 'error' | 'success';
  let commentStatus;
  try {
    const response = await fetch('https://api.mywebsite.com/comments', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({ comment }),
    });

    if (!response.ok) {
      commentStatus = 'error';
    } else {
      commentStatus = 'success';
    }
  } catch (error) {
    commentStatus = 'error';
  }

  // do something with commentStatus...
}

Once again we have to create a mutable variable here so it can go into the try-catch and come out victoriously with no scoping errors.

We refactor like before and this time, we async the try and catch functions thereby awaiting the tryCatch():

JavaScriptCopied!

async function comment(comment: string) {
  type Status = 'error' | 'success';
  // 👇 await because this returns Promise<Status>
  const commentStatus = await tryCatch<Status>({
    tryFn: async () => {
      const response = await fetch<('https://api.mywebsite.com/comments', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
        },
        body: JSON.stringify({ comment }),
      });
      // 👇 functional conditional
      return response.ok ? 'success' : 'error';
    },
    catchFn: async (error) => 'error';
  });
  // do something with commentStatus...
}

Readability, modularity, and single responsibility

Two try-catch rules of thumb to follow when handling exceptions:

1. The try-catch should be as close to the source of the error as possible, and
2. Only use one try-catch per function

They will make your code easier to read and maintain in the short- and long-term.

Look at processJSONFile() here, it respects rule 1. The 1st try-catch is solely responsible for handling file-reading errors and nothing else. No more logic will be added to try, so catch will also never change.

And next try-catch in line is just here to deal with JSON parsing.

JavaScriptCopied!

function processJSONFile(filePath) {
    let contents;
    let jsonContents;

    // First try-catch block to handle file reading errors
    try {
        contents = fs.readFileSync(filePath, 'utf8');
    } catch (error) {
        // log errors here
        contents = null;
    }

    // Second try-catch block to handle JSON parsing errors
    try {
        jsonContents = JSON.parse(contents);
    } catch (error) {
        // log errors here
        jsonContents = null;
    }

    return jsonContents;
}

But processJsonFile() completely disregards rule 2, with both try-catch blocks in the same function.

So let’s fix this by refactoring them to their separate functions:

JavaScriptCopied!

function processJSONFile(filePath) {
  const contents = getFileContents(filePath);
  const jsonContents = parseJSON(contents);

  return jsonContents;
}

function getFileContents(filePath) {
  let contents;
  try {
    contents = fs.readFileSync(filePath, 'utf8');
  } catch (error) {
    contents = null;
  }
  return contents;
}

function parseJSON(content) {
  let json;
  try {
    json = JSON.parse(content);
  } catch (error) {
    json = null;
  }
  return json;
}

But we have tryCatch() now – we can do better:

JavaScriptCopied!

function processJSONFile(filePath) {
  return parseJSON(getFileContents(filePath));
}

const getFileContents = (filePath) =>
  tryCatch({
    tryFn: () => fs.readFileSync(filePath, 'utf8'),
    catchFn: () => null,
  });

const parseJSON = (content) =>
  tryCatch({
    tryFn: () => JSON.parse(content),
    catchFn: () => null,
  });

We’re doing nothing more than silencing the exceptions – that’s the primary job these new functions have.

If this occurs frequently, why not even create a “silencer” version, returning the try function’s result on success, or nothing on error?

JavaScriptCopied!

function tryCatch<T>(fn: () => T) {
  try {
    return fn();
  } catch (error) {
    return null;
  }
}

Further shortening our code to this:

JavaScriptCopied!

function processJSONFile(filePath) {
  return parseJSON(getFileContents(filePath));
}

const getFileContents = (filePath) =>
  tryCatch(() => fs.readFileSync(filePath, 'utf8'));

const parseJSON = (content) => tryCatch(() => JSON.parse(content));

Side note: When naming identifiers, I say we try as much as possible to use nouns for variables, adjectives for functions, and… adverbs for higher-order functions! Like a story, the code will read more naturally and could be better understood.

So instead of tryCatch, we could use silently:

JavaScriptCopied!

const getFileContents = (filePath) =>
  silently(() => fs.readFileSync(filePath, 'utf8'));

const parseJSON = (content) => silently(() => JSON.parse(content));

If you’ve used @mui/styles or recompose, you’ll see how a ton of their higher-order functions are named with adverbial phrases — withStyles, withState, withProps, etc., and I doubt this was by chance.

Final thoughts

Of course try-catch works perfectly fine on its own.

We aren’t discarding it, but transforming it into a more maintainable and predictable tool. tryCatch() is even just one of the many declarative-friendly functions that use imperative constructs like try-catch under the hood.

If you prefer to stick with direct try-catch, do remember to use the 2 try-catch rules of thumb, to polish your code with valuable modularity and readability enhancements.

The world’s most popular programming language just got a new update.

Ever since 2015, a new JavaScript version has come out every year with tons of powerful features to make life much easier, and 2023 has been no different. Let’s look at what ES14 has to offer.

1. Array toSorted() method

Sweet syntactic sugar.

ES14 comes with a new toSorted() method that makes it easier to sort an array and return a copy without mutation.

So instead of doing this:

JavaScriptCopied!

const nums = [5, 2, 6, 3, 1, 7, 4];

const clone = [...nums];
const sorted = clone.sort();

console.log(sorted); // [1, 2, 3, 4, 5, 6, 7]

We now get to do this:

JavaScriptCopied!

const nums = [5, 2, 6, 3, 1, 7, 4];

const sorted = nums.toSorted();

console.log(sorted);  // [1, 2, 3, 4, 5, 6, 7]

console.log(nums);  // [5, 2, 6, 3, 1, 7, 4]

And just like sort(), toSorted() takes a callback function that lets you decide how the sort should happen – ascending or descending, alphabetical or numeric.

JavaScriptCopied!

const nums = [5, 2, 6, 3, 1, 7, 4];

const sorted = nums.toSorted((a, b) => b - a);

console.log(sorted); // [7, 6, 5, 4, 3, 2, 1]

2. Hashbang grammar

What’s a hashbang?

Basically, it’s a sequence of characters in a file that tells the Linux Shell what interpreter or engine it should use to run the file. For example:

codingbeauty.shCopied!

#!/bin/bash

echo "How are you all doing today?"

With this hashbang, we can now easily run codingbeauty.sh directly in the shell, after using the chmod command to make the script executable.

Hashbangs also let us hide all the juicy implementation details in our scripts and indicate specific interpreter versions to execute the script files.

So with ES14, we can now do this effortlessly in JavaScript files, like this:

codingbeauty.jsCopied!

#!/usr/bin/env node

console.log("I'm doing great, how are you?");

3. Array toSpliced() method

Those immutability purists out there will no doubt be pleased with all these new Array methods.

toSorted() is to sort() as toSpliced() is to splice():

JavaScriptCopied!

const colors = ['red', 'green', 'blue', 'yellow', 'pink'];

const spliced = colors.toSpliced(1, 2, 'gray', 'white');
console.log(spliced); // [ 'red', 'gray', 'white', 'yellow', 'pink' ]

// Original not modified
console.log(colors); // ['red', 'green', 'blue', 'yellow', 'pink'];

Here toSpliced() removes 2 of the array elements, starting from index 1, and inserts 'gray' and 'white' in their place.

4. Symbols as WeakMap keys

WeakMaps; not very popular, are they?

Well, they’re a lot like Maps, except their keys can only contain non-primitive objects – no strings or numbers allowed here. These keys are stored as weak references, meaning the JavaScript engine can carry out garbage collection on the objects when it needs to if there is no other reference to the objects in memory apart from the keys.

One powerful use of WeakMaps is custom caching: by using objects as keys, you can associate cached values with specific objects. When the objects are garbage collected, the corresponding WeakMap entries are automatically removed, clearing the cache immediately.

JavaScriptCopied!

const map = new Map();
const weakMap = new WeakMap();

const obj1 = { name: 'React' };
const obj2 = { name: 'Angular' };

map.set(obj1, 'Value for obj1 at Coding Beauty');
weakMap.set(obj2, 'Value for obj2 at Coding Beauty');

console.log(map.get(obj1)); // Output: Value for obj1
console.log(weakMap.get(obj2)); // Output: Value for obj2

obj1 = null;
obj2 = null;

console.log(map.get(obj1)); // Output: Value for obj1
console.log(weakMap.get(obj2)); // Output: undefined (obj2 has been garbage collected)

So ES14 makes it possible to define JavaScript Symbols as keys. This can make the role a key-value pair plays in a WeakMap clearer.

JavaScriptCopied!

let mySymbol = Symbol('mySymbol');

let myWeakMap = new WeakMap();

let obj = {
    name: 'Coding Beauty'
};

myWeakMap.set(mySymbol, obj);


console.log(myWeakMap.get(mySymbol)); // Output: object

And what are they meant for?

5. Array toReversed() method

Another new Array method to promote immutability and functional programming.

The name’s self-explanatory: give me the reversed version of my array.

Before – with reverse().

JavaScriptCopied!

const arr = [5, 4, 3, 2, 1]

const reversed = arr.reverse();

console.log(reversed); // [1, 2, 3, 4, 5]

// Original modified
console.log(arr); // [1, 2, 3, 4, 5]

Now:

JavaScriptCopied!

const arr = [5, 4, 3, 2, 1]

const reversed = arr.toReversed();

console.log(reversed); // [5, 4, 3, 2, 1]

// Original NOT modified
console.log(arr); // [1, 2, 3, 4, 5]

6. Array find from last

Sure we can already use the Array find() method to find an element in an array that passes a specified test condition. And findIndex() will give us the index of such an element.

But find() and findIndex() both start searching from the first element of the array. What if it’ll be better for us to search from the last element instead?

Here we’re trying to get the item in the array with the value prop equal to y. With find() and findIndex():

JavaScriptCopied!

const letters = [
  { value: 'v' },
  { value: 'w' },
  { value: 'x' },
  { value: 'y' },
  { value: 'z' },
];

const found = letters.find((item) => item.value === 'y');
const foundIndex = letters.findIndex((item) => item.value === 'y');

console.log(found); // { value: 'y' }
console.log(foundIndex); // 3

This works, but as the target object is closer to the tail of the array, we could make this program run faster if we use the new ES2022 findLast() and findLastIndex() methods to search the array from the end.

JavaScriptCopied!

const letters = [
  { value: 'v' },
  { value: 'w' },
  { value: 'x' },
  { value: 'y' },
  { value: 'z' },
];

const found = letters.findLast((item) => item.value === 'y');
const foundIndex = letters.findLastIndex((item) => item.value === 'y');

console.log(found); // { value: 'y' }
console.log(foundIndex); // 3

Another use case might require that we specifically search the array from the end to get the correct item. For example, if we want to find the last even number in a list of numbers, find() and findIndex() would produce a totally wrong result.

JavaScriptCopied!

const nums = [7, 14, 3, 8, 10, 9];

// gives 14, instead of 10
const lastEven = nums.find((value) => value % 2 === 0);

// gives 1, instead of 4
const lastEvenIndex = nums.findIndex((value) => value % 2 === 0);

console.log(lastEven); // 14
console.log(lastEvenIndex); // 1

Yes, we could call the reverse() method on the array to reverse the order of the elements before calling find() and findIndex().

But this approach would cause unnecessary mutation of the array, as reverse() reverses the elements of an array in place. The only way to avoid this mutation would be to make a new copy of the entire array, which could cause performance problems for large arrays.

And this beside the fact that findIndex() would still not work on the reversed array, as reversing the elements would also mean changing the indexes they had in the original array. To get the original index, we would need to perform an additional calculation, which means writing more code.

JavaScriptCopied!

const nums = [7, 14, 3, 8, 10, 9];

// Copying the entire array with the spread syntax before
// calling reverse()
const reversed = [...nums].reverse();

// correctly gives 10
const lastEven = reversed.find((value) => value % 2 === 0);

// gives 1, instead of 4
const reversedIndex = reversed.findIndex((value) => value % 2 === 0);

// Need to re-calculate to get original index
const lastEvenIndex = reversed.length - 1 - reversedIndex;

console.log(lastEven); // 10
console.log(reversedIndex); // 1
console.log(lastEvenIndex); // 4

It’s in cases like where the findLast() and findLastIndex() methods come in handy.

JavaScriptCopied!

const nums = [7, 14, 3, 8, 10, 9];

const lastEven = nums.findLast((num) => num % 2 === 0);
const lastEvenIndex = nums.findLastIndex((num) => num % 2 === 0);

console.log(lastEven); // 10
console.log(lastEvenIndex); // 4

This code is shorter and more readable. Most importantly, it produces the correct result.

7. Array with() method

Unlike the others, with() has no complementary mutating method. But once you see it in action, you’ll know that it’s the immutable approach to changing a single element.

In so many languages, you typically modify a single array element like this:

JavaScriptCopied!

const arr = [5, 4, 7, 2, 1]

// Mutates array to change element
arr[2] = 3;

console.log(arr);  // [5, 4, 3, 2, 1]

But see what we can do now, in ES2023 JavaScript:

JavaScriptCopied!

const arr = [5, 4, 7, 2, 1];

const replaced = arr.with(2, 3);

console.log(replaced);  // [5, 4, 3, 2, 1]

// Original not modified
console.log(arr);  // [5, 4, 7, 2, 1]

Final thoughts

This year was all about easier functional programming and immutability.

Indeed, the reliability and consistency that immutability brings cannot be overstated. With the rise of declarative frameworks like React and Vue as well as Redux and other libraries, we’ve seen immutable JavaScript array methods explode in popularity; it’s only natural that we see more and more of them come baked into the language as it matures.

They stole the show in 2023, just like JavaScript took over a huge chunk of the language ecosystem a while back, with many millions of developers keeping that fire burning today. Let’s see what the future holds.