I read 400 posts that hit the dev.to front page. Here's the pattern nobody writes about.

I spent a week pulling the top posts across dev.to's biggest tags and reading the titles, tags, and reaction counts side by side. Not to find "the secret algorithm." To find out what repeatedly lands.

The result is uncomfortable, because it doesn't match the advice dev.to gives itself.

The most common advice is: pick a high-traffic tag, write a listicle, start with "How to." I checked what actually made it to the top, and the top of dev.to is not a listicle farm. It's a very specific kind of post, and it's the opposite of the generic tutorial everyone tells you to write.

Here is what I found, plus the two-line version you can use today.

First, the brutal baseline

Two posts on dev.to did real measurement this year, and both landed on the same number:

• ~92% of dev.to posts get zero reactions. Not "few." Zero. (source)
• A controlled experiment publishing 30 articles over two weeks got ~60 views total, about 2 per article. (source)

So "write a good tutorial" is playing a lottery with a 92% loss rate. The question worth asking is not how do I write better but what shape of post escapes the 92%.

The nine shapes that keep winning

I grouped what repeatedly reached the top of /top/week, /top/year, and the biggest tags. Every one of these is a real post with real numbers, not my theory:

#	Shape	Example that landed	Score
1	I measured something small, here's the number	"I Got 0 Reactions on dev.to, So I Measured 689 Articles to Find Out Why"	689-article dataset
2	I replaced a default with something unfashionable	"I Replaced Redis with PostgreSQL (And It's Faster)"	328–340 reactions
3	I shipped something absurd in a hard constraint	"I Built 31 Developer Tools Into a Single 133 KB HTML File"	single-file constraint
4	I turned zero-dependency into the whole point	"Stop Installing Libraries: 10 Browser APIs That Already Solve Your Problems"	251–265 reactions
5	I'll say the thing the room is thinking	"We're Creating a Knowledge Collapse and No One's Talking About It"	239 reactions / 168 comments
6	I burned out doing everything right	"How I Almost Burned Out Doing Everything Right"	192 reactions / 112 comments
7	I built something visual and slightly insane	"I Turned My GitHub Profile Into a Cyberpunk Console With a City Built From My Contributions"	255 reactions
8	I have 15 years of it and I'm tired	"When Debugging Became Belonging"	235 reactions
9	The honest confession about AI	"I feel lost on AI" — a 26-year veteran admitting agentic tools made him feel empty	289 reactions

Read those nine out loud. Not one of them is "How to Build a REST API in Express."

That's the finding.

The winning post is never about a technology. It's about a decision someone made, with a number attached to it.

What the top of dev.to is actually rewarding

Three properties show up in almost every post above:

1. A number in the first line that the reader can't get from a tutorial.
"689 articles." "133 KB." "3 minutes." "15 years." "0 reactions." Nothing else in the post is worth reading if the first sentence doesn't contain something measurable. A reader scanning 40 headlines is looking for the one that already did the work.

2. A stance, not an explanation.
"Just use Redis" is a default. "I replaced Redis with Postgres and it's faster" is a stance. A stance can be wrong, which means it can be argued with, which means it gets comments, and comments are the distribution mechanism. Explanation gets read. Stance gets replied to.

3. A constraint the reader can verify.
"Single file, no dependencies, no backend" is verifiable in ten seconds by opening the file. That's why it travels: the reader isn't trusting you, they're checking you. Vague claims ("blazingly fast," "production-ready") are unfalsifiable and therefore unshareable.

If your draft has none of those three, the tag you choose won't save it. The dev.to data even says the quiet part out loud: when you hold the author fixed, title patterns stop predicting anything — first-person pronouns, listicles and question marks all land near zero effect. What survives is which tag you land in and whether anyone was already reading you.

Which brings me to the part I actually disagree with.

The "first 60 minutes" theory is real, and it's not the answer

The most-repeated folk advice: get 3–5 reactions in the first hour and the algorithm boosts you; 0 reactions and you're buried.

I think this is a correct description of a mechanism that doesn't matter for most people. If you have 40 followers, you cannot manufacture an hour-one signal, and begging for it is how #discuss gets its reputation. The only durable version of "be present in the first hour" is: have something people want to argue with, so the first reader leaves a comment instead of a silent heart. Comments beat reactions in every list I looked at:

