This is awesome but in case anyone was wondering: the author was previously using Webpack rather than a newer generation tool. So the speed benefits outlined here would likely be the same if they were still using Node with esbuild instead.

Overall I like Bun - diversity in JS ecosystems is a great thing - but I’m struggling to come up with reasons to actually use it (which is fine! As long as the author is enjoying the work, why not?)

You can see at the beginning of the article a benchmark comparison with Webpack and esbuild.

They weren't using SWC? They describe deploying to Vercel, and Next.js has had stable built-in support for SWC for a good while now

iirc next.js only uses swc for the dev mode bundler

edit: this is no longer the case, ignore me :)

Webpack is the bundler. SWC as used in Next.js doesn't do the bundling part.

I also didn't understand this, if they were using NextJS, why do they have a custom webpack config? My assumption is that there is a separate web app that does the drawing and coloring, they bundle it into a script.js and include it in their nextJS page.

Yes, this is correct. All the canvas stuff has nothing to do with React, so I bundle it all separately. In fact, I don't even load React on the browser, I just render the initial page with it on the server then just work with the DOM from there on out. It greatly reduces the amount of JS shipped to the client, and since 90% of my code was going to be Canvas related, it's not much overhead to add a few click listeners for various DOM nodes

Ah true, my bad. Though it's still relevant to mention, because usually when people hear "using Webpack" they also assume "using Babel". Bun is doing both the bundling and the transpiling, so it should be compared to the bundler + transpiler combination

I use it a lot for small cli apps and during dev, it's so nice to be able to run typescript files with bun instead of tsx or ts-node.

I use esbuild-runner, it works fine for me

Yes, I love bun for running typescript cli apps. 40x80 or some such is hardwired as the screen size though, and without raw mode, things like terminal window “controls” are broken.

Yeah we need to fix raw mode

>I’m struggling to come up with reasons to actually use it (which is fine! As long as the author is enjoying the work, why not?)

I wish more people, or at least more HN commenters, had this attitude. Don't have to look hard to find negativity in response to folks getting out there and having a go. How many passion projects went nowhere* but taught authors valuable shit that lead to incredible engineering and projects? Besides, I love writing software and anyone who says I shouldn't because it isn't going to be better than the status quo can beat it.

*not implying Bun is going nowhere. Be gone, pedants.

You're right ! I think many software engineers shits on project may be based on their experiences and forgets that these projects can driven in future awesome creations

> After a few hours of work, reading up on Bun and working my way through these issues, I now have a much simpler build system that runs in the blink of an eye. My Vercel build times have reduced from 2 minutes to just 50 seconds (that’s all React stuff & fetching node_modules). My watch script runs in a few milliseconds instead of 5 or more seconds, My code is much simpler and I’ve removed Webpack, Browserify and Uglify from my projects.

This is like when esbuild first appeared level's of excitement to me. Can't wait to try it out.

Good to see some real anecdotes. Bun makes big promises, so I've been really curious to see how the reality lines up right now (and not just in a hypothetical future)

Actually, I find kidzfun.art much more interesting than yet another js bundler ;-)

Glad to hear it! My kids love it which keeps me working on it. Having your ideal testers living with you is an amazing plus :-)

But it's not related ?

It’s the project I integrated Bun with as a bundler, thereby running into all these issues. I figured that others would hit the same problems so write this post about how to work around them

(I work on Bun)

Great writeup

We are working on the crash with the minifier + multiple entry points and hopefully will have a fix this week

> Bun inserts code that looks like this at the bottom of the built file, in this case from a file called account.ts

  var account_default = {};
  export {
    account_default as default
  };

Currently, Bun only supports esm output so for this to work you'll need `<script type="module">` instead of `<script>`. We will add support for IIFE though (which should fix this)

> Hopefully Bun will implement fs.watch soon and I can throw out this code.

Yeah we need to do this. It's not super hard and we have plenty of existing code for inotify and kqueue in place for watching files, there's no good reason why we haven't done this yet.

> There’s something unfinished with Bun’s implementation of the child_process module that breaks when run in the Vercel build environment.

