The problem with Javascript modules = Everyone will be forced to run a full web server to do anything (to handle CORS restrictions). We all lose the ability to simply have a local index.html file, and have it Just Work (TM): This ability is amazing for demos, fast iteration, onboarding new devs and developing without a ton of layers of js ecosystem machinery. Deno doesn't care about retaining this level of developer…
Is CommonJS even a thing for javascript running in web browsers? Moving from CommonJS to modules shouldn't affect any running in a browser.
The problem with Javascript modules = Everyone will be forced to run a full web server to do anything (to handle CORS restrictions). We all lose the ability to simply have a local index.html file, and have it Just Work (TM): This ability is amazing for demos, fast iteration, onboarding new devs and developing without a ton of layers of js ecosystem machinery. Deno doesn't care about retaining this level of developer…
If you are same origin, you do not require CORS to use type=module. Also type=module works on HTML pages served from file:// (file:///.../index.html).
The problem with Javascript modules = Everyone will be forced to run a full web server to do anything (to handle CORS restrictions). We all lose the ability to simply have a local index.html file, and have it Just Work (TM): This ability is amazing for demos, fast iteration, onboarding new devs and developing without a ton of layers of js ecosystem machinery. Deno doesn't care about retaining this level of developer…
>
Shouldn't that be a relative path for it to actually work as you intend?
That's all well and good, but what about those of us that already have a mountain of Jest tests with mocks that aren't supported in ESM mode? https://github.com/jestjs/jest/issues/9430 I've definitely worked around my fair share of CommonJS issues but until ESM "just works" I'm slightly pained by how aggressive the tone of this article is.
Use vitest.
We're trying, we've had compatibility issues with node-canvas and our older version of graphql-js
Didn't see mention of Browserify and other bundlers after it that made CommonJS the defacto standard for client/browser libraries as well. I think the biggest miss was not making mixed mode (default) for Node do it the way webpack/babel, etc did it by default in terms of interop. I get they wanted to make it more implicit to call cjs from esm, in the end it just inhibits conversion of existing libraries as dependenci…
Every time this is mentioned, the person is heavily downvoted. But if you were here in the 2000, that's exactly what happened. In fact, this very article starts with "JavaScript, the undisputed king of web development, is being sabotaged — not by a rival language or a revolutionary new technology, but by its own baggage from the past.". That's the first sentence. Nobody wanted to work with JS, it was used to make sno…
> But if you were here in the 2000, that's exactly what happened.
That was 23 years ago.
It's an entire generation. A baby born after that point could now be working as a fully fledged adult.
> 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.
I would. Typescript is easily the best language for anything from app development to small projects and has been for years now. If you're bringing up Go/Rust, then TS has been incredibly good in that timeframe. Before that there was Pythong+Django and Ruby/RoR back when we did SSR, and Java applets or flash before that.
Does anyone have a detailed understanding of why CommonJS (and its async incarnation, AMD) were not adopted by browsers? I do much like the `import` syntax personally and its a little cleaner to read, but CommonJS and AMD were the undisputed winners of the module format until ES Modules were born. Not that I have a problem with ES Modules, I don't, however I am interested in what was so insufficient about the precedi…
To be honest, I think the AMD incarnation is a complete non-starter. It’s just such a funky, weird little thing that only makes sense because it’s a compatibility shim. Nobody wants to directly author AMD, and someone shipping a JS implementation wants to ship features that people will use directly. I mean, I guess people will directly write AMD modules, and make modules using some giant script that uses cat, but the…
+this ... AMD was just weird and clunky to use in practice... CJS bundlers were much easier to grasp by comparison, and when browserify (and those that followed) came out, it was kind of a no-brainer at the time. If ESM were finalized maybe even 2 years earlier, we'd probably be using that already for everything. I think the Node team choosing to make esm/cjs interop more difficult than what babel had been doing slowed down the switch. I get the reasons why, I just don't agree with the approach in the end. I think if they made the interop good, and declared after Node v#, it would be esm only, that would have worked out better for everyone. The risk being a kind of Python 2->3 paralysis. If the interop was good for a few versions, I don't think the friction would have been that bad. Then after 2-3 years, the switch could have been much cleaner.
Every time this is mentioned, the person is heavily downvoted. But if you were here in the 2000, that's exactly what happened. In fact, this very article starts with "JavaScript, the undisputed king of web development, is being sabotaged — not by a rival language or a revolutionary new technology, but by its own baggage from the past.". That's the first sentence. Nobody wanted to work with JS, it was used to make sno…
You’re not wrong at all.
But the parent lost complaining that JS exists at all is not really productive to a discussion about what effects JS today.
The “JS should have been something else” ship sailed a VERY long time ago.
It’s like people who go into C++ threads and complain it wasn’t rust from the start. That’s nice. But rust wasn’t there at the time.
That's all well and good, but what about those of us that already have a mountain of Jest tests with mocks that aren't supported in ESM mode? https://github.com/jestjs/jest/issues/9430 I've definitely worked around my fair share of CommonJS issues but until ESM "just works" I'm slightly pained by how aggressive the tone of this article is.
That’s mostly because of how Jest absolutely brutalizes the Require stack. It’s a problem with Jest AND CommonJS, not ES Modules. In fact it’s a very illustrative example of why CommonJS should be taken out back and shot.
Are you saying I just shouldn't have access to that part of the runtime? I've also done my fair share of `require` hacking, and it's led to things like hot reload and lazy loading for Node backends. There's a lot of value in being able to mess with that part of the stack.