You know the feeling. You’re writing a README, a blog post, or even just a code comment. You type **bold** and it works fine. But then you hit that one Markdown quirk—the one that makes you want to throw your keyboard across the room. Maybe it’s the inconsistent handling of nested lists. Maybe it’s the clunky table syntax. Or maybe you just wish you could indent code instead of wrapping it in triple backticks.
And then someone shows you Shrimple. A Markdown alternative that actually looks cleaner. Proper indentation for code blocks. No more fumbling with backticks. The syntax is objectively nicer, more consistent. You feel a spark of hope—finally, someone fixed the annoying bits. But that hope dies quickly, because you’ve been here before.
The problem isn’t that Markdown is perfect. It’s that perfection in isolation doesn’t matter.
We’ve all seen the XKCD comic—the one where 15 competing standards spawn a new universal standard that becomes the 16th. Shrimple is that 16th standard. And while its syntax might be cleaner, the real barrier has nothing to do with syntax at all. It’s about people. It’s about the network of tools, habits, and expectations that makes Markdown the de facto language for writing on the web.
You’ve probably noticed: every few years, someone launches a ‘Markdown killer.’ AsciiDoc. reStructuredText. Org-mode. Now Shrimple. Each one promises to solve the same minor inconveniences. And each one fails to reach critical mass. Why? Because the cost of switching—for you, for your team, for the entire ecosystem—far outweighs the marginal benefit.
Most developers think the battle is technical. It’s not. It’s a coordination game.
Let me put it bluntly: Shrimple’s syntax is nicer. I’ll grant that. But nicer doesn’t win. Network effects win. When you write in Markdown, your README works on GitHub, GitLab, Bitbucket, and every static site generator. Your comments render in Slack, Discord, and Reddit. Your notes sync with Obsidian, Notion, and Roam. That’s the real value—universal interoperability.
Shrimple would require new parsers, new tooling, new integrations. Every developer would need to learn a new syntax, even if it’s simpler. Every CI pipeline would need updates. Every documentation generator would need patches. And for what? To save a few keystrokes? To avoid that one time you had to look up how to make a table?
I saw this firsthand when a colleague tried to introduce a ‘better’ Markdown at a startup. The pitch was solid: cleaner syntax, no ambiguity. But the team revolted. Not because the syntax was bad—but because swapping meant breaking everything. Docs broke. Linters broke. Code review comments broke. The cost of fragmentation was simply too high.
Incremental improvements don’t justify the fragmentation tax. Ever.
Now, I’m not saying Markdown is perfect. It has genuine pain points—nested lists, table alignment, footnotes. But those pain points are already solved by tools: extensions, preprocessors, and LSPs. The community has built a layer of glue that makes Markdown work for almost every use case. Shrimple is trying to solve a problem that’s already been patched.
The irony? Shrimple’s creator probably saw the same frustrations you did. They decided to build something better. And it is better—on paper. But in practice, the best syntax is the one everyone already knows. The best format is the one that’s everywhere. The best standard is the one you don’t have to think about.
Stop optimizing for your own convenience. Start optimizing for the ecosystem.
So what should you do? Don’t switch to Shrimple. Don’t switch to any ‘better’ Markdown. Instead, invest in better tooling around Markdown: better editors, better previews, better linting. That’s where the real leverage is. Because Markdown is good enough—and good enough, when shared by millions, beats perfect every time.
The next time you reach for Shrimple, remember: you’re not just choosing a syntax. You’re choosing whether to cooperate with everyone else. Choose cooperation. It’s boring. It works.
FAQ
Q: Isn't Shrimple objectively better than Markdown?
A: On syntax alone, yes. Indented code blocks are cleaner. But 'objectively better' ignores the ecosystem cost. Markdown's network effects—GitHub, Slack, every static site generator—make it the default. Switching fragments tooling, requires retraining, and breaks interoperability. The marginal benefit of cleaner syntax is dwarfed by the friction of change.
Q: So should I never try new markup languages?
A: Not never. If a new language offers a 10x improvement in productivity or unlocks entirely new capabilities, it's worth considering. The key is the magnitude of improvement. Shrimple offers a 1.5x syntax polish—not enough to warrant the switch. Aim for innovations that solve problems Markdown can't, not ones that polish what already works.
Q: But what about the frustration of Markdown's quirks?
A: I feel you. Markdown's inconsistencies are annoying. But the fix isn't a new standard—it's better tooling. Extensions like Markdownlint, custom parsers, and LSPs already patch most pain points. The community has built a layer on top. Adding a new standard just creates another set of quirks and compatibility headaches. Invest in tools, not in fragmentation.