Thursday, November 9, 2023

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:

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:

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:

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.

Friday, April 21, 2023

Voting Republican in 2023 - Supporting the US version of Al Qaeda aka MAGA

There were 56 Founding Fathers who signed the Declaration of Independence1At least 12 of them were plantation owners and slaveholders2Many of the major Founding Fathers owned numerous slaves, such as George Washington, Thomas Jefferson, and James Madison3Others owned only a few slaves, such as Benjamin Franklin3And still others married into large slave-owning families, such as Alexander Hamilton3.  

The mindset, wealth, and even direct descendants of those people are a part of the United States, and the most extreme of them have taken over the Republican party (at least in Congress, where it matters most). Please don't ignore those extremists the next time you go vote. Even if the Republican party once represented your values (and it may again someday), right now, I find it hard to see a fundamental difference between Al-Qaeda and the "MAGA" leadership like Marjorie Taylor Greene (harassing survivors of shootings, having an affair, lying, etc.), Jim Jordan (violating subpoenas, enabling molestation of his students, practicing law without a license, lying, etc.), Chip Roy, and even whole Governors like Ron DeSantis and Kristi Noem.

Even if your state isn't one being led/controlled by those extremists, by supporting the Republican party, you increase the odds they gain and hold enough power to fix the rules so they can keep that power, shut the democratic process further below a functioning level and further self-deal. Even if 95% of the Republican leadership weren't an issue, that 5% is loud and presently telling the weakest Speaker-of-the-House (Kevin McCarthy) in our history; how they want things to be. The people aren't a concern, just the attention.

We have to be honest with ourselves and each other about the fact that there are plenty of adults who have matured in body but not in mind. Much of the time, they blend in and are indistinguishable from the actual grown-ups, but their refusal to see a reality they don't like is their calling card. When you push them on those realities, you'll get excuses, projection, lies, and outright denial. Our culture has recently developed a title for the most immature of them all. They're now called "Karens," and gender isn't a factor, as exemplified here.

These people are unable to be honest with themselves. I suspect mental laziness is a factor also, but I'm not sure how you'd identify those who aren't honest with themselves because they don't care [and are thus mentally lazy] and those who "can't" be honest with themselves due to psychological factors.

I once believed the 2nd amendment was there to protect "the people" from the government. I didn't appreciate the hate and ignorance that existed then (far worse before the Internet existed.) I now realize that for the people to remain safe, the government must be able to handle extremists who want to take freedom from those they "feel" don't deserve it (like woman and those of color.) US individual gun-ownership is already WAY beyond the ability to keep the government in checks. Now the government needs to protect the people from themselves in many cases.

We must vote, and we must account for the character of the people we vote for because they may choose our fate. Politics isn't a thing that exists separate from us or that's out of our control. The more we vote, the more our views will be reflected unless we allow those who don't see a vote as important to take over.

Freedom is not free and we are all responsible for paying our portion if we want to keep it; something that's cost more lives than any of us can comprehended and won't appreciate until it's gone.

Here's another take: 

For those who don't know me and are reading this with no other context; know that I'm a disabled veteran of the US Marine corps. I've been near-death multiple times, have had to learn to walk and live again, and I have been left to die by the V.A. (and the votes that allow it to remain as it is). I have 3 children I'd give my life for, am a responsible gun-owner. In the past, I did identify more with Republican "values". That has changed since it's clear they have none. It's not about "parties". It's about putting people in power that actual care and will do their job, not stage theatrics for Fox (who has now admitted to lying, to the tune of >$780,000,000) or try to overthrow the republic.

Thursday, March 9, 2023

From CommonJS/Require to ES modules the easy way


When Node.js was first conceived, jQuery as a community; had embraced the AMD pattern and RequireJS in particular. Node.js was designed to run JavaScript code outside of a web browser, and as such, it needed a module system that was optimized for server-side development. CommonJS was the solution that was chosen because it fit the requirements of the Node.js ecosystem at the time.. CommonJS was the resulting solution and has been used in Node.js since v0.x. 

