DEV Community: yunjie

The Share Button Is the Product: Engineering a Viral Loop in Vanilla JS

yunjie — Sun, 05 Jul 2026 14:22:34 +0000

Most of us treat the share button as the last checkbox before shipping: drop in a navigator.share call, maybe a Twitter intent URL, done. I did that too, until I built a personality quiz — and realized the share path is the product. Nobody needs a quiz result for themselves. The entire reason these things spread (remember the Soldier-Poet-King wave?) is that the result exists to be shown to other people.

So when I built a Prince / Bandit / Mage quiz riding this year's animated-MV meme, I flipped my usual priorities. The quiz engine took an afternoon. The share funnel took a week. This post is about that week: encoding results into URLs with no backend, drawing Instagram-ratio share cards on a canvas, and a handful of small decisions that only matter once you assume every visitor arrived from someone else's screenshot.

One constraint up front, because it shaped everything: the whole site is static. No server, no database, no build step, no framework. The quiz engine is one IIFE in a single vanilla JS file. Everything below happens in the browser.

A result page that doesn't exist

The first problem with a serverless quiz: what URL do you share? There's no /results/abc123 because there's no database to put abc123 in.

The answer is old and unglamorous: the URL hash. When the quiz finishes, the full result gets encoded into the fragment and stamped onto the current URL without a navigation:

var params = "result=" + key + "&p=" + score.prince +
             "&b=" + score.bandit + "&m=" + score.mage;
history.replaceState(null, "", "#" + params);

That one line buys a lot. Reload the page and an IIFE at the bottom of the file parses the hash and re-renders the exact result — same archetype, same percentage bars — without replaying fifteen questions. Copy the URL to a friend and they see your result, not a landing page.

The restore path has to be paranoid, though, because hashes are user-editable. Anyone can type #result=mage&p=99&b=0&m=0. So the restore function validates that the three scores sum to exactly the question count; if they don't, it keeps the claimed archetype but swaps in a neutral fallback distribution. Tampered links still render something sane — and a hand-typed #result=mage&p=0&b=0&m=0 doesn't divide by zero into a page of NaN bars.

The share links don't point at the quiz

Here's the decision I'd defend hardest. The social share buttons — X, Reddit, Tumblr, WhatsApp, Facebook — do not share the quiz URL with the hash. They share one of three static landing pages, one per archetype:

function shareUrl(key) {
  return location.origin + "/result/" + key + "/";
}

Why? Three reasons that only became obvious after thinking of shares as inbound doors rather than outbound exits:

Crawlers can't see hashes. A shared quiz/#result=bandit link gives every social platform the identical generic preview. A real /result/bandit/ page gets its own title, description, and OG image — the unfurl card in the feed is the advertisement.
Search engines can index them. Three static pages targeting "prince bandit mage quiz [archetype]" queries cost nothing and catch people searching after seeing a friend's result.
The landing page can pitch the quiz. Someone clicking a friend's result doesn't want your fifteen answers replayed — they want to know what the thing is and take it themselves. Different job, different page.

The hash-URL still exists for the "copy link" button, where the receiver is a friend who genuinely wants to see your exact mix. Two share paths, two audiences, deliberately not unified.

The result has to feel unrepeatable

A share loop dies if two friends compare results and they're identical. With three buckets and fifteen questions, collisions are guaranteed — so the trick is layering enough variation that the rendered result almost never repeats.

Scoring itself is a naive tally, but the tie-break is opinionated. Rather than Math.max order or randomness, ties resolve toward the rarer archetype, implemented as nothing more than iteration order plus >=:

function winnerOf(score) {
  // tie-break order favors the rarer archetype: mage > bandit > prince
  var best = "prince";
  ["bandit", "mage"].forEach(function (k) {
    if (score[k] >= score[best]) best = k;
  });
  return best;
}

If you're torn between the crowd-pleaser and the weird one, you get the weird one. Rare results get shared more; the tie-break quietly feeds the loop.

