Building 10 Developer Tools With Zero Frameworks — And Why

I shipped 10 developer tools on rioges.xyz/tools last week. Every one runs entirely in the browser. No server calls, no signup walls, no cookie banners, no 3MB framework bundle. Just HTML, CSS, and vanilla JavaScript sitting inside an Astro site.

Here’s how I did it, what I’d do differently, and whether this approach still makes sense in 2026.

The Tools

Why Vanilla JS

Every dev tool site in 2026 is either:

1. A React app wrapped in Next.js loading 500KB of JavaScript to format JSON (which is a single JSON.stringify() call)
2. An AI-generated copy-paste that loads three ad networks before showing you an input field

I didn’t want either. The tools are simple — they take input, run a browser API or a small algorithm, and show output. That’s it. The heaviest dependency is Marked.js for the Markdown previewer, loaded via CDN. Everything else is built-in: JSON.parse, btoa/atob, RegExp, crypto.subtle, CSSColor.

The result: each tool page is under 15KB total (HTML + CSS + JS). They load faster than the average cookie consent banner.

Architecture: One Tool, One Page

Each tool lives at src/pages/tools/<tool-name>/index.astro in the Astro project. The pattern is identical for all 10:

---
import PageLayout from "@layouts/PageLayout.astro"

const title = "JSON Formatter & Validator"
const description = "Format, validate, minify, and sort JSON keys instantly..."
const jsonLd = [/* structured data */]
---

<PageLayout title={title} description={description} jsonLd={jsonLd}>
  <style>/* tool-specific CSS */</style>

  <!-- tool HTML -->
  <div class="tool-panel">...</div>

  <!-- FAQ section -->
  <section class="faq">...</section>

  <script is:inline>
    // vanilla JS — no build step, no bundler
    function formatJSON() { ... }
  </script>
</PageLayout>

Key decisions:

• is:inline on the <script> tag. Astro normally hoists and bundles scripts. I don’t want that — these are small, page-specific functions. Inline them, let the browser parse once, done.
• PageLayout wraps everything in the existing site shell (header, footer, nav, Tailwind). No separate tool “app” — it’s just another page on the site.
• Scoped <style> inside each page. No shared CSS file for the tools. Each page is self-contained. If I delete a tool, there’s nothing to clean up.

SEO: The Actual Reason I Built These

Let’s be honest — developer tools are commodity. Anyone can build a JSON formatter. I can’t compete on uniqueness. But I can compete on:

1. Speed. Under 15KB per page vs. 2MB+ for the ad-heavy alternatives. Core Web Vitals matter for ranking.
2. Structured data. Every tool page has both WebApplication and FAQPage JSON-LD schema. Google’s rich results love FAQ schema.
3. Privacy. “No data sent to any server” is a real differentiator when every other tool is scraping your input.
4. Canonical URLs + Open Graph. Each page has a canonical URL, OG tags, and Twitter cards. If someone shares a tool link, it looks right everywhere.

The FAQ schema alone is worth the effort. Each tool has 5 questions with answers. That’s 50 FAQ entries across 10 pages — each one a potential rich result in search.

The JSON-LD Pattern

Every tool page includes two schema objects:

{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "JSON Formatter & Validator",
  "description": "...",
  "url": "https://rioges.xyz/tools/json-formatter/",
  "applicationCategory": "DeveloperApplication",
  "operatingSystem": "Any",
  "offers": { "@type": "Offer", "price": "0", "priceCurrency": "USD" }
}

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Is my JSON data sent to any server?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. All processing happens in your browser..."
      }
    }
  ]
}

The WebApplication schema tells Google this is a free tool. The FAQPage schema gives it questions to show in search results. Together they cover the two main ways these pages get discovered.

What I’d Do Differently

The “10 tools” approach was efficient but shallow. Building 10 tools in parallel means none of them are as deep as a dedicated tool. Regex101 has features I’ll never match — regex explanation, substitution, unit tests. That’s fine. I’m not trying to replace it. I’m trying to show up in search for “json formatter” and “base64 decode” and “jwt decoder” — and those searches don’t need Regex101-level depth. They need a fast, clean answer.

Vanilla JS has limits. The JWT decoder and hash generator both use crypto.subtle which isn’t available in HTTP contexts (only HTTPS). The tools work on the deployed site (HTTPS), but local testing needs to account for this. Not a problem for production, but it caught me during development.

AI can generate these in minutes. That’s the honest take. The moat isn’t the tool itself — it’s the SEO, the speed, the privacy angle, and the fact that these pages are part of a real site with domain authority, not a throwaway Vercel deployment. The tools are the floor, not the ceiling.

The Numbers

Integration With the Astro Site

The tools live under src/pages/tools/ in the existing Astro project. They share the same layout, navigation, Tailwind config, Google Analytics, and footer as every other page on rioges.xyz. The sitemap picks them up automatically.

To add a new tool, I create one .astro file. No routing config, no component library, no state management. One file, one page, done.

Should You Do This?

If you have a personal site and want more search traffic — yes. The cost is low (I built all 10 in a day), the SEO structure compounds over time, and the tools are genuinely useful. Just don’t expect them to be your main traffic driver. They’re a long-term play.

The real value comes from combining tools with content. Write about what you built, how you built it, and why. That content — this post — will probably bring more traffic than the tools themselves.

All 10 tools are live at rioges.xyz/tools. Source code is on GitHub.