The most important feature of esbuild is to not move from under us. Subscribe to Phoenix issues tracker and the Phoenix tag in the forum, you will see folks struggle with phx.new from time to time. Maybe the node version is too old, maybe npm is too recent, maybe node-sass just stopped working. All I want is for phx.new to work 5 years from now and this direction gives us that. We want you to be able to run mix phx.new, then mix phx.server, and have that page functional, regardless if you have opted-in to LiveView or not.

After that, you can opt-in to any complexity you want. You can bring Redis, you can bring Webpack, you can bring RabbitMQ. But the initial bootstrap should always work and stand the test of time.

I would love to ship with no assets toolchain but that’s not practical. Even a barebone Phoenix app requires importing “phoenix_html.js” and we can’t just bundle it into the app because running “mix deps.update phoenix_html” should update both the Elixir code and JavaScript code. So a minimal bundler is required even without LiveView (and even more required with LiveView).

I seriously recommend everyone thinking that the current status quo is ok to spend some time on the support front lines. It will be immediately apparent it is not fine and that it generates an incredible amount of churn.

Very Soon™

this is already happening. esbuild so we get js/css bundling/minification. No node, no npm, no webpack
7 is essentially happening as well as heex will indeed be the default. --html and --live will be merged