The bigger lever is what I called the undercurrent: a second reading based on your runner-up archetype. Six winner+secondary combinations each get distinct copy ("there's a Bandit riding in your verse..."), and when the secondary scores 3 or fewer out of 15 — nearly all answers pointing one way — it's replaced by a rare "pure verse" variant instead. That's nine narrative outcomes multiplied by a unique percentage mix, from a scoring function that's ten lines long. The variety lives in the copy, not the algorithm, and copy is cheap.

Drawing the screenshot for them

People don't share links on Instagram; they share images. So the result screen renders a 1080×1350 share card (Instagram's portrait ratio) on a client-side canvas: radial-gradient parchment background, the tarot-style card art clipped through an arcTo rounded-rect path, the archetype name drawn onto a blank banner baked into the artwork, and three mini bars showing your percentage mix.

Canvas text rendering taught me two things the hard way:

Fonts load late. Draw before your webfont arrives and the canvas silently uses the fallback — the PNG looks off and no error tells you why. The fix is gating the entire draw on document.fonts.ready. It's a promise; await it, then paint.

Art and text have to agree on coordinates. Each card's artwork has its empty banner at a slightly different height, so each archetype carries its own bannerY ratio (0.846, 0.868, 0.848) and the name is drawn at cy + ch * bannerY. Hardcoding one offset looked fine on one card and misaligned on the other two.

The finished card goes through canvas.toBlob and gets cached, so when someone taps share, navigator.share can attach it as an actual image File — checked via navigator.canShare({ files: [...] }) first. No Web Share support? Fall back to downloading the PNG plus a copy-caption button. The user should never dead-end.

The pixel-level stuff that isn't optional

Last one, small but load-bearing: when the result appears, the card art must already be there. A placeholder flashing into a tarot card reads as jank, and jank on the money screen taxes the exact moment you want screenshotted.

Two-part fix. First, the moment the quiz starts, all three card images get preloaded — fifteen questions is plenty of time to fetch three webp files. Second, the reveal itself is gated on the decoder, not the network:

if (emblem.decode) {
  emblem.decode().then(reveal, reveal);
}

img.decode() resolves only after the image is fully decoded and paintable, so the result section stays hidden until the correct art can render in the same frame it appears. (Both promise branches call reveal — a broken image should degrade, not brick the page.) The percentage bars then animate via a double requestAnimationFrame, because setting a width and transitioning it in the same frame gets batched into no transition at all.

What I'd take away

None of this is hard engineering — it's a few hundred lines of vanilla JS with no dependencies. What changed for me was the frame: for anything designed to spread, the share path deserves the same rigor as the core feature. Encode state where crawlers and friends can both use it, ship the unfurl page separately from the app page, and draw the screenshot yourself instead of hoping users take a good one.

If you want to see the loop end to end, take the quiz and watch what the share modal hands you. I got The Mage, apparently. The tie-break may have been involved.

I built firsttripchina.com — a China travel guide written by someone who lives here

yunjie — Wed, 29 Apr 2026 13:55:25 +0000

👋 Hey dev.to — I just shipped firsttripchina.com, a practical China travel guide written by someone who actually lives in China (me — Yunjie, a software engineer in Chengdu).

It's a content site for first-time foreign visitors, covering the friction points existing English-language China resources consistently get wrong: the 240-hour visa-free transit policy, how to register Alipay with a foreign card, the real-name attraction booking
system, and structured city itineraries (4-day Beijing, 3-day Zhangjiajie, Beijing → Xi'an by
HSR). No tour packages. No affiliate scams. Free to read, no signup.

## Why I built it

Every Western friend who's ever told me they were planning a China trip sent me the same five questions:

"Will my Visa card actually work?"
"Do I need a VPN?"
"Is the high-speed rail bookable in English?"
"How do I book Forbidden City tickets?"
"Do I need a tour, or can I do it solo?"

The English-language China travel internet is in a strange state. Lonely Planet's last meaningful update to its China chapter was years ago. TripAdvisor's China forum is full of well-intentioned travelers giving each other 2018 advice. The big content sites (Travel China Guide, China Highlights) are mostly OTA fronts pushing tour packages.

