I read an interesting post in which the author stated the reasons why they were officially done with FontAwesome. I was intrigued, given I use FontAwesome in all my projects and feel that I am familiar enough with its various implementations.
To my surprise, the reasons provided all revolved around one core issue—improper production implementation. It seemed a little unfair to negatively review FontAwesome as a whole based on improper or impractical implementations. That would be like giving negative reviews to a toaster manufacturer because lots of people set up their toasters in their bathrooms (and were met with unfortunate accidents). It’s not a failing of the manufacturer...
FontAwesome can be implemented in many ways such as using Kits, downloading and hosting the SVG files, and my personal favourite: importing the FontAwesome npm packages into your project and using the Library for selective icon importing.
Developers should rarely be hosting and linking the entire suite of FontAwesome CSS files in a production application or site (unless they are happy to accept the pitfalls that go along with it, or if it's necessitated by the project's requirements). But to be clear: this is not the optimum nor the recommended implementation approach, and as such, it shouldn’t be used as the yard stick to measure the practicality and usefulness of FontAwesome as a whole.
Let's address the points in the original post...
🙅♂️ Myth #1: Managing versions is nightmare
The premise:
[You're] building a website in 2018, you may have used FontAwesome 5. [...] Let's say you need a gameboy icon. [...] But it doesn't work. Here's all the reasons why.
Here we go...
REASON 1: You're on FontAwesome 5.0. And this is on FontAwesome 5.11.0.
If implemented as project dependencies using npm, a quick update to your FontAwesome packages will provide you with all the latest icons.
Alternatively, if you've implemented a Kit, all of the latest icons will be available to you, based on your selected version. You easily can check and update the version of your Kit by logging into your FontAwesome account.
REASON 2: This is a 'pro' font. You're using a free version.
When searching for icons to use on the FontAwesome website, just click on the “Free” filter so you only list the icons available to your project.
REASON 3: You've been importing solid versions of fonts. You should You need the light versions.
So then install the light-style npm package and import the icons you need.
Better yet, if you've implemented FontAwesome as a Kit, then you automatically have access to every single icon style.
🙅♂️ Myth #2 - You import thousands of unused icons
The premise:
How many icons are you really using on your site? Maybe 6 or 7? Most sites (and I'm speaking from my own background) only use a handful of icons. [...] If you're importing a fontAwesome's regular.css, you're bringing in hundreds of fonticons you don't need. It's even more nightmare-ish if you're getting a circle-question icon (which lives in regular.css) AND a Facebook icon (which lives in brands.css). Now there's thousands of fonts imported... all eating bandwidth.
Again, if set up optimally, only the very few imported icons you are actually using (and their supporting CSS styles) are added to your final transpiled build files.
Reading further:
Defenders may say, "Well you can tree-shake it" or "optimize it".
And you're right! So... how many devs even know to do that or have the gumption to set that up?
Some common ground! While I was glad to hear that the author agreed that the defenders are right, I was taken aback by the assumption that implementing FontAwesome optimally is some Herculean task beyond the ability and understanding of most devs.
Lastly:
TailwindCSS includes the entire kitchen sink as well. But they also include helpers to prune it all so you ship the absolute, smallest most performant css you can.
The comparison to TailwindCSS is moot, given that FontAwesome provides the same optimisation options out of the box, provided your chosen implementation method supports it. For example, using npm packages and importing select icons ensures only the relevant icon data and CSS is included in your transpiled build.
And using Kits means none of this data is included in your final build and the specific CSS and SVG data is sent to the user during the client-side render of the page.
🙅♂️ Myth #3 - Resizing the icons is a nightmare
The premise:
A major problem with font icons is that you're treating them like fonts first, not icons. You want a horse icon to be 100px wide. This won't work:
.fa-horse { width: 100px; /* does nothing */ }.Instead, you have to fiddle with this using font-size.
That also means these icons are also affected by other css text modifiers, like line-height.
FontAwesome uses the font-size property because the icons are sized relative to the content and UI elements surrounding them. When you place a contextual icon next to your button label, it’s great that the icon will automatically match its size with that of the button label text. Need the icon to be a little bigger? Just add the fa-lg class.
A quick skim over the documentation will tell you everything you need to know about sizing your icons.
🙅♂️ Myth #4 - Major version releases break compatibility across the board
The premise:
<!-- FontAwesome 3 -->
<i class="icon-star"></i>
<!-- FontAwesome 4 -->
<i class="fa fa-star" aria-hidden="true"></i>
<!-- FontAwesome 5 -->
<i class="fas fa-star"></i>
<!-- FontAwesome 6 -->
<i class="fa-solid fa-star"></i>
If I wanted to upgrade FontAwesome 3 to FontAwesome 6, I'll have to go find all the markup and fix that.
If someone is using FontAwesome 3, sure, they would have to do that.
However, from FontAwesome 4 and up, backward compatibility is built in. You can upgrade your v4 or v5 project to v6 without having to make any changes to your markup.
If you check out the “Backward Compatibility” section of the “What’s Changed” section of the documentation, you’ll find that support for the use of the old style syntax (and even old icon names and Unicode values) comes out of the box.
🙅♂️ Myth #5 - You have to upgrade your plan to get the latest icons
The premise:
If I have FontAwesome 5 Pro, which I purchased in 2019, and I wanted a [thin-style bagel icon], I'll have to either:
Option 1: Keep FontAwesome 5 Pro and also include FontAwesome 6 [thin-style icons]
Option 2: Buy FontAwesome 6 Pro.Just to get a [bagel icon], I now can either fracture my versions or pay $99.
The answer is easy: just use the icon! A pro plan with FontAwesome includes the use of any icon in the latest version, always. So when v7 inevitably gets released, you’ll get access to those icons too, no plan-upgrade or additional payments required.
In Summary
All of these problems do have workarounds. The thing is -- all these problems are strictly from using FontAwesome!
This is almost true. I would go further to say that “all these problems are strictly from implementing FontAwesome in an unoptimised manner”.
When implemented well, FontAwesome provides you with lean, accessible, scalable icons for your projects. The original post conflated the issues present in bloated and “quick” implementations with the service as a whole, which I feel misinforms people of its great many utilities when used appropriately.
In my eyes, FontAwesome is still awesome.
☝️ Remember: Always import just the icons you need, tree-shake your projects, and never make toast in the bath.
💬 What do you think? Have you worked on a project that implemented FontAwesome in a not-so-awesome way? What's your favourite method for adding icons to your projects? I'm keen to hear your perspectives and thoughts in the comments below!
This post was originally a comment that I wanted to expand into a more long-form response. You can view the original post and my comment here:
Post: https://dev.to/rockykev/im-officially-done-with-fontawesome-2h2f
Top comments (18)
These tempered rebuttals are always welcome!
Cheers, @ben! 🙇♂️
I really liked this article and found it to be well-reasoned and informative. As a new webdev, I'm trying to understand everything, and this type of article really helps me understand things better. Thanks for taking the time to write this, Dan!
FontAwesome when scaffolding a brand new site and not sure what you need in icons! Totally a good move!
You’re very welcome, @randwulf_magnus, and thank you for the kind words!
Welcome to web dev! 😊
I think that FontAwesome is still a utility that introduces unnecessary and inappropriate markup and unnecessary styling considerations to your HTML. It's still the wrong solution it always was.
That bit about not having to change your markup when migrating from FA4 to FA6? That's great, but we shouldn't be resorting to changing the markup to accomodate cosmetic changes in the first place. We didn't need to do that a decade ago and we definitely don't need to do it now.
Thanks for your insights, @moopet.
I'm curious, you said that FontAwesome introduces:
Have you got any examples we can discuss?
Additionally, you stated that:
Going out on a limb here (to get more of a sense of your perspective), but are you in the camp that favours "separation of concerns" between HTML and CSS? If not, what did you mean by this statement? Perhaps I'm misunderstanding your position.
Yeah, that's what I mean.
I mean FontAwesome has the convention (though not the necessity) of using
ielements with no content as icons. You're adding empty italics to your page, which is non-semantic, but an explicitly non-semantic element like aspanwould be better, because it's not telling anyone anything about how it's displayed.Changing your icon choice across the site (which is purely cosmetic) means either changing the class so that
fa-facebooknow actually displays a meta logo, leading to confusion in the future because they're not actually interchangeable, or it means search-and-replace across all your HTML/templates.I'm also a big fan of not using icons at all, because for one thing, I find them confusing, and for another the author tends to run out of 1-to-1 representations of what they want and ends up using icons that kinda-sorta-might mean what they want if you squint hard enough.
Thanks for the extra context, @moopet.
Completely agree—implementing FA as a webfont and littering
<i>elements everywhere without the additional accessible markup goes against the FA documentation and WCAG guidelines. Devs should be following these guides to implement accessible icons, just as they would when adding the necessaryariaattributes for accessible navigation menus.The great thing about implementing FA using Kits or SVGs with JavaScript is that the accessible HTML is generated for you on the fly!
I feel that the Facebook/Meta argument is a bit of a straw man. If a company changes their logo and it has to be replaced across the site, depending on the implementation, you might have to search-and-replace to make the change in many HTML templates. That doesn’t mean that we should avoid using images. The same goes for icons. Depending on your stack, the search-and-replace effort could be reduced through a more atomic design/development approach. But even that will only get you so far. Maybe the takeaway here is to lock in your design approvals prior to development to reduce opportunities for this sort of refactoring?
I agree—poorly thought-out icons can be confusing for our end users. This isn’t a failing of FA (not that you said so), but is instead perhaps an indication that our designs have missed the mark. Thoroughly testing our web designs with our target user demographic is a great way to determine which icons resonate the most, or even which icons can be scrapped altogether. “Horses for courses”.
Really appreciate your additional insights.
That's a really good question, @dbarabashdev.
The short answers are:
The longer answers are:
I have worked on projects that were initially implementing the webfont version (which was some 500kB+) but then switched them over to using either a subset or an SVG Core and saw the FontAwesome portion of their bundle size plummet to a few kB. Unfortunately I don't have those projects handy to pull out the exact numbers for you.
The FontAwesome documentation has a great section on performance which details the complexities around each implementation method. Generally, your requirements should help inform which implementation will work best for your needs.
Personally, I use both the SVG Core (in React projects) and Kits (in more monolithic projects).
With the SVG Core, I'm only importing the specific icons I use in each project, and only in the styles I choose (regular, solid, light, etc.). When bundled, the only FontAwesome data included is the SVG markup and the CSS required to display them.
With a Kit, JavaScript is used to set up a MutationObserver that batches changes in the DOM to replace
<i>elements with<svg>elements, serving the SVG markup and styles from a global CDN. All of this happens during client-side render and doesn't hold-up the initial load of the page.The tricky thing about statistics is always going to be interpretation. Some will read the data and conclude that the solution is bloated and slow, while others will read the same data and see it as lightweight and fast. I feel it comes down to "horses for courses"—one implementation will be great for one project, but not so great for another.
I'd encourage you to try implementing FontAwesome yourself, take some measurements, and see which solution might suit you best. And if it turns out that none of them work well for your specific use-case, then that's okay too.
Thanks again!
I really like font awesome and it solves so many issues for frontend development. Great article 👏🏻
Thanks, @moose_said! 😊
I really like it too! Especially because it provides you with so many different ways to answer the question: “how do I add icons to my [insert stack here] project?” And the documentation is super thorough, which really helps! 👨💻
True that!
absolutely !
I like FontAwesome and React Icons. They are amazing!!!
Haha! I love it! Congrats! Your post appeared in the newsletter!
Glad to have sparked something! :-D
Teamwork makes the dream work 😎
It is still awesome indeed!