Every developer has that moment—you’re deep in a GitHub pull request, reviewing changes to a complex system, and you encounter a Mermaid diagram. Except it’s not a diagram. It’s a code block. Plain text. Indented syntax that you have to mentally parse or copy-paste into the Mermaid Live Editor just to understand what it’s showing.

That frustration was the spark that became Myrmaid.

Today, I’m excited to announce that Myrmaid is live on the Chrome Web Store. But this isn’t just a product launch announcement—this is the story of how a simple annoyance turned into a full-scale browser extension built with enterprise-grade architecture.

The Problem That Wouldn’t Go Away

It started innocently enough. I was reviewing a particularly complex pull request that included several sequence diagrams documenting API interactions. The diagrams were written in Mermaid, which is fantastic—it’s become the de facto standard for diagrams-as-code.

But GitHub doesn’t render Mermaid diagrams automatically. Neither does GitLab. Or Stack Overflow. Or most documentation sites.

So there I was, copying code blocks, opening new tabs, pasting into the Mermaid Live Editor, waiting for it to render, then switching back to my PR to continue reading. For each diagram. Multiple times per day.

I thought: “This is ridiculous. Why isn’t there a browser extension that just… does this automatically?”

I searched. There were a few options, but they either:

  • Required configuration or per-site permissions
  • Had questionable privacy practices
  • Lacked professional-quality rendering
  • Didn’t work consistently across sites
  • Were no longer maintained

I’m a developer. I build things. And I kept thinking about this problem.

The “How Hard Could It Be?” Moment

You know the moment. Every developer has been there. “How hard could it be to build a browser extension that renders Mermaid diagrams?”

Narrator: It was harder than he thought.

But that’s what made it interesting. This wasn’t just about detecting code blocks and calling a rendering library. It was about:

Architecture: How do you build something that works across dozens of different website layouts, markup patterns, and edge cases?

Performance: How do you detect and render diagrams without slowing down page loads or consuming excessive memory?

Privacy: How do you build something that users can trust with access to every webpage they visit?

User Experience: How do you make interactive controls feel natural and intuitive without disrupting the existing page layout?

Security: How do you safely render user-generated content without opening XSS vulnerabilities?

These weren’t trivial questions. And I realized that if I was going to build this, I was going to build it right.

Building the Foundation

I started with the architecture. Not the fun stuff—the foundation.

Dependency Injection

I implemented a comprehensive dependency injection container. Every service, every manager, every processor would be loosely coupled and easily testable. This wasn’t over-engineering—this was recognizing that complex software requires solid patterns.

// Clean, testable, maintainable
const detector = container.resolve('DiagramDetector');
const renderer = container.resolve('DiagramRenderer');

SOLID Principles

Every component followed the SOLID principles. Single Responsibility. Open/Closed. Liskov Substitution. Interface Segregation. Dependency Inversion.

These aren’t buzzwords. They’re the difference between code that’s a joy to maintain and code that becomes technical debt.

Strategy Pattern for Processors

Different diagram types have different quirks. XY charts need quote syntax fixes. Packet diagrams require range normalization. Color syntax needed RGBA conversion for Mermaid v11+.

Instead of one giant renderer with a thousand conditionals, I built a processor registry. Each diagram type gets its own processor. Clean. Extensible. Testable.

The Technical Challenges

Challenge #1: Detection

How do you find Mermaid diagrams across wildly different websites?

GitHub uses <pre><code class="language-mermaid">. GitLab uses different markup. Some sites use <div class="mermaid">. Others use custom elements.

The solution: Multi-pattern detection algorithms that scan for both code blocks and HTML elements, with comprehensive validation to avoid false positives.

Challenge #2: Security

You’re rendering user-generated content from the internet. That’s a massive security surface.

The solution: Comprehensive input sanitization. Content Security Policy compliance. XSS prevention at every layer. Secure DOM manipulation utilities. Regular security audits.

Every piece of content gets sanitized before rendering. No exceptions.

Challenge #3: Performance

Some pages have dozens of diagrams. Large diagrams can be computationally expensive to render. You can’t block the main thread or degrade page performance.

The solution: Concurrent rendering with intelligent queue management. GPU-accelerated pan/zoom. Efficient caching strategies. Tree-shaken bundles to minimize load time.

The result: ~338KB content bundle (including Mermaid.js) with minimal performance impact.

Challenge #4: Interactive Controls

Diagrams need pan, zoom, and minimap navigation. But every website has different layouts, z-indexes, and CSS. How do you add controls without breaking existing pages?

The solution: Shadow DOM for style isolation. Careful z-index management. Responsive layouts that adapt to viewport size. ARIA support for accessibility.

The Privacy Decision

This was non-negotiable from the start: Zero data collection.

No analytics. No telemetry. No tracking. No external servers. Nothing leaves your browser.

I know this is what users want because it’s what I want. Privacy isn’t a feature—it’s a fundamental right.

But here’s the thing: building without analytics is harder. I can’t see usage patterns. I can’t track errors in production. I don’t know which features are most popular.

