惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
V2EX
小众软件
小众软件
GbyAI
GbyAI
B
Blog RSS Feed
月光博客
月光博客
A
About on SuperTechFans
Microsoft Security Blog
Microsoft Security Blog
Blog — PlanetScale
Blog — PlanetScale
U
Unit 42
云风的 BLOG
云风的 BLOG
P
Proofpoint News Feed
Recent Announcements
Recent Announcements
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Vercel News
Vercel News
F
Fortinet All Blogs
Apple Machine Learning Research
Apple Machine Learning Research
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
雷峰网
雷峰网
Google DeepMind News
Google DeepMind News
MongoDB | Blog
MongoDB | Blog
Engineering at Meta
Engineering at Meta
aimingoo的专栏
aimingoo的专栏
博客园_首页
G
Google Developers Blog

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
How Emoji Mashups Work — And Why There's No "Algorithm" B...
monkeymore s · 2026-04-27 · via DEV Community

Ever wondered what happens when you smash 😂 and 🔥 together? You get a laughing face literally on fire. But here's the thing most people don't realize: Emoji Kitchen isn't doing real-time image processing. There's no AI model stitching stickers together on the fly, no Canvas API blending layers, no clever graphics algorithm running in your browser. The "magic" is actually a massive lookup table and a dead-simple frontend. Let me show you how this thing actually works under the hood.

The Big Surprise: It's Just a Really Big JSON File

When you open an Emoji Kitchen browser like Emoji Monkey, the very first thing it does is fetch a single JSON file — metadata.json — weighing in at a few megabytes. That file contains the entire universe of possible combinations. Every single mashup Google has ever drawn is already pre-defined in there.

The frontend doesn't generate anything. It doesn't blend images. It doesn't even know what the final sticker looks like until it loads a PNG from Google's CDN. All it knows is: "If the user picks emoji A and emoji B, the resulting image lives at this specific URL."

This is fundamentally different from how people imagine it works. You might picture some kind of procedural graphics system layering eyes onto faces or swapping colors in real time. Nope. Every single one of those 100,000+ combinations was hand-crafted by Google's design team. The code just looks up which ones exist.

Why Keep It Purely Frontend?

This architecture makes total sense once you think about it:

  • Zero server costs: You're not renting GPUs to run diffusion models or paying for image processing. You're serving a static JSON and some JavaScript.
  • Instant interaction: No round-trips to a backend mean selecting an emoji updates the UI in milliseconds.
  • Privacy by default: Nothing you search or select ever leaves your device. There's no analytics endpoint receiving your emoji preferences.
  • Offline-capable: Once that JSON is cached, the whole app works without internet (except for loading the actual PNG images).
  • Simple deployment: It's just a static site. Throw it on any CDN and it works globally.

The Data Structure That Powers Everything

The metadata.json deserialized into memory looks like this in TypeScript:

interface EmojiMetadata {
  knownSupportedEmoji: Array<string>;
  data: {
    [emojiCodepoint: string]: EmojiData;
  };
}

interface EmojiData {
  alt: string;
  keywords: Array<string>;
  emojiCodepoint: string;
  gBoardOrder: number;
  combinations: { 
    [otherEmojiCodepoint: string]: Array<EmojiCombination> 
  };
}

interface EmojiCombination {
  gStaticUrl: string;
  alt: string;
  leftEmoji: string;
  leftEmojiCodepoint: string;
  rightEmoji: string;
  rightEmojiCodepoint: string;
  date: string;
  isLatest: boolean;
  gBoardOrder: number;
}

Enter fullscreen mode Exit fullscreen mode

This structure is elegant in its simplicity. knownSupportedEmoji is just an array of codepoints like 1f602 (😂) and 1f525 (🔥). The data map holds every emoji's details, and critically, its combinations field maps other emoji codepoints to an array of EmojiCombination objects.

Why an array for combinations? Because Google sometimes updates a design. The same pair might have an old version and a newer, better-drawn version. The isLatest flag lets the frontend pick the most current one.

