Concept: Hammer CMS

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:

  1. Web-Native, Not Abstracted

    • Keep using HTML comment–based tags rather than adding another templating language.

    • Stay true to Hammer’s minimal, declarative syntax.

  2. Content in Git

    • Treat content like code - versioned, collaborative, and portable.

    • Use Markdown and YAML files with front matter to store structured content.

  3. 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.

  4. 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.

  5. 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

  1. Parse Markdown and YAML with front matter

  2. Generate multiple pages from one template

  3. Support content relations (e.g. post → author)

  4. Add template context (doc, collections, site, helpers)

  5. 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:

  1. Should content generation remain fully local, or optionally sync with headless CMS APIs (like Chisel or Decap)?

  2. 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?

  3. How far should we go with AI assistance in the Hammer GUI?

    • Inline content generation? Drafting? Summarization?

    • Or just leave it to the IDE?

  4. What helpers or templating capabilities would make this powerful yet still simple?

  5. Any concerns about complexity or backward compatibility?

  6. Anything else I should be considering?

1 Like

Here’s a follow up to the above post showing a preview of an early version of this approach in action

Please do take a look and let me know what you think!

1 Like

An interesting set of questions there. Me, I am an experienced web developer writing applications (Blazor etc), but I don’t want to spend a lot of time when I’m working on web sites that are essenstially “static”. So I’ve looked at the various systems out there, but they are quite some work to make them do what I want. So Hammer interests me because if is, as current “Fully local”. I don’t want to have it do anything more than take the templates and sources and make a static output (as in the video demo). Sure, I could put things in git or whatever, but that shouldn’t be a requirement IMO.

So, how do I want it to work? I want the template and CSS and then to be able to go into a “simple edit mode” like DreamWeaver did back in the day. I can create new pages, and they will be just the basic content editing. Markdown is my preference, but I will need to do fancy HTML too - getting into Flex and the like to arrange things. So a way to switch between the two (happy to have a page all one or the other instead of mixed in one page).

You ask about AI and my first reaction was “no thanks”. But I do use various AI tools for coding, and so if it is focussed on making HTML as I want it, then maybe, but optional. I have a plain HTML editor that is very clever and supports all the CSS you could ever want, but it doesn’t help me make nice looking pages because I have to know all the CSS to make it work. If I’m being paid to do it, I can spend the time, but if this is unpaid stuff with an hour to complete a big change, I want the tool to be able to give me a fancy table layout and then I can just supply the content to fit. Not sure if I can post a link, but the mudblazor dot com Carousel, Expansion Panel, Stack and the sort of things I’d like to be able to “just stick into the page” without having to work out how to do it. (I realised there is code in these, not expecting miracles, just the ability to make nice layouts more easily than “put something in ” which of course is much of the point of Markdown). Actually, a better example is probably the getforge pricing page. The three price boxes - I want to be able ot say “give me three boxes like that” and there it is.

So, in summary, a tool that does what the video does with perhaps easier config (YAML - yuck! 8-). And one that can be used by an inexperienced user in a simple edit mode.

I should also note that the example is focused on a “blog” with authors and posts. WordPress does that of course, but also “pages” which are just normal pages. I do a lot more of that than blog posts, though my sites do sometimes have a blog too.

Hope this ramble helps - I may not be the target market, but Hammer looks like the best option for me to be able to get something working without too much learning and installing and running obscure tools that I don’t understand. A GUI has to be so much better.

Thanks, Matthew

1 Like

I think you’re totally on-point with the spirit, motivation and principles - I want to avoid “Developer Ceremony” where possible and support when necessary.

The thing that I pulled out first was around Layout & Components - something I’ve been thinking about as I seek to convert many of the sites I’ve built with static pages into content generated layouts.

A Blog is a great MVP use-case because we can mostly just dump a blob of markdown into a section and we’re good, but as you say, that’s not the only and possibly not the most impactful use-case.

For instance, on https://docs.getforge.com which will be a target for me to convert to this approach, each documentation page is more opinionated about layout, sections and components.

For this we need ready-made layout patterns (e.g. 3 pricing boxes, carousel, stack, card grid), these can be pre-styled or vanilla for custom-styling.

The way I think about this is using Hammer @include partials as blocks. Each block is a reusable layout, implemented once, with a little templating.

You feed these blocks with content objects from your content entries via front-matter, markdown, YAML ;), JSON or whatever format.

Hammer renders the plain html/css at Build time.


Hammer Includes with props

The mental model then becomes more like a Vue or React component invocation for each partial instance - template + data from content. For this, the @include tag could be extended to take a data property in the template:

<!-- @include _partial data=page.blocks[2] -->
<!-- @loop block in page.blocks -->
  <!-- @if block.type == "PricingGrid" -->
    <!-- @include _pricing-grid data=block -->
  <!-- @endif -->
  <!-- @if block.type == "Callout" -->
    <!-- @include _callout data=block -->
  <!-- @endif -->
<!-- @endloop -->

Just thinking out loud…

When you mentioned “components” it sparked joy in me - one of the really powerful aspects of Blazor in the component implementation, where you can specify parameters to be filled in, and/or lists of things to fill the content. No idea how you make that easy to use but that’s a you problem. :sunglasses:

1 Like

While the content config is a JSON file in your site files, that’s not very Hammer.

Being JSON means with Cursor and Cursor rules, you could leverage AI to generate your CMS more easily.

But for the humanz - a GUI editor is what we want. So that is what we shall have.

When you enable the Content Mode in the Site settings, Hammer will scaffold all of the directories and bootstrap the initial config.

Then you have access to the Content Configuration in the GUI much like this WIP interface I’m working on.

  • Manage your collections (create, duplicate, delete and edit)
  • Manage collection fields
  • Validation of correct formatting
  • File generation according to the config