writeonce/docs/plan/exploration/fiber/01-porch-vs-fiber-scope-gap.md

porch vs fiber — the scope gap, and who prefers which

Companion to 00-fiber-parity.md. Written 2026-09-06, after the porch track (stories 1–8) was brainstormed to ready. It reads fiber v3 (.dev/reference/fiber, commit 3ca9a9d) against porch's approved scope — what ships today, plus what stories 1–8 add — and asks what remains missing, what fiber does better, and whether a developer would choose porch. An exploration doc: no status banner by convention.

The 32 middleware, mapped against approved scope

Nine already had counterparts before the track. The track adds eight more. The rest are excluded, and the exclusions divide into principled (a different philosophy) and blocked (a primitive porch does not have yet).

• Shipped before the track (9): cors, basicauth, keyauth (bearer), helmet (SecurityHeaders), hostauthorization (HostAllow), etag, static, recover (trap=500), logger.
• Added by the track (8): compress + sse (story 7), csrf (4), session (3), favicon + healthcheck + rewrite + skip + redirect (5/8), requestid (5), limiter (story 1, already done).
• Blocked on the lang-41 runtime hang (1): idempotency — built, reviewed, gate-passed, reverted; it is porch story 9, held, not a design gap.
• Excluded, owner named (rest): cache/paginate (language 18), expvar/pprof (runtime-v2 7 observability), proxy (language 38, needs net.connect), encryptcookie (runtime-v2 8 symmetric cipher), adaptor (no net/http ecosystem), earlydata (TLS at the proxy), timeout (per-handler, needs cancellation — language 31), envvar + responsetime (niche helpers, unscoped).

What porch lacks even after the whole track lands

Ranked by how much a real app feels it.

1. Typed request binding. Fiber's Bind().Body/Query/Cookie(&struct) is the single biggest ergonomic gap. porch cannot do it without reflection (principle 13 forbids it) until @derive lands (language iteration 29). Today a porch handler pulls fields out of maps by hand. This is the one place fiber is dramatically more pleasant, and it is felt on every form and every JSON endpoint.
2. Outbound HTTP: client and reverse proxy. Fiber ships an HTTP client and a proxy middleware. porch has no net.connect, so neither exists — an app that calls another service or fronts one cannot be written in porch at all. Owner: language iteration 38.
3. Encrypted cookies. Fiber's encryptcookie is AES-GCM; porch has digests but no symmetric cipher, so it offers signed-and-readable only. Fine for a session id, not for a payload an app wants to hide from the client.
4. Per-handler timeouts. Fiber wraps a handler in a deadline. porch has per-call net deadlines (iteration 35) but no per-handler timeout, because cancelling a running handler needs the actor-lifecycle cancellation that language iteration 31 owns.
5. Runtime templating. Fiber renders views at request time against a dozen template engines. porch rejects this by doctrine — markup is a compile-time literal (writeonce-view). A principled choice, but it rules out the user-editable-template use case entirely.
6. The ecosystem. adaptor plugs fiber into all of Go's net/http universe; its session/cache/limiter middleware take pluggable storage drivers (Redis, Postgres, dozens more). porch has none of that surface and, by single-binary doctrine, does not want most of it — but it means no drop-in Redis, no community middleware, no third-party integrations.
7. Minor, unscoped helpers: pagination, response-time header, env-var exposure. Each is a few lines an app can write; none is in the track.

What fiber is better at, even where porch has a counterpart

• Maturity and ecosystem. Battle-tested, huge community, pluggable storage behind every stateful middleware, and the whole Go module world one adaptor away. This is fiber's decisive, structural advantage and porch will not close it.
• Ergonomics. Binding, generic helpers, reflection-driven convenience — less hand-written glue per endpoint.
• Raw performance ceiling. fasthttp is extreme; a bytecode VM with single-threaded-per-connection serving will not match its throughput on a synthetic benchmark. (porch trades this for a different model, below.)
• Configurability. Case-sensitivity, strict-slash routing, prefork, storage backends — many knobs. porch is deliberately opinionated with few.
• All-in-one networking. Client, proxy, TLS termination, HTTP/2 in one process. porch delegates TLS/HTTP2 to a front proxy by doctrine.

Where porch is actually better

The honest counter-case, because "prefer" is not decided on fiber's axes alone.

• Durable by default, in one binary. Sessions, rate-limiting and idempotency ride the WAL and survive a restart with no Redis, no external store. Fiber's defaults are in-memory — a restart logs everyone out and resets every counter; durability means operating a second system. porch's whole stateful surface is durable with zero extra infrastructure.
• One static binary, zero dependencies. Hand-rolled crypto, no CGO, no driver matrix. Deploy a file.
• Safety by construction. No reflection, ownership/borrow checking, and a house style of secure-by-default (HttpOnly/SameSite defaults, session-id rotation on login, refusal classes distinguishable in logs but opaque in the body) and refuse-the-unconstructible (an incoherent heartbeat/idle pair, a streaming route under header-mutating middleware — both rejected at construction, never silently half-applied).
• A concurrency model that fits the hard parts. Actors/fibers/shards make SSE fan-out and WebSocket rooms natural rather than bolted on, and idle connections park for almost nothing.
• Honesty about limits. Every gap above is named with an owner; nothing degrades silently.

Would developers prefer porch over fiber?

It depends on who is asking, and the answer is not "porch wins on features."

• A Go developer choosing a framework today: no. Not on parity terms. Fiber wins on ecosystem, binding ergonomics, maturity, performance ceiling, storage flexibility and sheer breadth. porch cannot out-fiber fiber at fiber's own game, and trying would be the wrong goal.
• A developer already choosing writeonce: yes, and gladly. porch is a coherent, durable-by-default, single-binary framework with strong security defaults, written in the language it serves. Inside the ecosystem there is no contest — it is the framework, and a good one.
• A developer choosing on values, either language aside: sometimes. Someone who weights one-binary durability with no Redis, memory safety without GC pauses, opinionated secure defaults, and named-not-hidden limits above ecosystem breadth may genuinely prefer porch. That is a real but narrow constituency.

The honest positioning. porch is not a fiber-killer and the approved scope does not try to be one. It is deliberately complete enough to prove the language can carry a serious web framework, with a distinct thesis — durable-by-default, single-binary, safe-by-construction — that fiber does not compete on. Its remaining gaps are almost all one upstream primitive away (net.connect → client/proxy, @derive → binding, a cipher → encrypted cookies, cancellation → handler timeouts), which means the ceiling is set by the language track, not by porch's design. Developers will prefer porch when they have already bought the thesis; they will prefer fiber when they are shopping on breadth.