Why not iconify_ex

[kantum]

I'm using https://github.com/bonfire-networks/iconify_ex right now and I wonder why creating a new library was needed, and are there any reasons for me to switch.

[dannote]

Thanks for asking. I don’t mean this as a criticism of the original author — iconify_ex clearly solved a real problem and has useful ideas, especially around CSS/img/sprite modes and Surface integration. But when I looked at the implementation, it crossed the threshold where I’d rather do a clean rewrite than build on top of it. There are a lot of implementation details like IO.inspect calls, runtime file generation, process/ETS caching, generated modules, and mixed responsibilities spread through the codebase that make it hard to maintain or evolve safely.

phoenix_iconify was created with a narrower design: a small core iconify package handles IconifyJSON parsing, alias resolution, transformations, fetching, and safe SVG rendering, while phoenix_iconify adds a normal Phoenix component plus compile-time HEEx discovery and a manifest of only the icons used by the app.

So I wouldn’t say everyone should switch. If iconify_ex works for your app and you rely on its CSS/img/sprite/favicon modes, staying on it is reasonable. The reasons to switch are mostly if you want no Yarn/Iconify JSON asset setup, no generated component modules/static icon files, better Iconify alias/transform handling, SVG ID rewriting for gradients/masks/clip paths, and a simpler Phoenix.Component-first inline SVG workflow.