Understanding the implications of return await in ecmascript

In ECMAScript, an async function always wraps the returned value in a Promise. If you return a value, it's equivalent to returning Promise.resolve(value). If you throw an error, it's akin to returning Promise.reject(error). When you await a Promise, the function's execution is paused until the Promise is settled.

Consider the following code inside an async function:

javascript
return await someAsyncFunction();

This will pause the execution of the current function until someAsyncFunction() resolves, and then immediately return the resolved value. However, since async functions automatically wrap returned values in Promises, you can simply write:

javascript
return someAsyncFunction();

In this case, someAsyncFunction() is returned directly. The Promise returned by someAsyncFunction() will be returned by your function as-is. The JavaScript engine doesn't need to create an additional microtask to resolve the await, which it would do in the return await case. Here's why you might see a performance difference:

1. Microtask Queue Management: Every time you await a Promise, the engine adds a microtask to the queue for when the Promise resolves. Using return await adds an unnecessary microtask because you could return the Promise directly, and the calling code will await it anyway.

2. Stack Trace Generation: When you use await, the engine keeps track of the function from which it was called for the purpose of generating stack traces if an error is thrown. This can add overhead compared to returning a Promise directly, which doesn't require the engine to manage the stack in the same way.

3. Optimization: JavaScript engines can optimize return someAsyncFunction(); more effectively than return await someAsyncFunction(); because the former has less complexity for the engine to analyze and optimize.

The performance penalty of return await is generally quite small and may not be noticeable in everyday code. However, it's a good practice to avoid unnecessary await for the reasons above, especially in performance-critical code or in loops.

Here’s an example where return await does make sense and has no performance penalty:

javascript
async function foo() {
  try {
    return await someAsyncFunction();
  } catch (error) {
    // Error handling
  }
}

In the example above, return await is necessary to catch any promise rejections from someAsyncFunction() within the foo function's try block. Without await, a rejected promise would not be caught by try/catch, and the error handling would not work as intended.

Reasons NOT to use ESlint (sarcasm)

If you're looking to add chaos and confusion to your coding workflow, look no further than ESLint. This tool is designed to ensure that your code meets a certain set of standards and is free of any potential errors. But why would anyone want to use such a bothersome program? Here are just a few of the many reasons why you should avoid ESLint at all costs. Who needs organized and consistent code anyway? Who needs to save time by automatically catching syntax and formatting errors before they even reach the browser? And let's not forget about the joy of scrolling through hundreds of lines of messy, unreadable code. Who needs to be productive and efficient, right?

First of all, who has time to waste on pesky linting errors? It's much more fun to spend your valuable coding time debugging runtime issues. Not to mention, the rules that ESLint forces you to abide by are often arbitrary and outdated. Who wants to spend their days writing code that conforms to the stylistic preferences of others? Furthermore, the amount of time it takes to even set up ESLint can be a bit overwhelming. It might seem like a small task, but it can quickly become tedious and time-consuming.

Second, ESLint can be incredibly tedious to work with. It often requires you to spend hours hunting down small typos and other minor errors that could be easily overlooked. Not to mention, the linting rules can be difficult to decipher and often require you to make numerous adjustments to your code in order to comply. This can be incredibly time-consuming and ultimately leave you with code that doesn’t even meet the standards that ESLint was meant to enforce. Clearly, using ESLint is for the weak-hearted. It's for those who value productivity, consistency, and a well-organized codebase. But if you're like me, you'd much rather spend hours trying to decipher and fix code that could have been caught by a simple linter. So go ahead, do yourself a favor, and steer clear of the temptations of ESLint. Your code will thank you for it.

The final nail in the coffin is the fact that ESLint often introduces unexpected bugs into your code. Since the program is designed to catch coding errors, it can be difficult to figure out why an error is occurring, especially if you’re unfamiliar with the program. Furthermore, you can’t even trust ESLint to catch all of the errors in your code. This means that you may find yourself spending even more time troubleshooting and hunting down errors that the program missed. So, why bother using it in the first place? Furthermore, who needs the peace of mind that comes with knowing your code adheres to a standardized style guide, or the ability to easily catch potential bugs and security vulnerabilities before they become a problem? Who wants to work in a team where everyone follows the same code conventions, making collaboration smoother and conflicts less frequent?

In conclusion, ESLint is clearly not worth the headache. If you value your short-term sanity, you should avoid it. In the unlikely chance you like to sleep soundly, knowing your code is as solid as possible, you could look into it. What if sanity is overrated though?