As a web, mobile or software developer, you’re probably including emojis in your application the wrong way. This is why.
Starting With An...
For further actions, you may consider blocking this person and/or reporting abuse
Preword: this is a warning on the use of the library itself, not your article, despite the tongue-in-cheek title suggestion :-P
This should be titled "The one script that will kill your core web vitals".
If you used 10 different emojis on your page that is 10 extra network requests (plus one for the script itself), so your load speed will suffer!
Also I would imagine that your Cumulative Layout Shift would be horrendous due to the impact of inserting the images on the fly (and as such not allocating the correct space for them).
You would be much better manually inserting the SVG code for the emojis inline within the HTML if they are that important to your article.
If that much effort is not justified, then you know that is when you are using emojis the wrong way as they are simply not needed!
Additionally that alt text for the images will not behave well with screen readers as it appears to just be set to the emoji Unicode character, so from an accessibility perspective this is probably worse as you now have an image with a potentially useless alt description that will be announced instead of just an item that will get skipped (as screen readers have a notoriously bad time with emojis).
I would say avoid this at all costs for any site that needs traffic I am afraid (useful for personal blogs perhaps and the like, which I suppose are where emojis would be used anyway so perhaps I am just being stupid. hehe.)
Thanks for your comment 😁
Not a problem, like I said (or should have said more clearly!) I enjoyed the article and it actually has made me think this is one step away from a good idea.
You could convert the code to server side code and replace all the emojis with inline SVGs before serving the page. The principal is sound just the implementation is bad, doing it on the server could actually be a useful solution.
Saved the library anyway and if at some point I get down my list of 50 "thats a great idea I will do that one day" items I may implement it as a server side library.
Honestly I didn't think about the fact that, indeed, this creates many requests if you put several emojis! Thanks for your advice.
P.s. I guess what you're looking for is the rectangle "save" button, isn't it?
No I found it, the big heart icon on the left to give your article some love was what I was looking for! hehe.
I strongly agree, replacing a simple unicode emoji with a JS library that replaces the svg on the fly is a really, really bad idea.
If you do want to replace emojis with SVGs you should do it at a build step, automatically. Preferably all the SVGs would also be loaded as a single spirte-sheet to avoid multiple requests.
Personally I think that emojis are well supported enough to be used natively.
You shouldn't write an article and propose people to use files and resources instead of standard device emojis. Or at least you should write down the drawbacks and not present everything like bells and whistles.
People with old browsers or devices should upgrade their browsers to access new features. You remind me some old folks that even today insist to support Internet Explorer and spend countless hours to make their HTML/CSS work on obsolete browsers just for some people with old browsers to be able to see their pages.
You throw away standards about how emojis should appear on each device and use external libraries to live traverse the HTML code of the document? That's a terrible thing to do. If I have an iPhone, I want all emojis to look like how apple wants them to look like in an iPhone. If I open the sites using Firefox, I want all emojis to look like how Mozilla emojis are look like. If you don't want to use the default emojis, then you want to use device independent SVGs to present graphic emojis and not standard emojis. In your article you're just using a horrible automation technique to parse the whole document.
Also keep in mind that Twitter emoji usability sucks. Just try to use them in your tweets and you'll see for yourself what I am talking about. You can't even select them because they are not using standards.
Agree with everything apart from the "You remind me some old folks that even today insist to support Internet Explorer" - we support IE back to IE9 due to the fact that disabled users who rely on screen readers often can't afford to update JAWS to the later versions and so are stuck on older browsers, some are even still using IE6-8 according to the most recent WebAim survey, but even I draw the line at supporting IE6,7 or 8!. You should at least support IE11 due to this fact (as 1 in 10 screen reader users still use it), even if it is a pain!
Is this really true? I am genuinely interested, as I've not run into this particular argument before. Personally I tend to use NVDA most of the time (for testing purposes) as surveys tend to put it as the most used (webaim.org/projects/screenreadersu... ) and it works on every browser across Windows. It being free for use is probably also what's contributed to its popularity.
Also, looking at the JAWS website, it doesn't appear to charge for upgrades.
I do believe the argument for supporting very old browsers/systems has to strike a balance. First, we must ask if that emoji is vitally important to the content? If it's not, why is it there at all, and can it be removed?
If we truly need it, then how much of our audience is likely to be affected by it not being there? Mac and Linux have support for emoji out of the box, and Windows has it with built-in updates (albeit non-essential) since Windows 7 (which is about 11 years old now). We could use this Twitter library, but then the cost is going to affect all of our users by increasing network traffic and decreasing performance. When you consider that even countries like USA have some areas with really poor Internet connections, that impact actually becomes much more noticeable (businessinsider.com/map-fastest-an... ).
Thanks for your comment!
@ashleyjsheridan Yes it is true.
We could make the argument similar to @christoslitras that "users should just use the latest tech" but there are loads of reasons why they don't (for example):-
With regards to JAWS cost it depends entirely on what country you are in as they use a distributor model.
In the UK to upgrade from 2017 JAWS or earlier to 2020 JAWS would cost you £375 as a home user. If you need it for work expect to pay double for a commercial license (although with a bit of fiddling and patience you can get that paid for by the government).
This is why NVDA is so popular (as you mentioned, it's FREE!), and it is a great piece of kit, but JAWS is still better with some programmes etc.
It is also familiarity, if you have used JAWS for 10 years then you know the shortcuts, the speech patterns, idiosyncrasies etc. Forcing someone to use NVDA and a certain browser is like me asking you to start writing with your left hand if you are right handed (or vice versa) in order to use my service.
You could do it but it would take a lot of time and effort so I am sure you would just stick with your right hand and just go to someone else who will let you write with the hand you prefer. (Not my best analogy but hopefully you get the point!)
I agree on the balance, it frustrates me that I have to still support IE9 - but I blame Microsoft for the issues I have with IE9 not my end users.
We choose IE9+ (rather than IE8+ etc) as our support level as that supports modern HTML and most CSS and compiling your JavaScript to work in IE9 isn't difficult.
When I say support IE9 I am not talking about pixel perfection, we can live with layout quirks and certain features not working perfectly as long as the site is still usable and fully accessible.
Also we support IE9+ for E-commerce sites, for SAAS we support IE11+ due to not wanting to have to create our own frameworks. We do however ensure that older browsers have alternative ways of performing critical actions.
That is just my 2 cents and why we support that far back, everyone is different, I just think it makes commercial sense to support things people still use as when they can't use your website as you don't support them they will hopefully come to mine 😊.
If you have your own site statistics and you can see there is a quite percentage of IE users using your site/services, then you and your team can decide if it's worth the time and effort to support such obsolete and abandoned browsers.
According to gs.statcounter.com, IE (all versions) global share is 1.68% and it keeps falling. Also many companies like Google, Facebook and even Microsoft, have stopped supporting IE for all new releasde of some very popular frameworks like React, Angular, Blazor/.NET SPA and even VueJS.
It does not worth it, not only for the time you or your team spends on this, but also having your site/app downloading and loading several JS/CSS files for pollyfilling missing features for obsolete browsers is bad for the projects ecosystem, for the majority of end users, for devices and even for the environment.
Nooooo 🙀! Use the platform instead! Emojis are part of UTF, use them directly and no more libraries for this! Your grandparents who will have a bad connection will appreciate it as they will not need to download so many images.
I do think emoji should be avoided, except for the sake of convenience.
I'm sorry, but please don't. As someone with vision-related sensitivities, I have to adapt websites to my needs. If you stick to font-based emoji, I can change the font. (I hardly use mobile apps except some light games and a couple of apps which happen to suit my eyes anyway.)
My actual problem is not emoji, it's glare and contrast issues. I use Dark Reader to eliminate the glare and increase the contrast. My greatest nemeses (wording intentional :p ) are interface designers who don't consider this use or who enforce their view of what their site should look like. The next level down is designers who use black-on-transparent icons for important things. Thankfully, that's rare these days. Things have got better in the last 10 years, please don't reverse the trend. Actually, the trend is already starting to turn with site scripts setting styles in some cases. I'll leave my feelings out of it because you wouldn't like what I have to say. :(
Thanks for your interesting feedback!
Nice trick
I also use it in my blog, replacing the built-in ones with the consistent twemojis
How many grandparents are visiting your site?! ...
And another CDN ...
You can also use this method to display new emojis that haven't been supported on latest version of operating system yet. It typically takes 1-2 years for new emojis to get included.
That was just a funny Illustration for the fact that some users still have "old" smartphones 😉
Don't forget "emoji-to-ascii" in case your grandparent wants to access your website from a CLI....
Thank you for sharing. I don't want to use it in my project because I am lazy to add those redundant lines of code
Great article!
I implemented this method on my 11ty personal website and it doesn't require client-side js as I parse them during build time.
Thanks for this tool.
Nice trick,Best of Japanese Emoticons
getkaomoji.com/best-of-japanese-em...