Loading the Metadata

On app startup, this single function runs:

let emojiMetadata: EmojiMetadata | null = null;
let loadPromise: Promise<void> | null = null;

const METADATA_URL =
  "https://raw.githubusercontent.com/xsalazar/emoji-kitchen-backend/main/app/metadata.json";

export async function loadMetadata(): Promise<void> {
  if (emojiMetadata) return;
  if (loadPromise) return loadPromise;

  loadPromise = fetch(METADATA_URL)
    .then((res) => {
      if (!res.ok) throw new Error("Failed to load metadata");
      return res.json();
    })
    .then((data) => {
      emojiMetadata = data as EmojiMetadata;
    });

  return loadPromise;
}

Enter fullscreen mode Exit fullscreen mode

Simple memoized fetch. If the metadata is already loaded, return immediately. If a fetch is in flight, wait for it. Otherwise, kick off the request. The app shows a loading spinner until this resolves.

The Lookup Flow: From Click to Sticker

Here's what happens when you actually use the app:

Notice how there's no "generation" step. The browser doesn't create the image — it just points an <img> tag to a URL Google already prepared.

Rendering the Left and Right Panels

The left panel shows every supported emoji:

export default function LeftEmojiList({
  handleLeftEmojiClicked,
  leftSearchResults,
  selectedLeftEmoji,
}) {
  var knownSupportedEmoji = getSupportedEmoji();

  if (leftSearchResults.length > 0) {
    knownSupportedEmoji = knownSupportedEmoji.filter((emoji) =>
      leftSearchResults.includes(emoji)
    );
  }

  return knownSupportedEmoji.map((emojiCodepoint) => {
    const data = getEmojiData(emojiCodepoint);
    return (
      <ImageListItem
        onClick={() => handleLeftEmojiClicked(emojiCodepoint)}
      >
        <img
          loading="lazy"
          width="32px"
          height="32px"
          alt={data.alt}
          src={getNotoEmojiUrl(emojiCodepoint)}
        />
      </ImageListItem>
    );
  });
}

Enter fullscreen mode Exit fullscreen mode

The right panel is where the "combination logic" lives. When a left emoji is selected, the right panel checks the combinations map to know which emojis are valid partners:

export default function RightEmojiList({
  handleRightEmojiClicked,
  rightSearchResults,
  selectedLeftEmoji,
  selectedRightEmoji,
}) {
  var knownSupportedEmoji = getSupportedEmoji();
  var hasSelectedLeftEmoji = selectedLeftEmoji !== "";
  var possibleEmoji: Array<string> = [];

  if (hasSelectedLeftEmoji) {
    const data = getEmojiData(selectedLeftEmoji);
    possibleEmoji = Object.keys(data.combinations);
  }

  return knownSupportedEmoji.map((emojiCodepoint) => {
    var isValidCombo = true;
    if (hasSelectedLeftEmoji) {
      isValidCombo = possibleEmoji.includes(emojiCodepoint);
    }

    return (
      <ImageListItem
        onClick={() =>
          hasSelectedLeftEmoji && isValidCombo
            ? handleRightEmojiClicked(emojiCodepoint)
            : null
        }
        sx={{
          opacity: !hasSelectedLeftEmoji ? 0.1 : isValidCombo ? 1 : 0.1,
        }}
      >
        <img
          loading="lazy"
          width="32px"
          height="32px"
          alt={data.alt}
          src={getNotoEmojiUrl(emojiCodepoint)}
        />
      </ImageListItem>
    );
  });
}

Enter fullscreen mode Exit fullscreen mode

This is the core "algorithm" in the entire app. If hasSelectedLeftEmoji is false, everything is dimmed to 10% opacity because nothing is selectable yet. Once you pick a left emoji, only emojis present in data.combinations become clickable. That's it.

Displaying the Final Mashup

When both emojis are selected, the app resolves the specific combination:

combination = getEmojiData(selectedLeftEmoji)
  .combinations[selectedRightEmoji]
  .filter((c) => c.isLatest)[0];

