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 Font...
For further actions, you may consider blocking this person and/or reporting abuse
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 class="fa-solid fa-thumbs-up fa-xl"></i>Great article, fontawesome is still awesome and the 'problems' raised in the original article really seem petty to me
Haha! I love it! Congrats! Your post appeared in the newsletter!
Glad to have sparked something! :-D
Teamwork makes the dream work 😎
I like FontAwesome and React Icons. They are amazing!!!
It is still awesome indeed!
There are better and more convenient to use alternatives, for example:
icones.js.org/
bootstrap-icons.click/
etc
Based on what? If you need only a small handful of icons and you're happy to manage the SVG code yourself, sure, something like what you mentioned would be a better choice.
I'm not suggesting that FontAwesome is the golden hammer to solve all icon-related problems, just that FontAwesome is often mischaracterised, misunderstood, and misused.
As always, horses for courses! 🐎