ELEKS' intelligent automation: Unmatched efficiency for market leaders

ELEKS' intelligent automation transforms your business with custom data-driven tools. We streamline processes, boost productivity, and cut costs by automating complex tasks. Our tailored approach unlocks growth opportunities, freeing your team to focus on high-value tasks.

Schedule your automation consultation

Puzzle of the day

New puzzle to train your brain and test your coding understanding✨

Featured content

These coding themes are incredible

10 breathtaking themes to upgrade your dev quality of life and coding enjoyment.

1. Night Owl

Night Owl is here for all your late-night coding drills.

Easy on the eyes with a cool color palette:

Sit in a dark room and code all night long.

And there's a different variant, for those who hate the italics:

And when the morning comes around again:

No italics:

2. Atom One Theme

My absolute favorite.

The signature color scheme from the Atom editor that GitHub killed.

I find dark themes annoying in the day with bright light all around me -- so thankfully this also has a light counterpart.

3. GitHub Theme

Speaking of GitHub: Their official theme for VS Code:

Look familiar? No? How about this:

Reduce the font size and change it to Consolas and you have a perfect replica of the theme at github.com.

The 5 most game-changing JavaScript features from ES11

JavaScript has come a long way in the past 10 years with brand new feature upgrades in each one.

Let’s take a look at the 5 most significant features that arrived in ES11; and see the ones you missed.

1. Modularization on the fly: Dynamic imports

ES11 was the awesome year when import could now act as function, like require().

An async function.

Keeping imports at the top level was no longer a must; We could now easily resolve the module's name at compile time.

Loading modules optionally and only when needed for high-flying performance...

async function asyncFunc() {
  if (condition) {
    const giganticModule = await import('./gigantic-module');
  }
}

Loading modules based on user or variable input...

import minimist from 'minimist';

const argv = minimist(process.argv.slice(2));

viewModule(argv.name);

async function viewModule(name) {
  const module = await import(name);
  console.log(Object.keys(module));
}

It’s also great for using ES modules that no longer support require():

// ❌ require() of ES modules is not supported
const chalk = require('chalk');
console.log(chalk.blue('Coding Beauty'));

(async () => {
  // ✅ Runs successfully
  const chalk = (await import('chalk')).default;
  console.log(chalk.blue('Coding Beauty'));
})();

2. Promise.allSettled()

But we already had Promise.all() to wait for all the Promises in a list to resolve?

const responses = await Promise.all([
  fetch(endpoint1),
  fetch(endpoint2),
]);

So what was the point of this, right?

But no, allSettled() turns out to be quite different from all().

Promise.all(): If even a single Promise in the list fails, everything fails.

But you see the problem: We’d have no idea if one failed and which succeeded.

What if you want to retry the failed errors until they do succeed? You’re stuck.

Until you turn to Promise.allSettled():

❌ Before ES11:

// ❌ Promise.all()
async function fetchData() {
  const apiUrl = 'api.tariibaba.com';
  const endpoint1 = `${apiUrl}/route1`;
  const endpoint2 = `${apiUrl}/route2`;

  try {
    const responses = await Promise.all([
      fetch(endpoint1),
      fetch(endpoint2),
    ]);
  } catch (err) {
    // ❌ Which failed & which succeeded? We have no idea
    console.log(`error: ${err}`);
  }
  // ...
}

✅ After ES11:

Promise.allSettled(): Wait for every Promise to fail or resolve.

// ✅ Promise.allSettled()
async function fetchData() {
  const apiUrl = 'api.tariibaba.com';

  const endpoint1 = `${apiUrl}/route1`;
  const endpoint2 = `${apiUrl}/route2`;

  try {
    const promises = await Promise.allSettled([
      fetch(endpoint1),
      fetch(endpoint2),
    ]);
    const succeeded = promises.filter(
      (promise) => promise.status === 'fulfilled'
    );
    const failed = promises.filter(
      (promise) => promise.status === 'rejected'
    );
    // ✅ now retry failed API requests until succeeded?
  } catch (err) {
    // We don't need this anymore!
    console.log(`error: ${err}`);
  }
  // ...
}

Thanks for taking the time to read today’s issue.

Don’t let the bugs byte,
The Coding Beauty team