As the title suggests, I’d like to hear your opinion of the idea to replace esbuild with bun.js, since it recently received its 1.0 release. The release trailer can be found here: https://www.youtube.com/watch?v=ThyMiimsAA0, more infos about bun you can find here: https://bun.sh/
For those who haven’t heard of it: bun is supposed to be a drop-in replacement for nodeJS and Deno. It as also a package manager so it replaces npm etc, and it comes with its own test suite. Written in Zik (https://ziglang.org/), it seems much faster than node and deno.
Now, I know that Phoenix switched to esbuild quite recently, however bun seems to outperform esbuild, and can also be used as a test framework and even as a runtime, in case you need some service written in JS. So, as it looks like, it would be everything esbuild is (a bundler) but faster, and more. There’s already support for many frameworks, and I think it would be great if you could spin up a Phoenix app, and combine it for example with a single page application of your choice out of the box.
What is your opinion about this? Would you prefer to stick with esbuild for now, or do you think it would make sense to switch again?
This was at Bun’s GitHub repo. So it’s not possible to replace esbuild now because Bun doesn’t have Windows support.
Windows users — Bun does not currently provide a native Windows build. We’re working on this; progress can be tracked at this issue. In the meantime, use one of the installation methods below for Windows Subsystem for Linux.
Yes I forgot about Typescript support and the Windows issue. Well, that will be solved at some point, and I also would not suggest you replace esbuild right with an 1.0 version anyway but wait a bit until first production experience reports are in. But given that windows support is there, and we can see in many places reports like “we switched from node to bun and it is awesome”, would you like to have the switch to bun then?
This has been on my mind since Bun released version 1.0. I’ve published a package today to integrate Bun with Elixir which is heavily based on the Esbuild package.
I’ve pushed this rock before. I have in here everyday in the past complained how painful webpack was and that we should push to esbuild. I guess we have come full circle again.
I didn’t post this as a retort for asking to use bun.js but rather to say. It would look like every so many years that our asset tools evolve and we end up wanting to migrate. This clearly requires some effort on someones part and we should not just expect the core team to just want to pick up a new tool every few years.
Phoenix already does a good job at abstracting that pipeline for the most part.
The only thing I think that really keeps us coupled to this workflow is the trigger for watching a file so that it gets recompiled while running a dev server. “PhoenixLiveReload”
It would be nice to see phoenix in the future be completely static asset management agnostic and not come pre baked with any 3rd party lib for that.
This has been one of the biggest issues when working on any legacy app. The Node js libs that need to be managed in said tool cry because they are too out of date and no longer compatible.
Even to this day I don’t understand what is the benefit of esbuild compared to webpack, at least for the things I was using.
I think the biggest motivation to move to esbuild is the fact that you have the self-contained CLI tool, no longer have to install things like node, create js configs and all that crap.
For me it was the speed that the tools ran. Web pack can be very very very… slow.
I’ve found for the most part ESbuild to be vastly faster at compiling the assets.
ESbuild has also been much easier in terms of the constant rug pulling that was happening in the core libs that webpacked used for things like css chunking ect. It was like every other week I was having to change some webpack lib that did simple things like css that seemed to break the whole pipeline every upgrade
If you ever did a Phx project with a nested React app that used Webpack you know this pain very well.
The only thing I ran into at first was the lack of support for async js loading like wasm files.
that was due to how webpack “bundled” and chunked out those files.
I don‘t see where phoenix should or could become more agnostic to built tooling. The only reason it ships with one integrated is because it would be bad for a fresh phoenix project to require the user to setup an assets pipeline. It need to ship some reasonable baseline.
But the intergration points phoenix has with an assets pipeline is the config in dev.exs to start one or more watchers and one or more commands in mix.exs to run a full build. Both are actually optional if you don‘t need the assets pipeline to run with phoenix commands, but start them out of band. If those commands can put files somewhere in priv/static/… things will work.
Phoenix LiveReload checks files being changed in that folder as well. It doesn‘t care how or by which method files are changed in the folder.
So really phoenix doesn‘t care at all what you use. It just wants to see the resulting files being placed/updated in a certain folder.
NoBuild is not an alternative, especially in the hands of someone potentially not as experienced. Also NoBuild is still far from NoTooling. If I need a tool anyways I much prefer one, which can bundle my stuff as well.
tl;dr
In the current landscape, bundling is still a very effective strategy. Larger files compress much more effectively and thus download faster at all connection speeds. Further, queueing, scheduling, and latency work against us in a many-file setup.
However, one huge bundle would limit our ability to employ an effective caching strategy, so begin to conservatively split out into bundles that are governed largely by how often they’re likely to change. Avoid resending unchanged bytes.
Future platform features will pave the way for simplified build steps, but even the best compression in the world won’t sidestep the way HTTP’s scheduling mechanisms work.
Compression yes, via gzip through my nginx reverse proxy. obfuscation / minimization no.
No build is not for everyone; however, if you only use Phoenix Liveview, maybe a handful of smallish NPM packages, less than a dozen hand written Javascript (no typescript, no JSX, …) No build is perfectly ok.
