FGOTHS (For The GOTH Stack) is an Apache 2.0 licensed Go project generator and embedded runtime for two kinds of projects: JSON APIs and server-rendered web applications built on Templ and HTMX. Its most distinctive part is a development hot-module-replacement (HMR) path that sends Templ HTML fragments to the browser as FlatBuffers messages over Server-Sent Events (SSE). The author also publishes throughput, latency, and binary-size figures. Those numbers are the author’s own measurements and have not been independently reproduced, so they should be read as claims rather than verified results.
What FGOTHS generates
FGOTHS ships two project presets, as described by its author in the DEV Community article introducing the project. The Go package page for the fgoths-framework module describes the same scope: Go services, JSON APIs, and server-rendered web apps.
As an Amazon Associate I earn from qualifying purchases.
| Preset | What it produces | Core stack |
|---|---|---|
api |
A flat JSON API project | Go only; no HTML layer described |
webapp |
An MVC-style web application | Go, Templ templates, HTMX for partial page updates |
The webapp preset is the one that exercises the HMR pipeline, because Templ components are what the development server re-renders and pushes to the browser.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Why the author built it
The author, Σωκράτης, frames the project as a personal tool first. In the article’s words: “I’m building FGOTHS (For The GOTH Stack) for my own studio because I needed a way to bootstrap production-ready Go webapps with zero cloud overhead, no heavy JS frameworks, and a fast dev loop.” That is a statement of motivation and positioning, not an independent evaluation of the stack against alternatives.
How the HMR pipeline works
Hot reload in FGOTHS is built from three pieces: a change event, a binary message format, and a browser-side swap of HTML fragments. The hmr package documentation, pinned to version v1.4.1 in its URL, describes the transport design.
Transport: a standard-library SSE broadcaster
The package documentation describes a Server-Sent Events broadcaster that depends only on the Go standard library. It is used during development to push change events from the server to connected browsers. SSE is one-directional, server to client, which fits a reload channel: the browser only needs to listen for updates.
Message format: FlatBuffers in SSE data lines
Each change event is framed as a FlatBuffers message and then base64-encoded so it can travel in the text-based SSE data lines. The consequence is that every update carries an extra encoding step on both ends, which is a cost worth keeping in mind when judging the reported latency figures below.
What the update preserves
The article says the HMR path replaces Templ HTML fragments while keeping form input values, focus, and scroll position intact. This is the feature that most separates it from a full-page reload. It is a project claim. The article does not describe a test matrix for it, and no independent test of it is cited here, so check it against your own forms and components before relying on it.
Runtime and deployment features
The article also describes runtime features beyond development reload. These are feature descriptions from the author:
- Zero-CGO build approach: the project is described as not requiring cgo, which is what allows static binaries.
- Static binaries: the output is described as a single static executable, which the author uses to explain the binary-size figure below.
- Embedded reverse proxy: the runtime includes a reverse proxy with a circuit breaker, health-checked failover, and deployment policies.
The article does not document how these policies are configured, so treat the proxy as a described capability and confirm its configuration surface in the package before building production routing on it.
Rank #4
Reported performance figures
The article reports the following figures. They come from the author, who published them in a September 27 article; the listing shows that date without a year, so confirm the year on the article page before citing it.
| Metric | Reported value | Source and status |
|---|---|---|
| Throughput | 100,000+ requests per second | Author-reported; not independently reproduced |
| Tail latency | About 2.2 ms p99 | Author-reported; not independently reproduced |
| Static binary size | About 8.8 MB | Author-reported; not independently reproduced |
| Container footprint | Below 10 MB | Author-reported; not independently reproduced |
Reading these numbers
The article points to benchmark suites, execution scripts, and load profiles in the repository’s /benchmarks directory. Those materials are the place to check hardware, workload, and methodology, which the article summary does not spell out in full. The article also compares FGOTHS with other frameworks. Those comparisons are the author’s and should not be read as verified head-to-head results.
Best Value
Throughput and tail latency depend heavily on the test machine, the request mix, and whether the service is measured behind the proxy. A figure without those details cannot be transferred to your own deployment.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Getting started and licensing
The Go package page covers four workflows: installing the CLI, initializing an API project, running the development reload, and building. The page identifies the module as Apache 2.0 licensed. It is the authoritative place for exact command syntax, and this article does not reproduce it, since the commands can change between releases.
Evaluating FGOTHS against other options
If you are comparing FGOTHS with another Go generator or framework, put the two side by side on the same axes so the comparison is fair:
- Generated project types: whether each tool covers APIs, server-rendered apps, or both, and what the presets include.
- Reload behavior: the transport used, whether form state, focus, and scroll survive an update, and how the behavior was tested.
- Runtime dependencies: cgo requirements, static-build support, and any bundled proxy or deployment logic.
- Benchmark method: hardware, workload, concurrency, and whether the numbers can be rerun from the published scripts.
Apply the same checklist to any figures you see in competing write-ups. The article’s own comparisons have not been validated by an independent test.
”
The Bottom Line
FGOTHS is a serious-looking, openly licensed option for teams that want a Go, Templ, and HTMX starting point with a fast reload loop. Its headline performance numbers and its state-preserving HMR are the author’s claims, so verify them against your own forms and workload before committing.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
