Forge: A Stack‑Based Language for Generating HTML

By Beto Dealmeida
May 21, 2026

---

What is being claimed?

Forge advertises itself as a Forth‑inspired DSL that lets you write complete websites as collections of .forge files. The core idea is simple: define words that emit HTML fragments, then compose them on a stack. A single binary compiles these files to HTML on the server, serves the generated markup to crawlers, and also bundles a service worker that re‑compiles the same source in the browser for a single‑page‑app experience. The author also highlights a built‑in append‑only JSONL log that can be used for likes, comments, or any mutable state.

What is actually new?

1. Stack‑based templating – Most web templating languages (e.g., Jinja, Handlebars) are expression‑oriented. Forge replaces that with a postfix notation where each word consumes and produces stack items. This is reminiscent of existing Forth HTML libraries such as Factor's html vocab, but Forge ships a complete compilation pipeline.

2. Dual‑mode rendering – The same compiler runs both on the server (via WebAssembly) and in the client (via a service worker). The result is server‑side HTML for SEO and WebMentions, while the client sees a SPA without a separate JavaScript framework.

3. Log‑centric persistence – Instead of a traditional database, Forge ships an append‑only JSONL log. The log-append word writes a JSON document to a file on the server, and the same API can be used from the browser to record interactions like "likes".

4. Minimal project layout – A Forge site consists of three items: a library of words (lib.forge), a CSS file, and a directory of page files. The binary takes the root directory and produces a ready‑to‑serve site.

Limitations and practical concerns

Tooling maturity

Forge currently provides a single binary that compiles to WebAssembly. There is no IDE integration, language server, or hot‑reload support beyond the service worker. For a developer accustomed to VS Code extensions that highlight syntax errors, this is a steep hurdle. The lack of a package manager also means sharing reusable components across projects will rely on manual copying of .forge files.

Performance trade‑offs

Forth is known for low overhead, but the compilation step in Forge is non‑trivial. The server must invoke the WebAssembly compiler for every request that is not cached. Benchmarks published by the author show sub‑millisecond compile times for a 10 KB page, but larger sites (hundreds of pages, complex layouts) have not been measured. In the browser, the service worker must fetch the source, compile it, and replace the DOM—all before the user sees any content. This adds latency compared to a pre‑rendered static site.

Ecosystem and interoperability

HTML is a universal output format, but most modern tooling expects a build step that produces static files (e.g., Next.js, Hugo). Forge’s approach of compiling on demand makes it harder to integrate with CDNs that cache only static assets. Moreover, the JSONL log is a custom persistence layer; existing analytics or comment systems cannot be dropped in without adapters.

Learning curve

Stack‑based programming is unfamiliar to most web developers. While the language is concise—"Hello" h1 renders an <h1>—the mental model of pushing strings onto a stack and calling words that consume them can lead to subtle bugs, especially when mixing optional attributes or conditional markup. The documentation currently consists of a short README and a few example pages; newcomers will likely spend significant time experimenting before reaching productivity.

Security considerations

Because the compiler runs on the server for every request, any vulnerability in the WebAssembly runtime could be exposed to the public internet. The project does not yet describe sandboxing strategies or input sanitization for user‑provided data that ends up in the stack.

How does Forge fit into broader trends?

There is a growing interest in LLM‑friendly DSLs that can be generated from natural language or Markdown. Forge’s regular, postfix syntax could indeed be easier for a language model to emit than nested HTML. However, the same benefit could be achieved with existing templating languages that already have mature ecosystems (e.g., Nunjucks, Liquid). Forge’s niche is the combination of stack semantics with on‑the‑fly compilation, a trade‑off that may appeal to hobbyists or researchers exploring alternative web stacks.

Bottom line

Forge demonstrates that a Forth‑style language can be used to generate complete websites, and it provides an interesting proof‑of‑concept for dual server/client rendering without a separate JavaScript framework. The idea is technically sound, but the current implementation lacks the tooling, performance guarantees, and ecosystem support needed for production use. It will be worth watching whether the author expands the project with a package manager, richer debugging tools, and more rigorous benchmarks.

---

For a deeper look at the source code, see the project's repository on GitHub (link not provided in the original announcement).