A Modern Web App in C

Original Article ↗ Hacker News Discussion ↗

Building a “modern” web app in plain C using CGI, SQLite and OpenBSD’s httpd rekindles enthusiasm for minimalist stacks while reviving long‑running debates about C’s safety and suitability for internet‑exposed services. Many commenters like the simplicity, predictability, and tiny dependency surface of a single static binary invoked per request, especially compared with multi-layer setups involving nginx, app servers, and large frameworks. Critics counter that string handling, concurrency, and memory safety make C a poor fit compared to Go, Rust, or PHP/FastCGI, and argue that any performance or architectural gains must be weighed against security risks and the realities of modern observability and maintenance.

Choice of C and BCHS stack

  • Many are intrigued by building a “modern” web app in plain C with OpenBSD httpd and SQLite (BCHS).
  • Motivations inferred: minimal dependencies, predictable behavior, tight fit with OpenBSD’s pledge/unveil, and the feeling that C “fits in your head.”
  • Some question why C was chosen over C++, Rust, Go, or PHP, arguing other languages could offer similar simplicity with more safety and tooling.

CGI, process model, and performance

  • Core design: CGI, one fresh process per request. Advocates like the isolation, trivial deployment (replace one binary), and lack of complex app servers.
  • Critics call CGI a “half measure” and “inefficient,” noting process creation overhead and lack of shared state; they suggest FastCGI, in‑process modules, or custom HTTP servers instead.
  • Others counter that modern kernels make fork cheap enough for low/medium traffic, and compare this model to today’s “serverless” functions.

SQLite and concurrency

  • Questions raised about multiple concurrent requests hitting one SQLite file.
  • Responses: enabling WAL mode allows many concurrent readers with a single writer; file locking handles process concurrency. Writes still serialize but are fast without network hops.

String handling and C ergonomics

  • Several note that emitting HTML/CSS in C is tolerable; parsing and general string handling are the painful parts.
  • Some mitigate this with custom string builders/views and fixed-size buffers to avoid allocations.

Security and language choices

  • Strong disagreement on exposing new C code to the internet.
    • Critics: C’s memory unsafety leads to recurring RCEs; more secure choices (Rust, “C-style C++”) exist.
    • Defenders: most underlying infrastructure (kernels, web servers, DBs) is already C/C++; careful design, OpenBSD hardening, and small, auditable code can be safe.
  • Rust is praised for memory safety but criticized for heavy dependency graphs and “supply chain” risk; C is seen as trading memory safety for simpler, smaller dependency surfaces.

Simplicity vs modern stacks

  • Many express nostalgia for CGI and early PHP/Perl days and fatigue with today’s multi-layered stacks (nginx → app server → framework → ORM, etc.).
  • Some argue modern layers add needed features (observability, scaling, rate limiting), while others say these are overkill for small sites and internal tools.

Frontend, UX, and AI-writing concerns

  • Multiple commenters find the showcased site’s design hard to read and low-contrast.
  • Several suspect parts of the blog post are AI-written, though others dispute this and note AI detectors are unreliable.