DEV Community: Martin Rodriguez

Parsing markdown tables in 20 lines (because remark was overkill)

Martin Rodriguez — Mon, 29 Jun 2026 14:45:08 +0000

On Hacé Cuentas (hacecuentas.com) I render 1,200+ pages of user-facing explanation text from JSON content. Every page has at least one markdown table — tax brackets (like the Monotributo 2026 categories), conversion tables, BMI ranges, dose schedules.

For a long time my tables looked like this:

TasaQué esPara qué sirve
|---|---|---|
TNATasa Nominal Anual (sin capitalización)Lo que te muestra el banco

Ugly, right? The markdown pipes weren't rendering as a proper HTML table. Cells concatenated without separation. The separator row showed up as literal text.

The bug was in my hand-rolled markdown function:

.replace(/^\\| (.+) \\|$/gm, (match) => {
  const cells = match.slice(2, -2).split(' | ');
  return '<tr>' + cells.map((c) => `<td>${c}</td>`).join('') + '</tr>';
})

It generated <tr><td>…</td></tr> per line, but never wrapped them in <table>. Without <table>, browsers render <tr> inline as text. Cells mash together. The separator |---|---|---| stays as plain text because it doesn't match the regex.

Why not just use remark?

I considered adding remark + remark-parse + remark-html + remark-gfm (for tables). That's:

4 packages
~180 KB of dependencies
A plugin system I'd have to learn
Build time overhead per page

For a site where markdown is a side feature (the main thing is the calculator widget), this felt like killing a fly with a bazooka.

The fix: detect table blocks, not rows

Instead of processing each row in isolation, match the entire table block (header + separator + rows) in one regex:

function md(text) {
  // Process markdown tables as blocks first
  text = text.replace(
    /^(\\|.+\\|)\\n(\\|[-:| ]+\\|)\\n((?:\\|.+\\|\\n?)*\\|.+\\|)/gm,
    (_, headerLine, _sep, bodyBlock) => {
      const hCells = headerLine.slice(1, -1).split('|').map(s => s.trim());
      const rows = bodyBlock.split('\\n').filter(Boolean).map(row => {
        const cells = row.slice(1, -1).split('|').map(s => s.trim());
        return '<tr>' + cells.map(c => `<td>${c}</td>`).join('') + '</tr>';
      });
      return '<table><thead><tr>' +
        hCells.map(c => `<th>${c}</th>`).join('') +
        '</tr></thead><tbody>' + rows.join('') + '</tbody></table>';
    }
  );

  return text
    .replace(/^### (.+)$/gm, '<h3>$1</h3>')
    .replace(/^## (.+)$/gm, '<h2>$1</h2>')
    .replace(/\\*\\*(.+?)\\*\\*/g, '<strong>$1</strong>')
    .replace(/\\[(.+?)\\]\\((.+?)\\)/g, '<a href="$2">$1</a>')
    .replace(/\\n\\n/g, '</p><p>')
    .replace(/\\n/g, '<br>');
}

That's it. 20 lines of JavaScript, no dependencies.

Breaking down the regex

/^(\\|.+\\|)\\n(\\|[-:| ]+\\|)\\n((?:\\|.+\\|\\n?)*\\|.+\\|)/gm

^(\\|.+\\|) — capture the header line (e.g., | Col 1 | Col 2 |)
\\n — newline
(\\|[-:| ]+\\|) — capture the separator (|---|---|, supports alignment colons too)
\\n — newline
((?:\\|.+\\|\\n?)*\\|.+\\|) — capture one or more data rows. The \\n? on intermediate rows handles trailing newlines; the final \\|.+\\| matches the last row without requiring a trailing newline.

The gm flags make it match across the full document, anchored to line starts.

Edge cases it handles

Tables with any number of columns
Bold/italic inside cells (processed after, by the inline replacements)
Tables separated from surrounding text by blank lines
Tables anywhere in the document (not just at the start)

Edge cases it doesn't handle (on purpose)

Escaped pipes \\| inside cells — I never use them, so not worth the regex complexity
Multi-line cells — same reasoning
Cell alignment (:---: for center) — could add text-align parsing if needed, but my CSS handles defaults fine

CSS to make it pretty

The generated <table> inherits global styles. In my case:

.explanation table {
  border-collapse: collapse;
  margin: 1rem 0;
  width: 100%;
  border-radius: 8px;
  overflow: hidden;
  border: 1px solid var(--border);
}

.explanation th {
  padding: 0.625rem 0.875rem;
  border-bottom: 2px solid var(--border);
  font-weight: 600;
  text-align: left;
}

.explanation td {
  padding: 0.625rem 0.875rem;
  border-bottom: 1px solid var(--border);
  color: var(--text-muted);
}

.explanation tr:last-child td {
  border-bottom: none;
}

Why this matters

When you're shipping a static site with Astro or 11ty or Eleventy, dependency weight adds up. Every package in your build chain is another thing that can break, another thing to update, another 50ms of cold-start time.

For "I need basic markdown rendering," a 30-line function beats a 180KB dependency tree. Measure the actual pain before reaching for the library.

Source code is MIT-licensed: grblasquiz/hacecuentas — src/pages/[...slug].astro, lines ~27-50.

The full markdown function (with lists, links, code, headings) is under 30 lines total. If you need tables in an Astro content collection and don't want to pull remark, copy it.

Live demo: check any calculator on hacecuentas.com (e.g., calculadora de plazo fijo) — scroll down to "Cómo funciona" to see tables rendered from JSON markdown.

How I built 1,200+ calculator pages in Astro without writing 1,200 templates

Martin Rodriguez — Tue, 09 Jun 2026 20:11:11 +0000

I run Hacé Cuentas, a free collection of 4,100+ Spanish-language calculators. What started as 10 hand-built pages turned into thousands of routes — and the codebase is actually smaller than when I had 50.

Here's how Astro's content collections + dynamic routes made it possible.

The problem

Every calculator needs:

Inputs (each with labels, validation, hints)
A formula
Explanation text (markdown, often 2,000+ words for SEO)
FAQ (minimum 7 questions for depth)
Related calcs
schema.org JSON-LD (HowTo + FAQPage + SoftwareApplication + Article + BreadcrumbList)
Sources and citations

If I wrote one template per calc, every change (layout tweak, new CTA, CSS fix) would mean touching every calc file by hand.

The approach

One JSON per calc. One template for all.

Step 1: Content collection

src/content/calcs/plazo-fijo.json
src/content/calcs/imc.json
src/content/calcs/aguinaldo-sac.json
...

Each JSON looks like:

{
  "slug": "calculadora-plazo-fijo",
  "title": "Calculadora Plazo Fijo 2026 Argentina",
  "h1": "Calculadora de plazo fijo",
  "description": "...",
  "category": "finanzas",
  "formulaId": "plazo-fijo",
  "fields": [
    { "id": "capital", "label": "Capital", "type": "number", "format": "thousands" },
    { "id": "tna", "label": "TNA", "type": "number", "suffix": "%" },
    { "id": "dias", "label": "Días", "type": "number", "default": 30 }
  ],
  "outputs": [
    { "id": "montoFinal", "label": "Monto final", "format": "currency", "primary": true },
    { "id": "interesGanado", "label": "Intereses", "format": "currency" }
  ],
  "faq": [ /* ... */ ],
  "explanation": "## Cómo rinde un plazo fijo\n\n..."
}

Step 2: Dynamic route

---
// src/pages/[...slug].astro
export async function getStaticPaths() {
  const calcs = import.meta.glob('../content/calcs/*.json', { eager: true });
  return Object.values(calcs).map((mod) => {
    const c = mod.default;
    return {
      params: { slug: c.slug },
      props: { calc: c },
    };
  });
}

const { calc } = Astro.props;
---

<Layout title={calc.title}>
  <Calculator config={calc} />
  <Explanation markdown={calc.explanation} />
  <FAQ items={calc.faq} />
</Layout>

That's it. Adding a new calculator = adding one JSON file. Build time: +8ms per calc.

Step 3: Formulas as separate TypeScript modules

I keep the actual math separate because JSON can't hold functions:

// src/lib/formulas/plazo-fijo.ts
export interface Inputs { capital: number; tna: number; dias: number }
export interface Outputs { montoFinal: number; interesGanado: number; /* ... */ }

export function plazoFijo(i: Inputs): Outputs {
  const interesGanado = i.capital * (i.tna / 100) * (i.dias / 365);
  return {
    montoFinal: Math.round(i.capital + interesGanado),
    interesGanado: Math.round(interesGanado),
    // ... TEA, daily interest, etc
  };
}

The Calculator.astro component imports all formulas via import.meta.glob, maps them by formulaId, and runs the right one on form submit.

What I learned

1. JSON for content, TS for logic

Don't force everything into one format. JSON is great for structured content (fields, labels, FAQ), terrible for functions. Keeping them separate means non-coders can add calcs by editing JSON, and the formulas stay type-safe.

2. Schema.org multiplies "for free"

One JSON feeds several structured data blocks: SoftwareApplication, Article, BreadcrumbList, Dataset. Generating them from the same source means every page ships rich structured data with zero extra authoring work. (See a live calc.)

3. Markdown in JSON is fine

Yes, escaping \n in JSON is ugly. But having everything in one file (field definitions, explanation, FAQ, schema) is worth it. A simple markdown-to-HTML function at build time handles rendering:

function md(text: string): string {
  return text
    .replace(/^### (.+)$/gm, '<h3>$1</h3>')
    .replace(/^## (.+)$/gm, '<h2>$1</h2>')
    .replace(/\*\*(.+?)\*\*/g, '<strong>$1</strong>')
    // ... tables, links, code, etc
    .replace(/\n\n/g, '</p><p>');
}

No MDX, no Remark/Rehype pipeline. Just a 30-line function. Fast and debuggable.

4. Client-side rendering for the calc only

The entire page is static HTML at build time. Only the calculator widget hydrates with a tiny JS bundle. Lighthouse performance: 100. First Contentful Paint: 0.3s on 3G.

5. One page template = consistent UX

Every calc has the same layout: inputs on top, results card, explanation, FAQ, related. Users never have to relearn where things are. This also makes it trivial to A/B test layout changes — one file change propagates to every calc page.

Numbers (today)

Pages generated: thousands (calcs + blog + tables + comparators + per-province + 3 languages)
Build: static on Cloudflare Pages, Lighthouse perf 100
Source: a few thousand lines of Astro/TS + the bulk of the repo is JSON content
Adding a new calc: ~30 minutes (writing the JSON + formula, 0 min templating)

When this approach breaks down

Highly variable layouts: if each calc needs a dramatically different UI (3D visualizations, custom interactions), one template doesn't cut it.
Heavy client-side state: works for stateless calculators. Not for something like a multi-step tax filer with progress persistence.
Extreme i18n: I have Spanish + English; adding 20 languages would require a different architecture (content per locale per calc).

For typical calculators, though — input → formula → output → explanation — this pattern scales to thousands of pages without codebase bloat.

Source

Repo: grblasquiz/hacecuentas
Live: hacecuentas.com

Happy to answer questions about the architecture or share specific JSON/formula examples.

title: "How I built 3,400 calculators as a single Astro site on Cloudflare Pages"

Martin Rodriguez — Wed, 03 Jun 2026 17:49:23 +0000

The project
A while back I started Hacé Cuentas, a calculator site for the Spanish-speaking market — taxes, salaries, health, finance, cooking, whatever people google. It's now ~3,400 calculators in three languages (es/en/pt), all statically rendered, on Cloudflare Pages. One repo, one Astro project.

Here's what scaling a content site past a few thousand pages actually taught me — including the wall I hit at ~64 MiB that nearly killed a deploy without telling me.

One route, thousands of pages
Every calculator is two files:

src/content/calcs/.json — content: title, intro, FAQ, SEO metadata, input fields.
src/lib/formulas/.ts — logic: a pure function (inputs) => result.
Splitting content from logic is the decision that paid off most. Content edits never risk breaking math, the formulas are unit-testable in isolation, and — as you'll see below — the JSON's modification time becomes a clean freshness signal for SEO.

A single dynamic route renders all of them:

// src/pages/[...slug].astro
export async function getStaticPaths() {
const calcs = await getCollection('calcs');
return calcs.map((calc) => ({
params: { slug: calc.slug },
props: { calc },
}));
}
Astro content collections validate every JSON against a Zod schema at build time. That schema once caught 25 malformed files before they ever shipped — at this volume, build-time validation isn't optional.

The 64 MiB wall
Cloudflare Pages runs SSR/functions on Workers, and the bundled Worker has a hard size ceiling. I blew past it (~64 MiB) by importing big lookup data into the SSR path. The nasty part: the deploy reported success. wrangler returned OK, but the edge silently kept serving the old worker. I "deployed" three times wondering why nothing changed.

Lesson: at scale, "deploy succeeded" ≠ "it's live." Always verify the live edge content, not the CLI log. The fix was keeping heavy data out of the worker bundle and pre-rendering everything possible to static HTML.

Build OOM (exit 137)
Building 3,400 pages × 3 languages OOM-kills Node. The counterintuitive bit: cranking the heap can make it worse, because the OS OOM-killer steps in. What actually stabilized it was NODE_OPTIONS=--max-old-space-size=8192 plus reducing concurrent memory pressure during the build (don't run a content sweep and the build at once — they collide).

node:fs silently breaks SSR on workerd
Cloudflare's runtime (workerd) is not Node. Importing node:fs in an Astro page compiles fine and explodes at the edge. Worse: astro dev serves from a Node server, so it does not reproduce workerd — some bugs only appear in production. I now verify anything filesystem-adjacent (OG images, etc.) on prod, never trusting dev.

SEO at scale: don't churn your sitemap
The least obvious lesson, and the most important at this size. With thousands of URLs, lastmod is a signal Google trusts — until you abuse it. Regenerate lastmod = today for all 3,400 URLs on every deploy and Google burns crawl budget re-checking unchanged pages, then starts ignoring the signal entirely.

So I compute it from the content itself:

lastmod = max(lastReviewed, dataUpdate.lastUpdated, mtimeOf(jsonFile))
A URL's lastmod only moves when its real content changes. I can deploy 10× a day and the sitemap stays still unless I actually edited something. Your sitemap is a budget you spend — don't waste it on cosmetic diffs.

Bonus: charts without crawl waste
Each formula can return an output._chart (donut/gauge/scale) rendered client-side with Chart.js. Because that config lives in the .ts formula, not the content JSON, adding charts to hundreds of calculators moved exactly zero lastmod values. New feature, no sitemap churn.

Takeaways
Separate content from logic — it compounds at scale.
Trust the platform's real runtime, not your dev server.
"Deploy succeeded" ≠ "live and correct." Verify the edge.
Your sitemap is crawl budget. Spend it only on real changes.
Live site is https://hacecuentas.com if you want to see ~3,400 of these in the wild. Happy to dig into any Astro/Cloudflare detail in the comments.