Looking for feedback on a Hugo Module for Twemojis 🎉

Hi everybody!

I’m looking for some feedback on the first module I’ve released publicly, which packages Twitter’s pretty awesome (and open-source) Twemoji library of emojis to serve locally instead of making external calls to their CDN for every single icon.

The incompatibility and/or inconsistency between different OSes (and even browsers) when it comes to emojis, especially newer ones, got pretty tiring… so Twemojis are a fantastic way to standardize them for all visitors. It comes with both 72x72 PNG and vector SVG glyphs (which are much better for multiple reasons) as well as a small JS script that hot-swaps them out, so you can use native emojis as usual when writing content/designing templates. (It also means pages will fall back to regular emojis if a visitor has JS disabled.)

I went arguably a little overboard with emojis on my personal website if you’d like to see Twemojis in action:

Would love any and all feedback on what could be improved. I went back and forth debating whether or not to mount everything in static/ or assets/. I settled on static/twemoji/... but that might have been the wrong call — I see @bep mounts his heroicons module as assets… So if anyone has an opinion on that I’d especially like to hear it.

Hope everyone’s staying safe out there! :slight_smile:


edit: just noticed that Discourse itself uses Twemojis across this site as well, if you need another real-world example :+1:

1 Like

static vs assets depends I guess (you need them assets if you want to inline SVGs etc.); the layout of a module is something I have thought some about, I think the important part is to create some kind of namespace.

One tip: I notice you load the JS script in your partial. You may want to use Scratch or something to check /set that the script has already been loaded.

2 Likes

That’s what I was thinking. If I mount them as assets, there would need to be some awareness at build time for which emojis were used anywhere (aka which SVGs need to be included), which sounds like it’d get complex pretty quickly.

On the other hand, I cringe when I see this module adding 6,000 static files to the outputted site, even if it’s only a few extra MB. Will put some more thought into this… at the very least I’m realizing I should probably mount the script as an asset to allow for minification/bundling/etc via pipes.

Great idea, thanks!

I don’t understand that argument. The benefit of assets is that you only publish what you references via .RelPermalink etc. and it will not get published if you inline it via .Content.

Hmm… The appeal of using Twitter’s JS method is that it swaps emojis for images on the client side. Calling the SVGs as assets in templates like you said would be simple (whether one decides to inline them or not) but I can’t think of a straightfoward way — using pure Hugo, not webpack or something — to parse through all the markdown content for regular emojis and switch them out with Twemoji assets automatically before/during the rendering process?

It just occurred to me that a Twemoji shortcode would be simple to implement but wouldn’t be as seamless for a content author. Will keep brainstorming!

Hi there. First of all thank you very much for this awesome module, which I’m using in my website. Since the emojis are loaded from SVG images, could this be used to load custom icons with some kind of code? Wouldn’t it be great???

Thanks in advance!