CommonJS is hurting JavaScript

I think the historical context is necessary. At the time, Rails was a thing and python was taking server space from Java, PHP, etc. They weren't looking to those languages as standards, but rather as languages that were likely to have similar problems.

> and its async incarnation, AMD

A bare-bones implementation of AMD could be put together with less than a kilobyte of JavaScript (this is what we used at Mozilla for a minute circa 2012). Meanwhile, the ECMAScript folks were working on ES6, which was going to have a module system. Why would the browser build in support for a highly-opinionated system that you could implement yourself so trivially, all while a TC39-blessed standard was in the works?

> what I "imagine" browsers doing with CommonJS is making the `require` calls async in the background (IE non visible to developers) so they can resolve the modules then parse the code

That's not possible. You need to run the code to know what's being required: if I call `require('./' + getModuleName())`, you don't know what's being required until `getModuleName()` is evaluated. So you actually need to start running the JS. You need to pause execution of the code calling `require()` (a la `alert()`), and then you can download and parse the required module. When the file is downloaded, you can parse and execute the imported module. Each file would need to be downloaded/parsed/executed _synchronously_ in the order that each `require()` happens in: it's only async in so far as the JS pauses execution and picks up later.

> This isn't terribly different from how import statements work today.

Not so. You can find and resolve `import` statements (note: not `import()` calls, though these return Promises) without executing a JS file. You can parse the imports out of a file in one pass and fetch/parse/repeat for each import in the dependency tree before anything starts executing. Since "native" imports are static and declarative, you can resolve all of them without ever executing any code. And any dynamic imports return promises that the programmer needs to explicitly handle the behavior of at runtime.

> just improve the existing format

1. You'd have to kill dynamic imports (passing anything other than a string literal to `require()`, which would be impossible to do without breaking compatibility and couldn't be polyfilled.

2. AMD allowed a callback syntax for `require()` (it came out years before promises), which is cumbersome. Adding promises later would be challenging and leave technical debt.

[flagged]

> I've yet to met anybody who knows Python/Ruby/C#/Java/Rujst/Go and JS to chose JS outside of the web. Because there, we have the choice.

Pleased to meet you! Isomorphic code bases are a case to use a single language, which before WASM, is Javascript & Typescript. I may prefer to use something different with WASM, which has even more interoperability than JS, becoming a bigger part of the ecosystem, but so far it would be Assemblyscript to more easily migrate my existing codebase. Assemblyscript has a Garbage Collector, so I may choose Rust or Zig if I don't want the GC. Rust probably has the most momentum, so despite the complexities, verbosity, & loss of productivity working with Rust, that may be a better choice when working with WASM. I would prefer Zig over Rust & Assemblyscript over both in cases of app development...but breadth & depth of the ecosystem matters.

I wouldn't touch PHP, Python, Ruby if I had a between using Typescript...as PHP, Python, & Ruby lack a decent static type system.

> Nobody wanted to work with JS, it was used to make snowflakes on your home page on Xmas at best.

I disagree. Javascript is a prototype based language, which provided opportunities for composition over inheritance. JS supported closures from it's beginning while other popular languages did not (well Ruby had limited support for closures). Inheritance & other OO concepts now considered harmful were prevalent with Java, C#, Ruby, Python, etc.

Sure, we could have used LISP instead, but for some reason LISP did not gain traction. JS was the closest programming to LISP which had popular appeal.

I suggest that JS changed the general programming ecosystem in profoundly positive ways & I, for one, preferred developing in JS over the other popular alternatives when I could.

To further bolster the case for JS, Typescript was built as an extension on top of JS, proving you can have the dynamic prototype based runtime with a powerful static type system.

I just tried this and got "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at file:///home/**.js. (Reason: CORS request not http)" in firefox