What Is Forge, and Why Does It Exist?

Forge is a stack-based, Forth-inspired language built for one specific job: generating HTML. Its creator describes the origin with disarming honesty — “I don’t remember where the idea came from” — which signals something meaningful. This wasn’t a frustrated reaction to a broken tool or a response to a job requirement. It was a genuine intuition, acted on.

That intuition was straightforward: a concatenative programming model, where operations consume and produce values on a stack, maps naturally onto the act of composing markup. HTML is already a kind of nesting and wrapping operation. Forge just makes that explicit in the execution model.

The syntax follows classic Forth conventions closely. Words are defined with a colon, stack effects are documented in parentheses, and execution is postfix — meaning operands come before the operations that act on them. The simplest example from the project’s own documentation shows this directly:

: h1 ( s -- ) "<h1>" emit . "</h1>" emit ;

"Hello, World!" h1

Here, h1 is a word definition that takes a string off the stack, emits an opening tag, prints the string with ., then emits a closing tag. Calling it is a single postfix operation: push the string, invoke the word. No function call syntax, no template delimiters, no special escaping context.

From that foundation, the creator built a library of word definitions that handle more complex HTML patterns, including microformat markup. A post-body word, for instance, assembles a full blog post structure — publication date, author, permalink, content — by composing smaller named words in sequence. The result reads almost like a declarative description of the page’s shape, but executes as a series of stack operations.

Forge exists because one developer followed a hunch that the concatenative model, largely confined to systems programming and hobbyist language design, had an untested application in web templating. The project is the answer to whether that hunch was worth pursuing.

The Stack Model Applied to HTML: How It Actually Works

The simplest Forge word definition reveals the entire model. Writing : h1 ( s -- ) "<h1>" emit . "</h1>" emit ; does four things in sequence: pushes the string "<h1>" onto the stack, calls emit to output it as raw markup, calls . to pop and print the string sitting on top of the stack, then pushes "</h1>" and emits that. Calling "Hello, World!" h1 produces exactly <h1>Hello, World!</h1>. The pattern is mechanical, predictable, and composable by design.

The distinction between emit and . carries real architectural weight. emit outputs a literal string directly — it never touches the stack’s data. . consumes the top-of-stack value and prints it. That separation means the author controls precisely where dynamic content lands relative to surrounding markup. There is no implicit interpolation happening behind the scenes, no template engine scanning for {{ }} delimiters or <%= %> tags. Every output action is an explicit instruction.

This makes Forge structurally unlike Jinja2, Handlebars, or JSX. Those systems treat a template as a document with holes that get filled. Forge treats HTML generation as a sequence of operations on a data structure. An element like p or dt-published is not a placeholder — it is a word, a reusable unit of behavior defined once and invoked anywhere. The post-body definition in Forge’s example chains together h-entry-start, dt-published, p-author, p-summary, e-content, and u-url as discrete words, each one handling its own tag logic internally. The calling code never writes an angle bracket.

The practical result is that adding a new HTML pattern means writing one word definition, not modifying a template syntax or learning a new filter system. Complex microformat structures like h-entry become first-class vocabulary items in the same namespace as basic elements. The stack enforces a discipline: every word must leave the stack in a known state, which makes reasoning about composition straightforward. What looks like a niche experiment turns out to describe a genuinely different philosophy — HTML as a program, not a document.

Microformats as a First-Class Use Case

One of the first things Forge’s creator built after the core interpreter was a dedicated library of word definitions for microformats — specifically the h-entry vocabulary used in IndieWeb publishing. That’s a revealing choice. Most static site generators treat microformats as a plugin concern or ignore them entirely. Forge made them a standard part of the toolkit from day one.

The practical result is visible in a single code sample. Two high-level words, post-body and post-content, assemble a complete IndieWeb-compatible blog post. post-content is just a paragraph word wrapping body text. post-body is where the composition gets interesting: it calls h-entry-start, emits a byline block using dt-published, p-author, and h-entry-end, then layers in p-summary, e-content, and u-url to complete the microformat structure. The final call — "Hello, world!" "post-body" blog-post — produces a fully annotated h-entry from a title string and a word name.

This is Forth’s vocabulary-building model working exactly as intended. Primitive words handle individual microformat properties. Mid-level words like post-body compose those primitives into structural patterns. Page-level words then consume those patterns as opaque units. Each layer knows nothing about the implementation details below it. Swap out the dt-published word and every post definition that calls post-body picks up the change automatically.

The semantic web values embedded here are quiet but deliberate. h-entry is the markup standard that powers Webmention, feed readers, and IndieWeb aggregators. A site generator that ships h-entry support as a core library word isn’t neutral on the question of whether structured semantic markup matters — it’s made a bet. Forge’s creator made that bet early, before building most other features, which says something about what problem the tool was actually designed to solve. This wasn’t a general-purpose templating engine that happened to mention IndieWeb compatibility in the docs. Microformats were the use case that shaped the library’s architecture from the start.

What Most Coverage Misses: Concatenative Languages and the Web Have History

