It seems a little unfair to negatively review FontAwesome (FA henceforth) based on improper or impractical implementations, right? 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.
FA can be implemented in many ways such as using Kits, downloading and hosting the SVG files, and my personal favourite: importing FA npm package into your project and using the Library for selective icon importing.
No one should be linking the entire FA CSS files in production (unless you’re happy to accept the pitfalls that go along with it). But to be clear: this is not the optimum nor the recommended implementation approach, and as such, shouldn’t be used as the yard stick to measure the practicality of FA.
Addressing your points:
Point #1: Version nightmare
If implemented as an npm package, a quick update to your packages will provide you with all the latest icons.
REASON 1: You're on FontAwesome 5.0. And this is on FontAwesome 5.11.0.
Run your npm update command against your FA packages—job done.
REASON 2: This is a 'pro' font. You're using a free version.
When searching for icons to use on the FA website, just click on the “Free” filter so you only list the icons available to your project—no problem-o.
REASON 3: You've been importing solid versions of fonts. You should You need the light versions.
So then install the light npm package and import the icon—easy.
Problem #2 - Massive font set
Again, if set up as intended, only the very few imported icons you are actually using (and their supporting CSS styles) are added to your final transpiled build files.
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?
I’m glad that you agree that the defenders are right. Also, how many developers know how to properly set up their FA installs and have the gumption to do so? You’re taking a pretty broad swipe at the dev community here with this assumption, as if this is some Herculean task beyond the understanding of most devs.
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.
Your comparison to TailwindCSS is moot, given that FA provides the same optimisation options out of the box, provided your chosen implementation method supports it.
Problem #3 - Fonts first
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.
Are you screaming yet? 😱😱😱
FA 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.
A quick skim over the documentation will tell you everything you need to know about sizing your icons, no screaming required.
Problem #4 - Changing APIs
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 FA3, sure, they would have to do that.
However, from FA4 and up, backward compatibility is built in. You can upgrade your FA4 or FA5 project to FA6 without having to make any changes to your markup.
Problem #5 - Locking you into the model
Perhaps your choice of a TikTok icon was a mistake, because that falls under their “brands” style which is free to use, no payment required. But I understand your point: what if you have FA5 Pro but the icon you want to use is in FA6 Pro?
The answer is easy: just use FA6 Pro. A pro plan with FA means you can use any icon in the latest version of FA, always. So when FA7 inevitably gets released, you’ll get access to those icons too, no plan upgrade or additional payments required.
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 inefficient manner”.
When used properly, FA provides you with lean, accessible, scalable icons for your projects. Unfortunately, your post conflates the issues present in bloated and “quick” implementations with the service as a whole, which I feel misinforms people of it’s great many utilities when used appropriately.
Remember: Always import your icons and tree-shake your project, and never make toast in the bath.
Heya! You're totally right. I actually point that out before I start listing my grievances - that my preferred method is through svgs and through npm packages.
All of those solutions is if you have the luxury of doing that from the start.
I inherit a lot of old projects, and hence my frustration. (love the toaster metaphor)
Also, I noticed your comment is pretty long! Do you want to shape it into a separate blog post and do a counter-post? I promise I take no offense, and it'll be like a rap battle in blog form. :-)
I can absolutely appreciate your position. Inheriting technical debt just compounds your workload. And of course, you have to make that “refactor or leave it” decision (if you have the luxury), which you know is going to impact the next web dev one way or another.
I’m glad to hear you took my comment as it was intended—not as a personal attack, but as a rebuttal of your position. All too often (especially online) our words get taken out of context and perceived as an attack to be offended by. Grateful to see we can still have rational, mature discussions in 2022. 😊
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It seems a little unfair to negatively review FontAwesome (FA henceforth) based on improper or impractical implementations, right? 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.
FA can be implemented in many ways such as using Kits, downloading and hosting the SVG files, and my personal favourite: importing FA npm package into your project and using the Library for selective icon importing.
No one should be linking the entire FA CSS files in production (unless you’re happy to accept the pitfalls that go along with it). But to be clear: this is not the optimum nor the recommended implementation approach, and as such, shouldn’t be used as the yard stick to measure the practicality of FA.
Addressing your points:
Point #1: Version nightmare
If implemented as an npm package, a quick update to your packages will provide you with all the latest icons.
Run your npm update command against your FA packages—job done.
When searching for icons to use on the FA website, just click on the “Free” filter so you only list the icons available to your project—no problem-o.
So then install the light npm package and import the icon—easy.
Problem #2 - Massive font set
Again, if set up as intended, only the very few imported icons you are actually using (and their supporting CSS styles) are added to your final transpiled build files.
I’m glad that you agree that the defenders are right. Also, how many developers know how to properly set up their FA installs and have the gumption to do so? You’re taking a pretty broad swipe at the dev community here with this assumption, as if this is some Herculean task beyond the understanding of most devs.
Your comparison to TailwindCSS is moot, given that FA provides the same optimisation options out of the box, provided your chosen implementation method supports it.
Problem #3 - Fonts first
FA 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.
A quick skim over the documentation will tell you everything you need to know about sizing your icons, no screaming required.
Problem #4 - Changing APIs
If someone is using FA3, sure, they would have to do that.
However, from FA4 and up, backward compatibility is built in. You can upgrade your FA4 or FA5 project to FA6 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 FA docs, you’ll find that the use of the old style syntax (and even old icon names and Unicode values) are supported out of the box.
Problem #5 - Locking you into the model
Perhaps your choice of a TikTok icon was a mistake, because that falls under their “brands” style which is free to use, no payment required. But I understand your point: what if you have FA5 Pro but the icon you want to use is in FA6 Pro?
The answer is easy: just use FA6 Pro. A pro plan with FA means you can use any icon in the latest version of FA, always. So when FA7 inevitably gets released, you’ll get access to those icons too, no plan upgrade or additional payments required.
Summary
This is almost true. I would go further to say that “all these problems are strictly from implementing FontAwesome in an inefficient manner”.
When used properly, FA provides you with lean, accessible, scalable icons for your projects. Unfortunately, your post conflates the issues present in bloated and “quick” implementations with the service as a whole, which I feel misinforms people of it’s great many utilities when used appropriately.
Remember: Always import your icons and tree-shake your project, and never make toast in the bath.
Heya! You're totally right. I actually point that out before I start listing my grievances - that my preferred method is through svgs and through npm packages.
All of those solutions is if you have the luxury of doing that from the start.
I inherit a lot of old projects, and hence my frustration. (love the toaster metaphor)
Also, I noticed your comment is pretty long! Do you want to shape it into a separate blog post and do a counter-post? I promise I take no offense, and it'll be like a rap battle in blog form. :-)
I can absolutely appreciate your position. Inheriting technical debt just compounds your workload. And of course, you have to make that “refactor or leave it” decision (if you have the luxury), which you know is going to impact the next web dev one way or another.
Great minds must think alike, because I already spun-up a counter-post! 😅
I’m glad to hear you took my comment as it was intended—not as a personal attack, but as a rebuttal of your position. All too often (especially online) our words get taken out of context and perceived as an attack to be offended by. Grateful to see we can still have rational, mature discussions in 2022. 😊