Currently, Bun.spawn & Bun.spawnSync (which child_process uses internally) relies on `pidfd_open` (https://man7.org/linux/man-pages/man2/pidfd_open.2.html) which Vercel, due to using AWS Lambda, does not support because it is on Linux Kernel 5.10 (3 years old). We need to add a fork() + exec() fallback for this

edit: it's not pidfd_open, but it is one of these posix_spawn related calls that is missing

fs.watch is definitely a high priority in order to support day-to-day dev as a build system.

(Hey Jarred - Let’s get that zig package thing done soon!)

> fs.watch

https://facebook.github.io/watchman/ is a good workaround for now.

It’ll take a lot to replace esbuild for me -- it’s fast enough that it’s never the bottleneck and more importantly has always been absolutely rock-solid and reliable. So a tool that’s 2x faster but less reliable isn’t appealing.

bun seems great and promising but I'm in the same boat. vite/esbuild with vitest is running perfectly, and already fast enough (and at last not struggling with webpack or rollup overall poor quality anymore...).

Yep, vite is really nice too.

bun can run vite prod build at least and seems about 10% faster at it than node according to my testing.

My problem with “Vite is good enough” and “Vitest is good enough” as a paired hypothesis is they are literally opposite in their target environments. It’s explicitly unsupported to use Vite to build projects specifically for Node as a target, and it’s explicitly unsupported to test in Vitest in browser environments (though I think that’s being actively addressed, but it’s still going to be a second class solution).

It depends of what you mean by browser environments (integration tests?), but vitest with happy-dom is working great for testing libraries and components.

I've had bad experiences with esbuild. Don't remember what specifically but didn't work for my use cases.

Roll-up for libs and webpack for apps. Only thing that works for me and all the wonky edge cases involved in building for web and node and npm and old browsers and various file types and loaders and whatnot.

It isn’t clear to me that bun is less reliable. A day old bundling tool is not a fair yardstick for what I’m referring to. In general I haven’t heard about any reliability issues and see glowing reviews about its cold start time and thorough-put. If there are any I should be aware of please do share.

I was just thinking about the sort of issues described in this post, like having to use specific flags to prevent the minifier breaking code, or write an extra pass to tweak the output. I’d worry about what other problems there might be that I hadn’t noticed yet.

Presumably those will get fixed over time, and at some point bun will just work if you want to replace your existing bundler. But even then, I personally would lean to sticking with esbuild as it’s more than fast enough for my purposes -- extra speed isn’t a compelling selling point (for me).

Yes, Bun is very much in beta, but it's already really, really good. I'm fine using it with my hobby projects right now, but once it gets to 1.0 I'll give serious consideration to using it in production code too. The API is really simple, and I love how it just understands Typescript, so you can throw any code in your repo at it and it chugs away happily.

Yes, being able to just run TS directly is very appealing. When I last tried, neither bun nor deno nor ts-node worked out of the box for me. The other two seem to be a bit stuck in the weeds (deno aggressively trying to do its own thing, then backtracking and adding node compatibility back in; ts-node hampered by having to work around weird design decisions in both node and TS) so I wouldn’t be surprised if bun ends up as the winning TS engine.

INCREDIBLY less reliable! Even the sole dev would admit as much if you could distract them from their VC handlers.

Gotta go with libre tools for these cases unfortunately. Nothing against Bun specifically of course, just the concept of capital + dev tools is something that must be re-learned as evil time and time again.

From OP:

A second issue with the default minification is that it broke my app in strange ways that I could not track down – I’m guessing that it’s rewriting the code in some way that is not fully stable yet. I solved it by turning off the syntax minification option

Rest sounds nice:)

a BUNdler

I appreciate the kind of guy that adopts a technology before it’s “ready.”

Bun is really sweet tech. I think a good benchmark for it being ready is being able to run Nestjs.

Has any one tried bun with nestjs? I have a nestjs project that uses webpack.

kidzfun.art is pretty good. I enjoyed it every much. Here is a screenshot, https://ibb.co/WygKLDc

Glad you like it :-). I'm planning to write a few blog posts about how it's built, there's some fun stuff in there - the first one will probably be about how I make the paint bucket fill operation be instantaneous, that was an interesting problem to solve

Now, go make some Gifs in the Animation section!

Bun clearly is both a great project and has rough edges.

Thank you to the Bun team for the work you're doing.

Thanks also to OP - the success of tooling depends upon the work of both the project and the early adopters willing to put in the work like OP did (seems substantial and motivated at least partly by sheer challenge/intellectual curiosity).

While it's definitely not ready for the mainstream, it's still a very interesting project.

Great to seeing another alternative, But working outside Bun I don’t see “The reason”, speed is great but excessive speed is most times unnecessary. Understand on the level of Bun it’s better to have its own bundler than to use a 3rd party hope it works well with bun