Rewriting my website in plain HTML and CSS

Original Article ↗ Hacker News Discussion ↗

Rebuilding personal websites in plain HTML and CSS is attracting renewed interest as developers tire of heavyweight JavaScript frameworks and complex toolchains. Commenters highlight both the appeal of minimal, fast, framework-free sites and the practical pain points this approach exposes, such as duplication, templating, RSS generation, and live reloading—often leading people to recreate lightweight static site generators with tools like Pandoc, Make, PHP, or SSI. The conversation surfaces a broad spectrum of options, from modern SSGs like Astro and Hugo to old-school techniques like server-side includes, reflecting an ongoing tension between simplicity, maintainability, and developer convenience.

Static site generators & modern tooling

  • Many argue the described approach effectively reimplements a static site generator (SSG).
  • Popular SSGs mentioned: Astro, Hugo, Jekyll, Pelican, Eleventy, Nikola, Hakyll, Lume, Zola, Hakyll, and smaller tools like Teeny, Query, bashblog.
  • Astro is repeatedly praised: zero-JS-by-default, component model, markdown integration, ability to mix React/Svelte, and simple templates.
  • Some prefer rolling minimal custom pipelines (pandoc + Makefile/shell, Node+ESBuild+SASS, Python + Jinja2, simple PHP, Go templates) to avoid SSG complexity and theme systems.

Templating, includes, and reuse

  • A central pain point: shared headers/footers and repeated HTML.
  • Solutions discussed:
    • Server Side Includes (SSI) in nginx/apache and similar features in Caddy.
    • PHP include, tiny PHP apps, or template engines (Twig, Go templates, Jinja2, Mustache/“mo”, Slab, etc.).
    • Static build scripts concatenating header/body/footer.
    • <object> as a quasi-include, with debate over extra HTTP requests vs simplicity.
    • Web Components or light JS includes for those okay with JavaScript.
  • Concerns: some platforms (e.g., Netlify-like static hosting) don’t support SSI; some people want zero JS and no backend.

Workflows, tooling, and ergonomics

  • Common stacks: write in Markdown (or SGML), convert with pandoc or SSG to HTML, sometimes add syntax highlighting at build time to avoid runtime JS.
  • Live reload options: livereloadx, live-server, custom watchers (entr, watchexec), IDE-integrated reload.
  • Several report that manual copy-paste and search/replace across a small site is manageable and even preferable to framework churn.

Performance, complexity, and philosophy

  • Many value minimal HTML/CSS for speed, longevity, and fewer dependencies; some host on GitHub Pages or even home servers.
  • Skeptics of JS-heavy stacks point to bloat, breakage when JS is disabled, and maintenance pain (npm churn, React/Next complexity).
  • Others counter that JS frameworks can offer better organization, richer features, and that JS size is often blamed more than images/CSS.
  • Accessibility and semantics debates surface (native HTML vs ARIA/JS-driven UIs), with no clear consensus.

Odds and ends

  • RSS feeds are a common missing piece; some generate them via scripts or external tools.
  • Several note that simple static blogs teach where modern framework conveniences come from, and that “boring” tech can be a feature.