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.
Bundling is here to stay for a while.
To be clear, I was writing with tongue in cheek =)
Though, behind every joke there is some truth.. isn’t it? ;)
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.
I prefer Deno over Bun both from a security and hygiene perspective and the integrated approach. A good writeup on Deno is here.
There is also a nice Elixir integration.
Have you tried it? I’m looking forward to a nobuild liveview app running, but haven’t gotten to make it work myself.
