Emoji are zero cost resources for websites on most devices and have the benefit of matching the users expectations of iconography across the system, not to mention being accessible by default.
It’s really a win win of size reduction, consistency and accessibility.
The only competitive systems are something like font-awesome icons or SFSymbols. The latter isn’t available to sites afaik though.
There's no consistency, because different operating systems and web browsers display emoji differently, and emoji availability depends crucially on the OS or browser version.
The consistency is that if you use a (mushroom) emoji as an icon for your stuff, users on Windows will immediately know what it is because they are aware of how the emojis on their OS work. Same with Android, iOS, etc. Not that all emojis are the same across all devices.
This is less consistent than images, which are generally rendered the same on all devices. Worse, though, is the broken black boxes that appear when someone uses a newer emoji that your browser or operating system version doesn't yet support, which happens all of the time.
> Not sure why you're being so argumentative about a misunderstanding of definitions?
There's no misunderstanding of definitions. The argument is about whether emojis are "really a win win". I don't think they are, for reasons I've explained. Specifically, with regard to needing icons for "berries and maybe more vegetables", you can already do this with small jpgs that would not take much bandwidth, and in general there's more consistency in jpg support across different software then there is in emoji support.
Waiting for the Unicode committee to add emoji for every possible object in the world seems like madness to me.
I’m not sure why you’re struggling with this concept.
It is consistent for the user on whatever system they are on. If they switch between apps, they see the same emoji that they’re familiar with.
The web developer doesn’t have to care what the icon looks like. They just say: use this emoji that semantically means “flower”. They know it may look different to other users but it will look like what that individual user is familiar with.
> I’m not sure why you’re struggling with this concept.
I'm not struggling with any concept.
It's a simple fact that as emojis continually get added to Unicode, not all browsers and operating systems support all emoji, and so one person sees a broken black box where another person sees the emoji. That's gross inconsistency.
> So let’s not use html either because someone can clutch pearls all day that some ancient browser on some EOL system might not support a specific new html tag.
Ancient? The submitted article is "New emojis in 2023-2024" about "the draft emoji candidates up for approval by Unicode this September". Thus, no software even supports the new emoji yet, and ironically they have to use png images to show what the emoji will look like.
I'm done talking with you. This is getting too ridiculous. Moreover, your "pearl clutching" remarks are stepping over the line and violating the HN guidelines: https://news.ycombinator.com/newsguidelines.html
Emojis are great as quick icons that take zero work to source, add in, align with text in the layout and size consistently.
Absolutely nothing wrong with that, especially since people on hn love to complain about inclusion of unnecessary assets in websites that could be more lightweight.
Hh sure I even like to create some. But for this purpose I do not bother. I need something small that I can just use for personal purpose. It works well with outdoor internet - where it is used. Adds bit of accent on minimal site to ease the navigation.
I do not really care if they add more veggies etc. I mentioned it as user-case in context of adding random Emojis.
