“esbuild” will bundle, properly, javascript files only, for on its website it says that there may be problems with bundling css files.
Does bundling js files save that much traffic so that it’s worth it to use the tool?
The main benefits right now are tree-shaking, minification, and single (or a few) bundled file caching (browser does that, so it tends to load once per version). Esbuild can build css as entry point without any other config options, I haven’t seen any problem with css building.
It’s worth it for now, browser capability around this is improving (e.g. import map). Honestly esbuild config is really simple compared to js-based bundler.
1 Like
What’s tree-shaking?
The browser is capable of caching 1 file as well as 5 ones. What’s the difference?
You haven’t listed any beneftis of using the tool in the first place. “It’s easy to use therefore one should use it”. What for? How about downsides?
It really depends how much js you have. If I only use Phoenix Liveview and a bit of js I wrote, I don’t bundle. If I need to use a js framework for a project, I bundle.
Don’t trust words, benchmark yourself.
I think you perhaps have misunderstood the explanation for lack of context. This community has kind of a history with javascript build tools. We used to use Brunch, then Webpack and now we are using Esbuild, which is really simple to configure and use compared to existing options in the market. The decision to replace Webpack with Esbuild has been documented on the forums (if you are interested). For further explanations that are not just subjective opinions, I think it would actually be productive if you tried configuring the other tools and making the decisions if it’s worth it on your own.
It depends on the project’s asset delivery strategy… You still can deliver a huge bundle that the browser will cache and only redownload once a month or deliver lots of small files that are cached and change frequently. It really depends, there’s no “right” answer here. I encourage you to read a little bit more on those strategies to make it more clear how those different tools might help you.
You can also use GitHub - CargoSense/dart_sass: An installer for sass combined with esbuild to get sass without webpack.
2 Likes
Yes I just followed a tutorial on setting up CargoSense dart_sass to enable bootstrap and fontawesome with a phoenix 1.6 project.
The only downside of dropping webpack I have for now is that with CargoSense dart_sass, I have to manually copy fonts to “priv/static/…” when they are referenced in imported css/sass files. The issue is reported on the github here: Images and fonts are missing from node_modules css files that use url('...') · Issue #22 · CargoSense/dart_sass · GitHub.
I don’t want to make a big deal out of this, but just in case there would be simple workarounds, I would take it. ^^
One solution I’ve found that I like because I haven’t had to adjust it is to just chain specialized build tools together.
For instance:
- I use the tailwind package to output a tailwind.css file.
- I have an esbuild config using app.js to grab and bundle packages from node_modules (get to use dependabot on GitHub then).
- I have another esbuild config that pulls css (with fonts) in from node modules to bundle with any custom CSS in app.cs
- And then I could bundle it all together with one more esbuild config but instead I just link the 3 files in html.
The configs are all super short and easy to read, run in milliseconds, and adding new front end packages is still just npm install.
I wonder if you could chain dart_sass and esbuild in some simple way that would being the fonts in for you?
2 Likes
Thank you for sharing your solution. I like it too. ^^
Yes that would be great, but for now I don’t have sufficient knowledge with those tools and I will just keep manually copying the needed fonts for imported sass styles. Otherwise I found dart_sass config very easy and straightforward.
