Why: the goal or problem

Imagine a town guide where visitors read walks and landmark articles. Editors repeat layout fixes across pages. They know Go templates and want shared Markdown publishing; page-specific interactive components are a lower priority.

How: work toward a solution

Start the town guide with three Markdown articles and one layout. Next builds an index and three article pages, then delivers them through hosting. Missing layout stops output. A browser widget can call a separate Save API; Hugo never handles reader requests. Previous, Reset, or reload restores earlier states.

Build a town visitor guide

Concept simulation

Hugo

Next traces source → build → output → host → browser.

  1. 01 Three Markdown articles + layout
    • local-history.md
    • town-market.md
    • walking-trails.md
    • Shared layout
  2. 02 Hugo · Go templates

    Waiting

  3. 03 Generated HTML files 0

    index.html · local-history.html · town-market.html · walking-trails.html

  4. 04 Static host · publish files
  5. 05 Browser · read three articles

Three Markdown articles + layout

Execution boundary
Build: content + Go templates → files. The host serves files without running Hugo per read.
State and responsibility
Publisher owns templates and deployment; a separate service owns private records.

A fictional demo within this article. Reset or reload restores its initial state.

What: the concept

Hugo combines content with templates to generate static files. Its Go implementation does not require authors to write articles as Go programs.

Plan template maintenance and personal storage separately.

Source