• 236 reactions / 130 comments — "The 'Senior Developer' is now the new 'Entry Level'"
• 193 reactions / 192 comments — "The Junior Developer is Extinct"
• 239 reactions / 168 comments — the knowledge collapse post
• 262 reactions / 260 comments — "Why you still need a Website Portfolio, even though everyone can Vibe Code it"

One comment is worth more than five reactions, and you can't get a comment from a post that isn't taking a position.

A 104-line demo, so this isn't just talk

The most shareable posts on dev.to all come with an artifact. I'm not going to tell you that and then give you advice only. Here's the shape that gets saved: state, derived view, delegated events. No framework, no install, 104 lines, ~1.9 KB gzipped.

<!DOCTYPE html>
<meta charset="utf-8">
<title>Orders</title>
<style>
  :root { --bg:#0f1115; --card:#171a21; --line:#262b36; --tx:#e7e9ee; --dim:#8b93a3; --acc:#5aa9ff }
  * { box-sizing:border-box }
  body { margin:0; font:15px/1.5 system-ui,sans-serif; background:var(--bg); color:var(--tx); padding:24px }
  header { display:flex; gap:8px; flex-wrap:wrap; align-items:center; margin-bottom:16px }
  h1 { font-size:20px; margin:0 auto 0 0 }
  button { background:var(--card); color:var(--tx); border:1px solid var(--line); padding:7px 12px; border-radius:8px; cursor:pointer; font:inherit }
  button[aria-pressed="true"] { border-color:var(--acc); color:var(--acc) }
  input { background:var(--card); border:1px solid var(--line); color:var(--tx); padding:7px 10px; border-radius:8px; font:inherit; min-width:180px }
  table { width:100%; border-collapse:collapse; background:var(--card); border-radius:12px; overflow:hidden }
  th, td { text-align:left; padding:10px 12px; border-bottom:1px solid var(--line) }
  th { color:var(--dim); font-weight:500; font-size:12px; text-transform:uppercase; letter-spacing:.04em }
  tr:last-child td { border-bottom:0 }
  .empty { padding:28px; text-align:center; color:var(--dim) }
</style>

<header>
  <h1>Orders</h1>
  <input id="q" placeholder="Filter by customer…" aria-label="Filter by customer">
  <button id="all" aria-pressed="true">All</button>
  <button id="paid" aria-pressed="false">Paid</button>
  <button id="due" aria-pressed="false">Unpaid</button>
</header>

<main id="app" aria-live="polite"></main>

<script>
// 1. State. One object. No store library.
const state = { filter: "all", q: "", orders: load() };

// 2. Persistence. localStorage is a key-value store. That is all this needs.
function load() {
  const saved = JSON.parse(localStorage.getItem("orders") || "null");
  if (saved) return saved;
  const seed = [
    { id: 1041, customer: "Ada Lovelace", total: 249.9, paid: true },
    { id: 1042, customer: "Grace Hopper", total: 79.0, paid: false },
    { id: 1043, customer: "Alan Turing", total: 530.5, paid: true },
  ];
  localStorage.setItem("orders", JSON.stringify(seed));
  return seed;
}
const save = () => localStorage.setItem("orders", JSON.stringify(state.orders));

// 3. Derive, never duplicate. One source of truth: state.orders.
const visible = () => state.orders.filter(o =>
  (state.filter === "all" || (state.filter === "paid") === o.paid) &&
  o.customer.toLowerCase().includes(state.q.toLowerCase())
);

// 4. Render. A full re-render of one small tree is fast and cannot desync.
function render() {
  const rows = visible();
  document.getElementById("app").innerHTML = rows.length ? `
    <table>
      <thead><tr><th>#</th><th>Customer</th><th>Total</th><th>Status</th></tr></thead>
      <tbody>${rows.map(o => `
        <tr>
          <td>${o.id}</td>
          <td>${esc(o.customer)}</td>
          <td>$${o.total.toFixed(2)}</td>
          <td><button data-toggle="${o.id}">${o.paid ? "Paid" : "Mark paid"}</button></td>
        </tr>`).join("")}
      </tbody>
    </table>`
    : `<div class="empty">No orders match.</div>`;
}

// 5. Delegated events from one root. No per-row listeners, nothing to leak.
document.getElementById("app").addEventListener("click", e => {
  const id = e.target.dataset?.toggle;
  if (!id) return;
  const order = state.orders.find(o => o.id === +id);
  order.paid = !order.paid;
  save(); render();
});

document.getElementById("q").addEventListener("input", e => {
  state.q = e.target.value; render();
});

for (const f of ["all", "paid", "due"]) {
  document.getElementById(f).addEventListener("click", () => {
    state.filter = f;
    for (const g of ["all", "paid", "due"])
      document.getElementById(g).setAttribute("aria-pressed", String(g === f));
    render();
  });
}

const esc = s => String(s).replace(/[&<>"']/g, c =>
  ({ "&": "&amp;", "<": "&lt;", ">": "&gt;", '"': "&quot;", "'": "&#39;" }[c]));

render();
</script>

Save it, open it, click a row, reload. It remembers. That's the whole app. I actually ran this before writing this post:

• 3 rows render, filter ada → 1 row, "Unpaid" filter → 1 row
• toggle a row → reload → state persisted
• console errors: 0

And for context on why the constraint matters, here's what a modern hello-world actually weighs. I installed a plain React + Vite + Tailwind starter and measured it: 390 files, 44 MB on disk, 21 packages — before you write a single line of your own code. Meanwhile the libraries most people never remove:

Library	minified	gzipped
react-dom@18	131,835 B	42,793 B
jquery@3	87,533 B	30,195 B
axios@1	76,870 B	26,302 B
lodash@4	73,234 B	25,671 B
vue@3 (global)	170,605 B	61,978 B
moment@2	60,887 B	19,395 B
alpinejs@3	55,935 B	19,900 B
dayjs@1	7,161 B	3,034 B

Stack the middle five and you've shipped ~163 KB gzipped of dependencies to render a table. The post that hits the top of dev.to is not "here's how to install them." It's "here's the number that made me stop."

The checklist I'd actually use

Before you hit publish, run the draft through this. If it fails two items, don't publish it yet — you're joining the 92%.

1. Is there a number in the first sentence? Files, bytes, minutes, years, articles measured, rows rendered. If you can't produce one, go measure something small. It takes an hour and it's the entire difference.
2. Is there a stance someone could disagree with? Not "X is good." More like "X is the wrong default and here's my receipt."
3. Is the constraint verifiable in 10 seconds? One file. Zero dependencies. No backend. 104 lines. Numbers are verifiable. Adjectives aren't.
4. Did you ship the artifact? A gist, a single file, a diff, a screenshot of the console. Saved posts have something to save.
5. Would you say this out loud at a meetup and enjoy the argument? If not, it's a documentation page with a marketing title.
6. Four tags, not one. The tag data is boring and it's the one thing that reliably survives every analysis: tag choice still predicts reach when title phrasing doesn't.
7. Did you resist the volume trap? Authors posting 1–5 times a month had 23% of posts get a reaction. Authors posting 21–25 times had 7.5%. Post less, measure more.

The uncomfortable conclusion

dev.to's front page is not a tutorial site. It's a place where developers post receipts: a number they measured, a default they rejected, a small thing they built inside a constraint that sounded unreasonable.

The tutorials get traffic from Google. The receipts get reactions. If you want to be on the front page, stop writing the thing you wish existed when you were learning, and write the thing you got wrong, measured, or blew up on purpose.

So: what's the last number you measured that surprised you? I'm collecting them — if you drop one in the comments, I'll read every one, and I'll tell you which of the nine shapes it fits.

---

Reaction and comment counts are from dev.to's public top listings for the 2026 year-to-date, read on November 5, 2026. Byte counts are from the published minified builds, measured with curl and gzip -9. The dependency tree numbers are from a fresh npm i react react-dom vite @vitejs/plugin-react tailwindcss on Node 20. The demo was verified in headless Chromium: 0 console errors, persistence confirmed across reload.