Iconify offers components for several popular frameworks:
Unlike icon fonts, which only render icons available in specific fonts, Iconify implementations are not tied to specific icon set.
There are two types of implementations:
Some implementations support Iconify API.
They fetch icons as needed from API, so developers do not need to create icon bundles. Because of this, such implementations are very easy to use. Developers do not need to keep track of icons used in project.
There are several downsides to using API:
- API requires visitor to be online. Iconify API software is available, so organizations can mitigate it by hosting Iconify API on internal servers. You can also create icon bundles.
- Code is a bit bigger because it includes API support. Difference isn't big, just about 10-15kb, depending on implementation.
If you want to make sure icon data is always available, do not rely on Iconify API. Even though Iconify API servers have redundancies built in to provide as stable experience as possible, internet is never 100% reliable.
Implementations without API support rely on developer providing icon data. They are a bit harder to work with because you need to bundle icon data with package. These components get icon data from icon components.
Unlike SVG framework, components are designed for specific frameworks:
- Components use syntax familiar to developers.
- Some components use framework's native code when possible.
- Components correctly bind event handlers and dynamic properties. SVG framework cannot do that.
- Components render icons regardless of parent element, making it perfect for use in things like Shadow DOM. SVG framework only scans placeholders in document.body (unless configured otherwise, but components do that without additional configuration).
Most components share common code, making it easy to maintain multiple components for multiple frameworks. They also share code with Iconify SVG framework.
You can find code and demo files in big monorepo: https://github.com/iconify/iconify.