Forking the Web

Original Article ↗ Hacker News Discussion ↗

Scope and Motivation of a “Web Fork”

  • Many commenters like the idea of a simpler, information-focused “old web” for documents, not apps.
  • Others argue the current web already supports simple, script-free pages; the problem is incentives (SEO, advertising, engagement), not standards.
  • Some see the real issue as privacy, corporate capture, and high barriers to implementing a browser, not just complexity per se.

Strict Grammar and XHTML Parallels

  • The proposal’s “strict grammar, reject on error” is widely compared to XHTML, which is seen as a historical failure.
  • Critics say hard parse failures are worse than “99% working” pages, especially for long-lived content and emergencies.
  • Supporters of strictness want machine-friendly schemas, easier tooling, and deterministic behavior; they argue strictness works if adopted from the start and generated by tools, not hand-authored.
  • Others reply that real-world content pipelines, user-generated content, and mixed toolchains make strictness brittle in practice.

No Scripting vs Application Platform Reality

  • Strong disagreement on “no scripting”:
    • Pro: removes complexity and security issues; encourages dedicated apps (map viewers, etc.); aligns with “Unix philosophy.”
    • Con: browsers are now application platforms; users don’t want many separate native apps; sandboxed JS/WASM is safer and more convenient than random binaries.
  • Some suggest capabilities-based scripting (e.g., WASM with fine-grained permissions) as a middle ground.

Alternatives and Subsets

  • Gemini is cited as a close cousin but criticized for being too limited (no metadata, weak structure).
  • Markdown-in-browser or a strict subset of HTML (“web-lite”) are proposed as more realistic approaches, though Markdown’s ecosystem is called messy.
  • Others suggest reviving or extending Gopher-like or game/BBS protocols for niche use.

Feasibility, Governance, and Philosophy

  • Many doubt mainstream traction: e-commerce and modern apps depend heavily on JS; big vendors won’t adopt a restrictive spec.
  • Some argue layered, POSIX-like, capability-based designs could resist standard capture better than monolithic browsers.
  • A subset of participants explicitly value such a fork as a fun, nerdy side-internet, even if it never becomes profitable or mainstream.