Don't forget Bun (*) ... [1]. Bun's bundler is appealing since Bun packages a bunch of other tools you already need (test runner, runtime, fast npm replacement).
Bun + Biome covers everything you need for a TS project (Biome lints and formats).
--
* : I guess it is not written in Rust but still in the same category of tools.
there is a small difference: you also need to make your own hmr reloading script when using bun. But it does so much more than just frontend bundleing.
Sure. This was wrt "when using bun" - i.e. somebody else might prefer to just whack web-dev-server into place as a lightweight option for them.
mininext is a neat idea and I plan to read through the code (do you have a preferred 'small snippet' for hrm? I'd be interested to read that too) but I was talking more generally in my last comment.
Sorry for the silly question, I found the standardDevReloader stuff, hadn't realised it was built in. Not what I was hoping for since I want per-library reloading, but for the goals of mininext that's probably overkill anyway.
I like to keep it simple. Right now bun just rebuilds everything and it is so fast that I don't recognize it.
If it ever becomes a problem I will optimize it.
The standardDevReloader is a snippet to tell the browser to refresh the page after a rebuild happened.
If you setup a fresh project with the barebones quickstart template with:
bun create spirobel/aldi yournewproject
you will see a dev.ts in the project folder.
compared to the start.ts (which is used to run the prod version) it will setup this snippet, so it is included in every html page that is served.
Yep that was a bummer for me, I was trying to start a little project where I wanted a bundler lib and started using Deno's... but quickly ran into some limitations and found out they've deprecated it and it's not even maintained anymore :( . I started using esbuild instead via its Typescript lib, but then noticed I was spending a lot of time working around the problems with the JS ecosystem (terrible file system watcher in node.js, lots of underpar libraries and as someone not intimate with every domain, it's nearly impossible to know which library may be well written and maintained without spending lots of time investigating, weird APIs, silent errors, I just can't believe some people can cope with all of this instead of just moving to a saner language).... and as esbuild is written in Go, I rewrote my code in Go and now it's much, much nicer to work on, much faster, can be shipped as a single binary etc.
If there was a bundler written in Rust I might have chosen that, as despite not having anything against Go, the momentum seems to be strongly shifting to Rust (and even in the little Go I did, I already feel the pain of its error handling), and Rust definitely gives you better tools to write reliably applications.
Neither sentence of your post has any value to anybody, other than (possibly, dubiously) yourself. Next time, consider writing such comments in your personal journal, or perhaps just shouting them out loud when you're alone.
I feel like it's a bit weird they didn't mention Rsbuild. Rsbuild is a "nice" wrapper around Rspack and SWC.
It's probably more holistic/batteries included than Farm, from a cursory glance. Rsbuild also aims to be a Vite alternative, but leans more into the webpack philosophy (and ecosystem) than Rollup's
There is also Vite, of course , which is already quite fast and very popular.
What's the differentiator between those?