5 ms·

Bun’s DX is pretty unprecedented in this space, and most of my use cases are now covered / not causing Bun to crash (when actually using run-scripts with `bun r

Bun’s DX is pretty unprecedented in this space, and most of my use cases are now covered / not causing Bun to crash (when actually using run-scripts with `bun run`). Meanwhile, I can’t configure node to not require extensions on import, nor have tsc configured to automatically add .js extensions to its compiled output, without adding on a bundler… although native TypeScript support would remedy this nit quite a bit, I can’t imagine the user experience (or performance) to match Bun’s when it reaches stable.

spankalee 2y ago
Extensions should be required. It's not possible to do path searches over the network like you can on local disk, and network-attached VMs, like browsers, are a very, very important runtime for JavaScript.
- samtheprogram 2y ago
  That makes sense. I guess since using .js for the relevant imports just works in TypeScript I should be happy then…
- leipert 2y ago
  Also performance. foo could mean foo/index.js, foo.js at the minimum. So you have 2x the lookups. Oh no, wait we also potentially have mjs, cjs, jsx, ts and tsx. So 12 times the stat checking for each import.
  - simlevesque 2y ago
    > foo could mean foo/index.js, foo.js at the minimum. So you have 2x the lookups. Only in the worst case. If it's foo.js there's only one lookup. > Oh no, wait we also potentially have mjs, cjs, jsx, ts and tsx. So 12 times the stat checking for each import. Again, you're only taking into account the worst case.
- pfg_ 2y ago
  Fortunately, code is generally bundled for browsers to reduce the number of network requests and total size of downloads. And node has access to the filesystem, so it can do path searches just fine if it wants to support existing code.
  - WorldMaker 2y ago
    You probably don't need a bundler in the browser anymore. We're not yet to the point that is a popular "mainstream" opinion, but between massive improvements in browser connection handling (HTTP 1.1 connection sharing actually works in more places, HTTP/2+) and very good ESM support in browser's well optimized preloaders and caching engines (which can sometimes reduce download size much better than all-or-none bundles can, sure the trade-off is network requests but we are in a good place to take that trade-off), we're at an exciting point where there is almost never a need to bundle in development environments, and it is increasingly an option to not bundle in production either. It is worth benchmarking today (I can't tell you what your profiler tools will tell you) if you are really gaining as much from production bundles as you think you are. Not enough people are running those benchmarks, but some of them may already be surprised. The Developer Experience of unbundled ESM is great. Of course you do need to do things like always use file extensions. But those aren't hard changes to make, worth it for the better Developer Experience, and if it can help us start to wean off of mega-bundler tools as required production compile time steps.
    - tubs 2y ago
      Meh. Even with h3 I still see more gains from reducing network requests than most other attempts I try. (One day s3 will support multiple ranges per request, if I wish hard enough).
- silverwind 2y ago
  Yeah, besides that, leaving out the extension also creates ambiguity when the same filename exists with multiple file extensions.
hackandthink 2y ago
"nor have tsc configured to automatically add .js extensions to its compiled output" It seems to be the default now: $echo 'console.log("test")' > t.ts $ tsc t.ts $ ls t.js t.ts $ node t.js test
- boromisp 2y ago
  What they probably meant was writing 'import "file.ts"' and have tsc emit 'import "file.js"'. https://github.com/microsoft/TypeScript/issues/49083 https://github.com/microsoft/TypeScript/issues/49083
  - WorldMaker 2y ago
    Given the context of Node here will allow experimental type-stripping and will not be doing things like import rewriting, Typescript's decision here to focus on "users write .js in imports because that's how the type-stripped file should look" seems like the right call to me. Less work for a type-stripper because Typescript can already check if there is a .ts or .d.ts file for you if you use .js imports everywhere.
IshKebab 2y ago
> unprecedented Well except for Deno...
- pas 2y ago
  Bun started with compatibility with NodeJS as a primary goal, whereas for Deno it took a while to be able to import npm stuff. (Of course there are fun WTF[0] errors with Bun, and I only tried Deno before the npm import feature landed.) [0] https://github.com/oven-sh/bun/issues/11420 https://github.com/oven-sh/bun/issues/11420
k__ 2y ago
Bun is pretty awesome. However, the node:crypto module still doesn't work 100%. So, I can't use it yet.
- tossandthrow 2y ago
  The parallel implementation they do uncovers a number of unexpected behaviors in the node implementation.
  - k__ 2y ago
    I see. I just tried to sign some data with an RSA key, and the results differed in Node and Bun.
oblio 2y ago
Isn't Bun too raw? It's built with Zig, which hasn't even hit 1.0.
- laxis96 2y ago
  Probably had to stay in the oven a bit longer... Jokes apart, Zig is moving forward a lot which is why it's not 1.0 yet, but it doesn't mean you can't write safe and performant applications right now. Zig is also a rather simple and straightforward language (like C) and has powerful compile-time code generation (like C macros, but without the awful preprocessor).
  - oblio 2y ago
    I'm more worried about compilation or stdlib bugs. In theory you can do lots of things with lots of things, but in practice there are all sorts of hidden limitations and bugs that tend to be noticed once a software product is past 1.0 and has been out in the wild for half a decade or more.
- jokethrowaway 2y ago
  You still get segmentation faults. My biggest complain with bun is not having enough safety. If you use frameworks written for node memory usage is very high and performance is meh. If you use frameworks written for bun they smoke anything on node. I'd definitely move over, just to get rid of the whole TypeScript / cjs / esm crap, but: 1. frontend support is poor (next.js / solid.js - I can't run anything fully on bun) 3. I still need to rewrite my backend app from a node.js framework to a bun one 4. for backend development the javascript ecosystem is losing the crown: if I wanted something safe I'd just write it in Rust (TS allows any random developer to write crap with any in it and it validates), if I'm doing something AI related I'd probably need python anyway and fastapi is not half bad
  - tossandthrow 2y ago
    We use Bun in production for the entire stack and has done since v1 - only with minor hikups, that all trvivially has been fixed. DX is great! We use vite react ts, yoga, and prisma.
WuxiFingerHold 2y ago
I like Bun a lot, but Deno is (still) the more mature, stable, capable (e.g. stable workers, http2) and depending on the use-case more performant option (V8 > JSC). DX and tooling is top-notch. Deno can perform typchecking, btw. They bundle the TSC IIRC. Bun is the hype, but Deno is currently clearly the better option for serious endevours. Still, the vision and execution of Bun is impressive. Good for us devs.
XCSme 2y ago
I tried Bun twice, months apart, it never worked for me on Windows, failing to run "bun install": https://github.com/search?q=repo%3Aoven-sh%2Fbun+bun+install&type=issues https://github.com/search?q=repo%3Aoven-sh%2Fbun+bun+install...
deleted 2y ago
[deleted]

spankalee 2y ago

Extensions should be required. It's not possible to do path searches over the network like you can on local disk, and network-attached VMs, like browsers, are a very, very important runtime for JavaScript.

samtheprogram 2y ago
That makes sense. I guess since using .js for the relevant imports just works in TypeScript I should be happy then…
leipert 2y ago
Also performance. foo could mean foo/index.js, foo.js at the minimum. So you have 2x the lookups. Oh no, wait we also potentially have mjs, cjs, jsx, ts and tsx. So 12 times the stat checking for each import.
- simlevesque 2y ago
  > foo could mean foo/index.js, foo.js at the minimum. So you have 2x the lookups. Only in the worst case. If it's foo.js there's only one lookup. > Oh no, wait we also potentially have mjs, cjs, jsx, ts and tsx. So 12 times the stat checking for each import. Again, you're only taking into account the worst case.
pfg_ 2y ago
Fortunately, code is generally bundled for browsers to reduce the number of network requests and total size of downloads. And node has access to the filesystem, so it can do path searches just fine if it wants to support existing code.
- WorldMaker 2y ago
  You probably don't need a bundler in the browser anymore. We're not yet to the point that is a popular "mainstream" opinion, but between massive improvements in browser connection handling (HTTP 1.1 connection sharing actually works in more places, HTTP/2+) and very good ESM support in browser's well optimized preloaders and caching engines (which can sometimes reduce download size much better than all-or-none bundles can, sure the trade-off is network requests but we are in a good place to take that trade-off), we're at an exciting point where there is almost never a need to bundle in development environments, and it is increasingly an option to not bundle in production either. It is worth benchmarking today (I can't tell you what your profiler tools will tell you) if you are really gaining as much from production bundles as you think you are. Not enough people are running those benchmarks, but some of them may already be surprised. The Developer Experience of unbundled ESM is great. Of course you do need to do things like always use file extensions. But those aren't hard changes to make, worth it for the better Developer Experience, and if it can help us start to wean off of mega-bundler tools as required production compile time steps.
  - tubs 2y ago
    Meh. Even with h3 I still see more gains from reducing network requests than most other attempts I try. (One day s3 will support multiple ranges per request, if I wish hard enough).
silverwind 2y ago
Yeah, besides that, leaving out the extension also creates ambiguity when the same filename exists with multiple file extensions.

hackandthink 2y ago

"nor have tsc configured to automatically add .js extensions to its compiled output" It seems to be the default now: $echo 'console.log("test")' > t.ts $ tsc t.ts $ ls t.js t.ts $ node t.js test

boromisp 2y ago
What they probably meant was writing 'import "file.ts"' and have tsc emit 'import "file.js"'. https://github.com/microsoft/TypeScript/issues/49083 https://github.com/microsoft/TypeScript/issues/49083
- WorldMaker 2y ago
  Given the context of Node here will allow experimental type-stripping and will not be doing things like import rewriting, Typescript's decision here to focus on "users write .js in imports because that's how the type-stripped file should look" seems like the right call to me. Less work for a type-stripper because Typescript can already check if there is a .ts or .d.ts file for you if you use .js imports everywhere.

IshKebab 2y ago

> unprecedented Well except for Deno...

pas 2y ago
Bun started with compatibility with NodeJS as a primary goal, whereas for Deno it took a while to be able to import npm stuff. (Of course there are fun WTF[0] errors with Bun, and I only tried Deno before the npm import feature landed.) [0] https://github.com/oven-sh/bun/issues/11420 https://github.com/oven-sh/bun/issues/11420

k__ 2y ago

Bun is pretty awesome. However, the node:crypto module still doesn't work 100%. So, I can't use it yet.

tossandthrow 2y ago
The parallel implementation they do uncovers a number of unexpected behaviors in the node implementation.
- k__ 2y ago
  I see. I just tried to sign some data with an RSA key, and the results differed in Node and Bun.

oblio 2y ago

Isn't Bun too raw? It's built with Zig, which hasn't even hit 1.0.

laxis96 2y ago
Probably had to stay in the oven a bit longer... Jokes apart, Zig is moving forward a lot which is why it's not 1.0 yet, but it doesn't mean you can't write safe and performant applications right now. Zig is also a rather simple and straightforward language (like C) and has powerful compile-time code generation (like C macros, but without the awful preprocessor).
- oblio 2y ago
  I'm more worried about compilation or stdlib bugs. In theory you can do lots of things with lots of things, but in practice there are all sorts of hidden limitations and bugs that tend to be noticed once a software product is past 1.0 and has been out in the wild for half a decade or more.
jokethrowaway 2y ago
You still get segmentation faults. My biggest complain with bun is not having enough safety. If you use frameworks written for node memory usage is very high and performance is meh. If you use frameworks written for bun they smoke anything on node. I'd definitely move over, just to get rid of the whole TypeScript / cjs / esm crap, but: 1. frontend support is poor (next.js / solid.js - I can't run anything fully on bun) 3. I still need to rewrite my backend app from a node.js framework to a bun one 4. for backend development the javascript ecosystem is losing the crown: if I wanted something safe I'd just write it in Rust (TS allows any random developer to write crap with any in it and it validates), if I'm doing something AI related I'd probably need python anyway and fastapi is not half bad
- tossandthrow 2y ago
  We use Bun in production for the entire stack and has done since v1 - only with minor hikups, that all trvivially has been fixed. DX is great! We use vite react ts, yoga, and prisma.

WuxiFingerHold 2y ago

I like Bun a lot, but Deno is (still) the more mature, stable, capable (e.g. stable workers, http2) and depending on the use-case more performant option (V8 > JSC). DX and tooling is top-notch. Deno can perform typchecking, btw. They bundle the TSC IIRC. Bun is the hype, but Deno is currently clearly the better option for serious endevours. Still, the vision and execution of Bun is impressive. Good for us devs.

XCSme 2y ago

I tried Bun twice, months apart, it never worked for me on Windows, failing to run "bun install": https://github.com/search?q=repo%3Aoven-sh%2Fbun+bun+install&type=issues https://github.com/search?q=repo%3Aoven-sh%2Fbun+bun+install...

deleted 2y ago

[deleted]