That makes development more challenging. But it’s the right decision.

Everything runs locally. All preferences stored in browser storage. No network requests. No third-party services. No exceptions.

The TypeScript Journey

I wrote Myrmaid in TypeScript 5.8+ with strict mode enabled. Every module fully typed. Comprehensive JSDoc documentation.

Some might say this is overkill for a browser extension. I disagree.

Type safety catches bugs before they reach users. Clear interfaces make the codebase approachable. Documentation helps future contributors (including future me).

Forty-six TypeScript modules. Comprehensive test coverage. ESLint validation. Clean, maintainable code.

Is it more work upfront? Absolutely. Is it worth it? Without question.

The Cross-Platform Vision

Here’s where things get interesting. Myrmaid isn’t just a Chrome extension.

From the beginning, I architected it to work across platforms:

  • Chrome/Edge/Brave: Available now
  • Safari for macOS: In development
  • Safari for iOS: In development
  • Safari for iPadOS: In development
  • Safari for visionOS: In development

The TypeScript codebase compiles to JavaScript for both Chrome and Safari. The same core logic, the same processors, the same UI components.

For Safari, I’m building native Swift wrappers. UserDefaults for settings synchronization. Native message handlers for macOS. PNG rendering via WebKit.

And for visionOS? That’s where it gets really exciting. Spatial computing. Depth layers. Hand tracking. Imagine exploring a complex architecture diagram in 3D space, using gestures to navigate and manipulate the view.

That’s not science fiction. That’s the roadmap.

The Build Pipeline

Let me geek out for a moment about the build pipeline, because this is where TypeScript, Swift, ESBuild, and XcodeGen come together.

For Chrome:

TypeScript → ESBuild → JavaScript + Polyfills → Chrome Extension

For Safari:

TypeScript → ESBuild → JavaScript → Safari Extension Resources → XcodeGen → Xcode Project → Native Apps

One codebase. Multiple platforms. Clean separation of concerns.

What I Learned

1. Architecture Matters

The time invested in solid architecture patterns paid off immediately. Adding new features is straightforward. Testing is simple. Debugging is manageable.

2. Privacy is Possible

You don’t need analytics to build great software. You need clear principles and user feedback.

3. TypeScript is Worth It

Type safety, IntelliSense, and refactoring confidence are game-changers for maintainability.

4. Build for the Future

Architecting for multiple platforms from day one made Safari support possible without rewriting everything.

5. Users Care About Quality

Professional rendering, smooth interactions, and attention to detail matter. Users notice when you sweat the small stuff.

The Launch

After months of development, testing, refinement, and documentation, Myrmaid is live on the Chrome Web Store.

What it does:

  • Automatically detects and renders Mermaid diagrams on any webpage
  • Works on GitHub, GitLab, Stack Overflow, documentation sites, and more
  • Interactive pan/zoom controls with minimap navigation
  • Multi-format export (SVG, PNG, source code)
  • Multiple themes (default, dark, forest, neutral)
  • Zero data collection, complete privacy
  • Enterprise-grade security

What makes it different:

  • Built with SOLID principles and dependency injection
  • Comprehensive test coverage and security audits
  • Professional-quality rendering and interactions
  • Privacy-first from the ground up
  • Cross-platform architecture (Chrome now, Safari soon)

What’s Next

The Chrome extension is just the beginning.

Short Term:

  • Safari extensions for macOS, iOS, and iPadOS
  • Additional themes and customization options
  • Performance optimizations
  • Community feedback integration

Long Term:

  • visionOS spatial computing features
  • Custom theme creation
  • Additional export formats
  • Collaborative features

Always:

  • Zero data collection
  • Privacy-first principles
  • Security best practices
  • Quality over speed

Try It Yourself

If you’re a developer who works with Mermaid diagrams, I built Myrmaid for you.

If you’re tired of copying code blocks to external tools, I built Myrmaid for you.

If you care about privacy and want software that respects your data, I built Myrmaid for you.

Install Myrmaid from Chrome Web Store →

No configuration. No account. No data collection. Just install and browse.

Visit GitHub, GitLab, or any documentation site with Mermaid diagrams. Watch as they transform into beautiful, interactive visualizations.

Thank You

To everyone who:

  • Provided feedback during development
  • Tested early builds
  • Reported bugs and edge cases
  • Encouraged me to keep building

This launch is for you.

Join the Journey

Myrmaid is just getting started. Safari support is coming. VisionOS features are on the horizon. The roadmap is ambitious.

Want to stay updated?

Share Your Thoughts

I’d love to hear from you:

  • How do you use Myrmaid in your workflow?
  • What features would you like to see?
  • What diagram types do you work with most?
  • What could be improved?

Get in touch →

From a simple frustration to a full-featured browser extension, Myrmaid represents everything I believe about software development: Build it right. Respect privacy. Sweat the details. Ship quality.

Here’s to making the web a little more visual, one diagram at a time.

ajmcclary
ajmcclary

Leave a Reply

Your email address will not be published.