None of them know that the 240-hour visa-free policy expanded in late 2024, that Alipay now accepts foreign cards but with a ¥200 single-transaction limit and 3% fee, or that buying a Forbidden City ticket requires a real-name passport-linked booking 7 days in advance. I write Markdown for fun, I have a Vercel account, so I built the version I wished
existed.

## The tech stack (briefly)

Stack is React 19 + Vite + TypeScript on the frontend, Vercel Functions + Neon Postgres on the backend, deployed on Vercel.

The "obvious" content-site setup is content/posts/*.md parsed at build time — Astro or Hugo would have been the textbook answer. I went with Postgres rows for content because I want to edit from a hosted admin UI, not commit-and-deploy. The tradeoff is real (you can't git diff a content edit), but for a solo project the speed of "open admin, edit, save"
beats the audit trail.

For SEO I prerender the SPA to static HTML at build time — Puppeteer pulls every published slug from Postgres, visits each URL on a local vite preview server, and writes the rendered HTML into dist/<path>/index.html. Vercel then serves the static HTML before falling back to the SPA. This took longer than expected to get running on Vercel's build
container (you need puppeteer-core + @sparticuz/chromium, not regular Puppeteer, because the container doesn't ship the shared libraries Chromium expects). Each route runs through a usePageSeo hook that imperatively injects per-route <title>, meta tags, canonical, and JSON-LD, so prerender captures complete SEO HTML for every page.

The result: every page on the site lands in Google's index as static HTML — important, because Googlebot only executes JavaScript ~70% of the time on first crawl.

## What's currently live

12 destination pages (Beijing, Shanghai, Suzhou, Hangzhou, Zhangjiajie, Chengdu, plus more) and 8+ deep-dive blog posts.

Coming soon: Xi'an, Guilin, Yunnan destinations; a China high-speed rail master guide; a DiDi (rideshare) walkthrough for foreign passport holders.

The site is at firsttripchina.com — browse the destinations or blog and take a look.

I built a privacy-first PDF dark mode converter that runs entirely in your browser

yunjie — Sat, 25 Apr 2026 08:58:01 +0000

TL;DR: I shipped pdfdark.org — a browser-side PDF dark mode converter. Files don't get

uploaded; the entire conversion happens in your browser via PDF.js + a Web Worker. Open source (MIT), free, no signup.

Why I built this

Reading long PDFs at night was killing my eyes. The two paths I had both sucked:

Existing "dark mode PDF" web tools → required uploading the file. For research papers, contracts, medical records

— that felt sketchy. No way to verify what they did with my data.

OS-level "invert colors" → wrecked photos and charts. Faces became X-rays. Graphs became noise.

So I built one with two non-negotiable defaults:

Nothing leaves your browser. PDF.js parses the file, a Web Worker does the dark-mode pass, pdf-lib stitches the

result. Verify it yourself in DevTools → Network.

Images keep their original colors. A saturation classifier detects photos and figures and leaves them untouched

while it darkens text and UI.

How it works

Drop PDF

→ PDF.js renders pages to canvas

→ Web Worker classifies each pixel by saturation

├─ saturated pixels (images, charts) → preserved

└─ low-saturation pixels (text, UI) → themed

→ pdf-lib assembles a new PDF

→ User downloads

The classifier runs on OffscreenCanvas inside a Web Worker, so the UI thread never blocks on large PDFs.

Output is a real PDF (image-based, one JPEG per page), so the dark mode persists when you email it, sync it to iPad, or

open it on a Kindle. Not a viewer toggle.

What it cost to ship

Domain: $7.50 (Cloudflare Registrar, .org)
Hosting: $0 (Vercel free tier)
Email forwarding: $0 (Cloudflare Email Routing)
Error monitoring: $0 (Sentry free tier, errors only with full content masking)
Time: a few weekends

Total cost: $7.50.

What I'm watching

Whether the "no-upload" angle resonates beyond privacy nerds
Edge cases that break the algorithm (weird embedded fonts, scanned PDFs)
Whether to add a vector-preserving mode for text-only PDFs (current output is image-based, so text isn't selectable)