stiegi
Opinions: replace esbuild with bun.js
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?
Trending in Discussions
Other Trending Topics
Latest Phoenix Threads
Chat & Discussions>Discussions
Latest on Elixir Forum
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #performance










First 10 of 28 Posts
wanton7
I also read it supports TypeScript out of the box.
wanton7
This was at Bun’s GitHub repo. So it’s not possible to replace esbuild now because Bun doesn’t have Windows support.
stiegi
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?
wanton7
I’ve only used Phoenix LiveView for very small projects but sure I would be fine with that change.
LostKobrakai
Esbuild was chosen to lessen the node/npm related churn on the phoenix team. I personally wouldn’t see a switch to bun being helpful to that goal.
I’d love to see someone build a wrapper for downloading bun like the esbuild wrapper does it though.
belaustegui
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.
zstzlmk
Thank you, this is awesome.
belaustegui
Thank you! I hope that you find it useful
arcanemachine
Doesn’t ESBuild support TS out of the box? I haven’t made any changes but I can automagically import my TS files as needed.
polypush135
Well at least you are not asking for webpack
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.