// Then renders:
<ImageListItem>
  <img alt={combination.alt} src={combination.gStaticUrl} />
</ImageListItem>

Enter fullscreen mode Exit fullscreen mode

The gStaticUrl points to Google's image servers. An example URL looks something like https://www.gstatic.com/android/keyboard/emojikitchen/.../u1f602_u1f525.png. The browser fetches and displays it like any other image.

Search Without a Search Engine

The search feature is entirely client-side too. It debounces input at 300ms and filters against the alt text and keywords array stored in the metadata:

useEffect(() => {
  if (debouncedSearchTerm.trim().length >= 3) {
    const requestQuery = debouncedSearchTerm.trim().toLowerCase();
    const allEmoji = getSupportedEmoji();
    const results = allEmoji.filter((codepoint) => {
      const data = getEmojiData(codepoint);
      return (
        data.alt.toLowerCase().includes(requestQuery) ||
        data.keywords.some((k) => k.toLowerCase().includes(requestQuery))
      );
    });
    setSearchResults(results);
  } else {
    setSearchResults([]);
  }
}, [debouncedSearchTerm]);

Enter fullscreen mode Exit fullscreen mode

No Algolia, no Elasticsearch, no backend API. Just Array.filter on an in-memory array. It's fast because even with thousands of emojis, modern JavaScript can filter arrays in microseconds.

Randomization: Just Picking from the Lookup Table

The "randomize" buttons aren't generating random combinations algorithmically. They're picking random entries from the existing data:

const handleFullEmojiRandomize = () => {
  const knownSupportedEmoji = getSupportedEmoji();
  const randomLeftEmoji =
    knownSupportedEmoji[
      Math.floor(Math.random() * knownSupportedEmoji.length)
    ];

  const data = getEmojiData(randomLeftEmoji);
  const possibleRightEmoji = Object.keys(data.combinations);

  const randomRightEmoji =
    possibleRightEmoji[
      Math.floor(Math.random() * possibleRightEmoji.length)
    ];

  setSelectedLeftEmoji(randomLeftEmoji);
  setSelectedRightEmoji(randomRightEmoji);
};

Enter fullscreen mode Exit fullscreen mode

Pick a random left emoji, then pick a random key from its combinations object. That's the whole trick. Every "random" mashup is guaranteed to exist because it only picks from entries already in the JSON.

The Emoji Images: Noto Emoji SVGs

For displaying the individual emojis in the left and right lists (not the mashups), the app uses Google's open-source Noto Emoji font. It constructs a raw GitHub URL to fetch the SVG directly:

export function getNotoEmojiUrl(emojiCodepoint: string): string {
  return `https://raw.githubusercontent.com/googlefonts/noto-emoji/main/svg/emoji_u${emojiCodepoint
    .split("-")
    .filter((x) => x !== "fe0f")
    .map((x) => x.padStart(4, "0"))
    .join("_")}.svg`;
}

Enter fullscreen mode Exit fullscreen mode

This strips out the variation selector (fe0f) and pads codepoints so a9 becomes 00a9 for consistency with Noto's filename convention. The result is a crisp SVG for every emoji in the picker.

What This Architecture Teaches Us

There's a common instinct among developers to reach for complex solutions: machine learning models, serverless functions, image processing pipelines. Emoji Kitchen is a great reminder that sometimes the best engineering is a well-structured lookup table.

Google's designers did the hard work — drawing 100,000+ unique stickers. The frontend's job is just to navigate that catalog efficiently. By pre-computing every possible output and shipping the index as JSON, you get:

  • Sub-millisecond "computation" (it's just a hash lookup)
  • Infinite scalability (static files on a CDN)
  • Zero maintenance for the combination logic
  • Perfect reproducibility (the same inputs always point to the same URL)

Try It Yourself

Browse the full catalog of over 100,000 emoji combinations at Emoji Monkey. Search for your favorites, find the weirdest mashups, and copy them straight to your clipboard — everything happens right in your browser, no data sent anywhere.