Dan WalshI 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
