I’ve been exploring a concept to bring content generation directly into Hammer for Mac. I’d love to open this up for discussion and collective shaping with the community.
Some background:
https://blog.beach.io/the-cms-is-dead-long-live-the-cms-forge-870f39b22926
https://blog.beach.io/static-cms-tutorial-converting-the-hammer-gallery-25d9a6768c51
It was a long time ago that we started to explore what has become common place - the combination of headless CMS with build time compilation and static site generation and deployment to the edge via a global CDN.
Our version of this many moons ago combined third party headless CMS services of the time - Contentful, Cockpit etc. withHammer for Mac.
We then went on to build our own headless CMS, called Chisel CMS. This was an open-source, thin client and opinionated starter project setup for Parse Server, the open source nodeJS, express, mongoDB self-hosted PaaS stack.
Why This Matters
Hammer’s original magic was in its simplicity: local-first web publishing, powered by clean HTML and a build system that just worked, with an elegant GUI for those that prefer over CLI.
Before “Jamstack” and “headless CMS” became common terms, Hammer already had the DNA - local editing, templating, and deployment to the edge via Forge.
Now, with the rise of AI-assisted creation, content in Git, and open schema formats like front matter, I think there’s an opportunity to revisit those roots and evolve Hammer into something beautifully modern - without losing what made it unique.
First Principles
Here are the guiding ideas shaping this direction:
-
Web-Native, Not Abstracted
-
Keep using HTML comment–based tags rather than adding another templating language.
-
Stay true to Hammer’s minimal, declarative syntax.
-
-
Content in Git
-
Treat content like code - versioned, collaborative, and portable.
-
Use Markdown and YAML files with front matter to store structured content.
-
-
AI-Assisted Editing
-
Embrace AI tools that help scaffold, rewrite, and enrich content within Hammer.
-
Think “Copilot for content”: integrated, context-aware assistance right in the editor.
-
-
Beautiful Authoring Experience
-
Offer a non-technical UI for writers and editors to contribute content, without needing to touch HTML, IDE’s or Git directly.
-
Combine the polish of Hammer’s visual design with the flexibility of structured content.
-
-
Ecosystem Compatibility
- Stay interoperable with Decap CMS, Eleventy, Jekyll, and similar ecosystems through familiar front matter formats and collection patterns.
The Concept
At a technical level, this proposal introduces content generation support in Hammer builds.
It enables dynamic page generation from Markdown/YAML files using Hammer HTML templates — similar to static site generators like Jekyll or Eleventy, but powered by Hammer’s native tag system.
Example project structure:
content/
├── posts/
│ ├── hello-hammer.md
│ └── templates-with-hammer-tags.md
└── authors/
└── steve.yaml
templates/
├── index.html
└── post.html
Each content file includes front matter defining metadata (title, date, author, etc.), and Hammer uses that to render HTML pages from templates.
Core Capabilities
-
Parse Markdown and YAML with front matter
-
Generate multiple pages from one template
-
Support content relations (e.g. post → author)
-
Add template context (
doc,collections,site,helpers) -
Enhance template tags to support expressions, loops, filters, and helpers
Example Template Syntax
Hammer’s existing comment-based tags remain at the heart:
<!-- @loop post in collections.posts orderBy:'date' desc limit:5 -->
<h2><!-- $post.title --></h2>
<p><!-- $post.summary --></p>
<!-- @end -->
And for details pages:
<h1><!-- $doc.title --></h1>
<!-- $!doc.body --> // ! renders raw output
<p>Written by <!-- $doc.author.name --></p>
Discussion Points
Before moving ahead, I’d love your thoughts on a few questions:
-
Should content generation remain fully local, or optionally sync with headless CMS APIs (like Chisel or Decap)?
-
What’s the ideal developer–writer workflow?
-
Should non-technical users work in a Hammer-based UI while developers commit to Git?
-
If so, how should we manage merging changes?
-
-
How far should we go with AI assistance in the Hammer GUI?
-
Inline content generation? Drafting? Summarization?
-
Or just leave it to the IDE?
-
-
What helpers or templating capabilities would make this powerful yet still simple?
-
Any concerns about complexity or backward compatibility?
-
Anything else I should be considering?