Web templating discourse has a blind spot. The conversation defaults to three paradigms: declarative markup like HTML itself, functional composition like JSX, and logic-driven template engines like Jinja or Liquid. Concatenative, stack-based approaches barely register in that conversation — and Forge is one of the few public projects proving the concept is viable.

The lineage here matters. Forth, the language that directly inspired Forge, dates to 1970 when Chuck Moore developed it for telescope control software at the National Radio Astronomy Observatory. Its execution model is famously minimal: push values onto a stack, apply words that consume and produce those values, compose larger behavior from smaller primitives. Embedded systems and resource-constrained hardware kept Forth relevant for decades precisely because that model requires almost nothing to run. Applying that same philosophy to HTML generation is a genuinely underreported design direction — one that trades the abstraction comfort of modern frameworks for explicit, composable control over every byte of output.

Forge makes that tradeoff visible. A word definition like : h1 ( s -- ) "<h1>" emit . "</h1>" emit ; is not a template or a component. It is an instruction sequence that manipulates a stack and emits output. The stack effect notation ( s -- ) documents exactly what enters and leaves. There is no runtime magic, no virtual DOM, no compiler transform sitting between the author and the generated markup.

That directness has a natural audience: the IndieWeb and personal publishing communities. These communities built microformats — a set of HTML class-name conventions like h-entry, dt-published, and u-url — to embed machine-readable semantic data directly in human-readable pages. Semantic correctness is not optional in that world; it is the entire point. Forge ships with a built-in library of microformat words, meaning dt-published and p-author and u-url are first-class primitives rather than afterthoughts bolted onto a generic templating system. For publishers who care about IndieWeb interoperability, that is a material difference from reaching for Eleventy or Hugo and manually managing class names in partials.

The mainstream web development press has not covered this intersection. Forge exists in that gap.

Limitations and Open Questions the Project Raises

The available documentation for Forge cuts off mid-sentence — the homepage source truncates at “Each site is a collection of pag” — which leaves critical questions about the language completely unanswered. There is no visible documentation covering loops, conditionals, error handling, or how Forge manages state beyond what sits on the stack at any given moment. These are not minor gaps. For any templating system targeting real websites, the ability to iterate over a list of posts or conditionally render elements based on data is table stakes. Whether Forge handles these through standard Forth-style control flow words, some custom mechanism, or not at all is simply unknown from what’s publicly visible.

The mental model shift is another unresolved challenge. Web developers today think in component trees — React, Vue, Svelte — or in declarative template syntax like Jinja or Liquid. Stack-based thinking inverts that intuition entirely. Instead of nesting elements around content, you push values and consume them through word definitions. The h1 word definition Forge shows — "Hello, World!" h1 — is clean, but scaling that discipline across a full page layout demands a different kind of spatial reasoning. Whether Forge includes any onboarding tooling, documentation for developers unfamiliar with Forth, or even a standard library beyond the microformat words shown is nowhere confirmed.

The byline code in the post-body definition adds another ambiguity. The line "<p class='byline'>" emit injects a raw HTML string directly rather than using a higher-level word that accepts class names as arguments. That pattern works, but it suggests Forge may not yet have a composable vocabulary for attributes — no word like "byline" p.class that keeps markup semantics inside the language. The emit word appears to be a raw output escape hatch, which is useful but signals that the abstraction layer has holes. Whether those holes are intentional, temporary, or endemic to the current design is a question the truncated sources cannot answer.

Why This Matters Now: The Counterculture of Minimal Web Tooling

The timing of a project like Forge is not accidental. As AI coding assistants push developers toward React boilerplate, Tailwind utility classes, and Next.js scaffolding by default, a countercurrent is forming among builders who want to account for every tag their tools emit. For performance-sensitive publishing — sites where payload size affects Core Web Vitals scores and where third-party scripts are a liability — that level of control is not aesthetic preference. It is a technical requirement.

Forge occupies this space deliberately. Its author’s origin statement is disarmingly simple: “I had an idea, so I built the tool.” That sentence carries weight in an ecosystem where most developers configure abstractions rather than create them. Writing a Forth-inspired interpreter from scratch, defining a word vocabulary that maps stack operations to HTML output, and building microformat support on top of that — none of this is the path of least resistance. It is the path taken by someone who found the existing design space unsatisfying and decided to redraw it.

The historical grounding matters here. Forth was designed by Charles Moore in the late 1960s as a language that fit inside severe memory constraints and gave programmers direct access to machine behavior. Applying that same philosophy to HTML generation in 2026 is not nostalgia. It is a recognition that the problems Moore was solving — minimal overhead, explicit control, composable primitives — are the same problems that haunt anyone who has audited the network waterfall of a modern content site.

Whether Forge attracts a user base beyond its creator is beside the point. The project proves that the design space for web authoring tools has open territory. A single developer, working from a half-remembered idea, produced a functioning language with a word definition syntax, a stack execution model, and built-in support for microformats — structured data markup that most contemporary site generators treat as an afterthought. That outcome is the argument. The tools developers use to build the web are not fixed. They are chosen, and sometimes, they are built from scratch.