6 ms·

> Notice I have changed the extension from .js to .mjs. Don’t worry, either extension can be used. And you are going to run into issues with either choice As s

> Notice I have changed the extension from .js to .mjs. Don’t worry, either extension can be used. And you are going to run into issues with either choice As someone that has used module systems from dojo to CommonsJS to AMD to ESM with webpack and esbuild and rollup and a few others thrown in ... this statement hits hard.

bubblyworld 1y ago
Yeah, modules in jsland are just trauma... now we have import maps in the browser too. Let's see what kinds of fun we can have with those.
- ajayvk 1y ago
  A recent improvement in import map support in the browser https://shopify.engineering/resilient-import-maps https://shopify.engineering/resilient-import-maps
  - hdjrudni 1y ago
    The interesting bit is this: https://philipwalton.com/articles/cascading-cache-invalidation/ https://philipwalton.com/articles/cascading-cache-invalidati... Without that one sentence, the entire article is moot because I thought bundlers solved the problem. I haven't thought about that in years. I didn't realize it had been solved. Browser support looks pretty good. I guess now I have to figure out how to get this to play nice with Vite and TypeScript module resolution.... and now it's starting to hurt my brain again, great.
SCLeo 1y ago
Yeah, the commonjs to esm transition has been the python 2 to python 3 transition of JavaScript, except the benefits are limited (at least compared to the hassle created). There are many libraries that have switched to esm only (meaning they don't support commonjs), but even today, the best way to find the last commonjs version of those libraries is to go to the "versions" tab on npm, and find the most downloaded version in the last month, and chances are, that will be the last commonjs version. Yes, in a vacuum, esm is objectively a better than commonjs, but how tc39 almost intentionally made it incompatible with commonjs (via top-level awaits) is just bizarre to me.
- eyelidlessness 1y ago
  It had to be incompatible with CommonJS regardless of top level await. There is no imaginable scenario where browsers would ship a module system with synchronous request and resolution semantics. A module graph can be arbitrarily deep, meaning that synchronous modules would block page load for arbitrarily deep network waterfalls. That’s a complete non-starter. Given that, top-level await is a sensible affordance, which you’d have to go out of your way to block because async modules already have the same semantics. Recently, Node has compromised by allowing ESM to be loaded synchronously absent TLA, but that’s only feasible because Node is loading those models from the file system, rather than any network-accessible location (and because it already has those semantics for CJS). That compromise makes sense locally, too. But it still doesn’t make sense in a browser.
- apatheticonion 1y ago
  Bundler engineer here. ESM is great when it comes to build-time optimisations. When a bundler runs into CJS code it literally deopts the output to accommodate - so from that side it's amazing. But also, there's a special place in hell for the people that decided to add default exports, "export * from" and top level await. Commonjs is also very weird as a "module" instance can be reassigned to a reference of another module module.exports = require('./foo') and there's no way to do this in ESM (for good reason, but also no one warned us). In fact major projects like React use CJS exports and the entire project cannot be optimized by bundlers. So, rather than porting to ESM, they created a compiler LOL
  - pwdisswordfishz 1y ago
    > But also, there's a special place in hell for the people that decided to add […] top level await. There is also a special place in extra-hell for those who export a function named 'then'.
    - deleted 1y ago
      [deleted]
    - sirsuki 1y ago
zackify 1y ago
That’s why everyone should be using bun.sh
- VWWHFSfQ 1y ago
  Web dev is full of "you should just use some other tool that I like" I'm convinced that 90% of the JavaScript ecosystem only exists to build tools for itself. It's tools all the way down
  - wild_egg 1y ago
    For those of us forced to be in the JS ecosystem, finally having a runtime that Just Works has been great. Bun has replaced a massive number of tools and dependencies from our stack and really counteracted the tooling explosion that we were forced into with node.
    - zackify 1y ago
      Imagine complaining that a language has so many users and projects so it sucks. Exactly, bun is killer. The test runner is extremely fast. I can build apps with 1-5 total dependencies and everything just works, and works incredibly fast.
    - diggan 1y ago
      > really counteracted the tooling explosion that we were forced into with node Isn't this more-or-less a self-inflected wound? Who forced you into working with node?
      - edoceo 1y ago
        $JOB
      - Defletter 1y ago
        In our case, it's not so much being forced to use Bun, but rather that Bun is in real terms infinitely more convenient than lower-level languages. Firstly, even the most novice of novices tend to have a passing familiarity with JS/TS, whereas this is not true for C/Zig/Rust/etc, so it's easier for people to contribute to our projects. Bun also provides so many things for free, statically, and cross platform. You want a TCP server? A websocket server? SQLite database? You want to include static assets? You want to generate static assets at compile time? Etc? Bun provides it. Attempting to replicate even a modicum of this in lower-level languages can be a real struggle. Rust is definitively the least-worst in this respect because there's been a concerted effort by the community to provide stable packages that do most things. But Rust is a complicated and unapproachable language. Using other low-level languages like C/Zig, and you immediately run into issues of libraries and static linking. And even if you find a library, its documentation is either lacklustre or outright missing (looking at you libuv and libxev respectively). The amount of manual setup and third-party builds-system finagling just to: 1) run a TCP server; 2) fetch data over HTTP; 3) do both of these using a single event loop (no separate threads); 4) use SQLite for storage; and 5) have all this produce a single self-contained executable. Yet I cannot understate how trivial this is with Bun.
BostonFern 1y ago
Won’t .esm.js work?
goodthink 1y ago
I recently found out that the Function object will compile any javascript you care to feed to it. At runtime! new Function('class MyClass { ...}; return MyClass') My system does not allow for "imports". No npm etc. So this is a bit of a lifesaver for me. I realize in js land it may not be as useful but it is pretty handy.

bubblyworld 1y ago

Yeah, modules in jsland are just trauma... now we have import maps in the browser too. Let's see what kinds of fun we can have with those.

ajayvk 1y ago
A recent improvement in import map support in the browser https://shopify.engineering/resilient-import-maps https://shopify.engineering/resilient-import-maps
- hdjrudni 1y ago
  The interesting bit is this: https://philipwalton.com/articles/cascading-cache-invalidation/ https://philipwalton.com/articles/cascading-cache-invalidati... Without that one sentence, the entire article is moot because I thought bundlers solved the problem. I haven't thought about that in years. I didn't realize it had been solved. Browser support looks pretty good. I guess now I have to figure out how to get this to play nice with Vite and TypeScript module resolution.... and now it's starting to hurt my brain again, great.

SCLeo 1y ago

Yeah, the commonjs to esm transition has been the python 2 to python 3 transition of JavaScript, except the benefits are limited (at least compared to the hassle created). There are many libraries that have switched to esm only (meaning they don't support commonjs), but even today, the best way to find the last commonjs version of those libraries is to go to the "versions" tab on npm, and find the most downloaded version in the last month, and chances are, that will be the last commonjs version. Yes, in a vacuum, esm is objectively a better than commonjs, but how tc39 almost intentionally made it incompatible with commonjs (via top-level awaits) is just bizarre to me.

eyelidlessness 1y ago
It had to be incompatible with CommonJS regardless of top level await. There is no imaginable scenario where browsers would ship a module system with synchronous request and resolution semantics. A module graph can be arbitrarily deep, meaning that synchronous modules would block page load for arbitrarily deep network waterfalls. That’s a complete non-starter. Given that, top-level await is a sensible affordance, which you’d have to go out of your way to block because async modules already have the same semantics. Recently, Node has compromised by allowing ESM to be loaded synchronously absent TLA, but that’s only feasible because Node is loading those models from the file system, rather than any network-accessible location (and because it already has those semantics for CJS). That compromise makes sense locally, too. But it still doesn’t make sense in a browser.
apatheticonion 1y ago
Bundler engineer here. ESM is great when it comes to build-time optimisations. When a bundler runs into CJS code it literally deopts the output to accommodate - so from that side it's amazing. But also, there's a special place in hell for the people that decided to add default exports, "export * from" and top level await. Commonjs is also very weird as a "module" instance can be reassigned to a reference of another module module.exports = require('./foo') and there's no way to do this in ESM (for good reason, but also no one warned us). In fact major projects like React use CJS exports and the entire project cannot be optimized by bundlers. So, rather than porting to ESM, they created a compiler LOL
- pwdisswordfishz 1y ago
  > But also, there's a special place in hell for the people that decided to add […] top level await. There is also a special place in extra-hell for those who export a function named 'then'.
  - deleted 1y ago
    [deleted]
  - sirsuki 1y ago

zackify 1y ago

That’s why everyone should be using bun.sh

VWWHFSfQ 1y ago
Web dev is full of "you should just use some other tool that I like" I'm convinced that 90% of the JavaScript ecosystem only exists to build tools for itself. It's tools all the way down
- wild_egg 1y ago
  For those of us forced to be in the JS ecosystem, finally having a runtime that Just Works has been great. Bun has replaced a massive number of tools and dependencies from our stack and really counteracted the tooling explosion that we were forced into with node.
  - zackify 1y ago
    Imagine complaining that a language has so many users and projects so it sucks. Exactly, bun is killer. The test runner is extremely fast. I can build apps with 1-5 total dependencies and everything just works, and works incredibly fast.
  - diggan 1y ago
    > really counteracted the tooling explosion that we were forced into with node Isn't this more-or-less a self-inflected wound? Who forced you into working with node?
    - edoceo 1y ago
      $JOB
    - Defletter 1y ago
      In our case, it's not so much being forced to use Bun, but rather that Bun is in real terms infinitely more convenient than lower-level languages. Firstly, even the most novice of novices tend to have a passing familiarity with JS/TS, whereas this is not true for C/Zig/Rust/etc, so it's easier for people to contribute to our projects. Bun also provides so many things for free, statically, and cross platform. You want a TCP server? A websocket server? SQLite database? You want to include static assets? You want to generate static assets at compile time? Etc? Bun provides it. Attempting to replicate even a modicum of this in lower-level languages can be a real struggle. Rust is definitively the least-worst in this respect because there's been a concerted effort by the community to provide stable packages that do most things. But Rust is a complicated and unapproachable language. Using other low-level languages like C/Zig, and you immediately run into issues of libraries and static linking. And even if you find a library, its documentation is either lacklustre or outright missing (looking at you libuv and libxev respectively). The amount of manual setup and third-party builds-system finagling just to: 1) run a TCP server; 2) fetch data over HTTP; 3) do both of these using a single event loop (no separate threads); 4) use SQLite for storage; and 5) have all this produce a single self-contained executable. Yet I cannot understate how trivial this is with Bun.

BostonFern 1y ago

Won’t .esm.js work?

goodthink 1y ago

I recently found out that the Function object will compile any javascript you care to feed to it. At runtime! new Function('class MyClass { ...}; return MyClass') My system does not allow for "imports". No npm etc. So this is a bit of a lifesaver for me. I realize in js land it may not be as useful but it is pretty handy.