Meanwhile, the browser has continued to evolve sought to address the need that RequireJS was filling. With ECMAScript 6 (ES6), ECMAScript modules (ESM) were introduced.

ESM is a newer module format that is part of the ECMAScript language specification, and it provides a standard way to define modules in JavaScript. ESM provides a number of benefits over CommonJS, including better performance, improved compatibility with tooling and bundlers, and better support for static analysis and tree-shaking.

Since the release of ECMAScript 6, many JavaScript environments have added support for ESM, including Node.js, web browsers, and many other runtimes.

FAQ First

1. What is CommonJS?

CommonJS module system is the default module system within the NodeJS ecosystem. CommonJS modules are the original way to package JavaScript code for Node.js. In terms of the loading paradigm for CommonJS, modules are loaded synchronously and are processed in the same order that the JavaScript runtime locates them. CommonJS provides require()

2. What are ESM?

The ES module usage format is the official standard to write JavaScript for maximum reusability and is what most web browsers natively support and Node.JS has fully supported since 12.x (experimental support as early as 9.x.)

3. What are major difference between CommonJS and ESM?

  • CommonJS is synchronous whereas ES is asynchronous
  • CommonJS supports only runtime resolution whereas ES supports both parse time and runtime
  • ESM support interoperability whereas CommonJS do not
  • CommonJS is the original standard in Node.js whereas ES recently achieved stable support and has been in in browsers for 5+ years
  • Common JS uses require() and ESM uses import export

4. What are the benefits of CommonJS?

CommonJS is the default standard and is supported in all Node.js versions. It is resolved at Runtime and has a wide amount of Dev support since it has been there since the beginning of Node.JS

5. Does Node.js use CommonJS?

Yes, CommonJS was the default Standard for module inclusion. 

6. Does Node.js use ES Modules (ESM)?

Yes, ESM is fully supported since Node.js 12.x

7. Is CommonJS going away?

There is no sunset date on CommonJS, but it's not native to ecmascript as ESM is so it might be expected to be deprecated at some point in favor of ESM and, it is worth noting that many developers are now migrating to ESM, especially for new projects or where the benefits of ESM outweigh the costs of migration.

Commonjs/Requirejs/AMD pattern

function foo() {}

modules.exports = foo;


foo = require('foo');

ECMAscript modules (ESM/modules)

export function foo() {}


// An https url can also be provided
import { foo } from "foo.mjs";

For some advanced tricks, check out Data URLs.

Package.json changes and file extensions

When using require('foo'); we are depending on CommonJS, which is well-established in Node.js since v0.1.0. As of node v9.x, it has been possible to enable an experimental flag to begin using ESM. As of Node.js v12.x, ESM are natively supported. The overall migration path from CommonJS to ESM can take multiple forms. To provide compatibility and keep longterm changes to a minimum, the following behaviors exist:
  • .js file extension is assumed to implement CommonJS
  • .mjs file extension is assumed to implement ESM
  • .cjs file extension is assumed to implement CommonJS
  • package.js can include { "type": "module" } to indicate .js file extension will contain ESM. With this, there is no longer a need to use the .mjs extension
  • Node can be run with --experimental-specifier-resolution=node to tell node to support CommonJS and ESM BOTH in .js files


If you embrace ESlint, know that definitions must be based on es2021 (es12) or newer. Previous ecmascript versions require other approaches (like --experimental node.js flags.)


Starting from Node.js 14.13.0 and higher, it's possible to import CommonJS modules using the ES module syntax (import/export). In other words, you can use the import statement to import objects from a CommonJS module that exports using module.exports.

For example, if you have a CommonJS module foo.js that exports an object like this: 

module.exports = { a: 1, b: 2, c: 3 };

You can import this object using the ES module syntax like this:

import foo from './foo.js'; console.log(foo.a); // Output: 1

Note that you need to use a file extension of .mjs for the importing file (see above) if you're using ECMAScript modules. However, if you prefer to use the .js file extension for both CommonJS and ECMAScript modules, you can add "type": "module" to your package.json file OR run Node.js with --experimental-specifier-resolution=node 

The FAQ and other bits where borrowed from:

Thursday, February 2, 2023

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?