Migrating Dillo from GitHub

📝 Discussion Summary (Click to expand)

The three most prevalent themes expressed in the discussion are:

1. Decline in GitHub Frontend Usability and Performance

Many users expressed frustration that GitHub's modern frontend, heavily reliant on JavaScript frameworks like React, has become sluggish and performs poorly compared to its previous versions, severely impacting developers using simpler or older browsers. * Quotation: User superkuh stated, regarding the state of the frontend, "The new React stuff is sluggish even on a crazy fast computer." * Quotation: User datadrivenangel noted the massive increase in code size correlating with slowness: "What's nuts about that presentation is that the github frontend has gone from ~.2 to >2 Million lines of code in the last 5-6 years. 10x the code... to get slower?"

2. Pushback Against Heavy JavaScript Dependence and Accessibility Regressions

A major point of contention is GitHub's move toward requiring complex JavaScript environments, which breaks compatibility for users with non-JS browsers (like Dillo, mentioned by the original poster) or those who prefer minimal JS for performance. * Quotation: User superkuh criticized this reliance: "There's 'enabling javascript' and then there's 'requiring a javascript VM with bleeding edge features basically only found 3 browsers'." * Quotation: User venturecruelty questioned the necessity: "Why should you need JavaScript to render text and buttons? Were browsers unable to do this prior to the JavaScriptification of everything?"

3. Increased Interest in and Migration to Self-Hosted/Alternative Git Forges

The dissatisfaction with GitHub's technical direction and centralization has fueled a noticeable trend toward migrating projects to self-hosted solutions (like Gitea/Forgejo) or evaluating alternatives that prioritize minimalism and performance. * Quotation: User homebrewer recommended alternatives based on their own experience: "For contrast, gitea/forgejo use as little JavaScript as possible, and have been busy removing frontend libraries over the past year or so... Let them choke on their 'app-like experience', and if you can afford it, switch over to either one." * Quotation: User the__alchemist described the movement: "We are in the disapora phase; there is a steady stream of these announcements, each with a different GitHub alternative."

🚀 Project Ideas

Minimalist, JS-Optional Git Forge Viewer

Summary

A lightweight, static web service that mirrors public Git repositories (from GitHub, GitLab, Forgejo, etc.) and renders key information (code, issues, PRs) using minimal JavaScript, ensuring graceful degradation, especially for users of legacy or simple browsers like Dillo.
Core value proposition: Uncompromised accessibility and performance for passive consumption of open-source code and project metadata, decoupling browsing from complex application frameworks.

Details

Key	Value
Target Audience	Users running low-JS browsers (Dillo, Lynx), those experiencing GitHub slowness, and developers wanting highly performant read-only access.
Core Feature	Static site generation/serving from cloned Git repos, converting Git metadata (commits, issues if available via API scraping/mirroring) into pure HTML/CSS pages using server-side rendering only.
Tech Stack	Go or Rust (for fast parsing and serving), leveraging standard Git tooling (`git cat-file`, `git log`) and potentially scraping public APIs/mailing lists for issue tracking data.
Difficulty	Medium (Handling all Git features and complex issue metadata without JS is challenging, but targeting read-only views simplifies this.)
Monetization	Hobby

Notes

Why HN commenters would love it: It directly addresses the pain point that "frontend barely works without JavaScript" and the desire for speed ("The new React stuff is sluggish"). Users like marginalia_nu and superkuh explicitly need this capability for non-JavaScript environments.
Potential for discussion or practical utility: It revives the spirit of fast, minimal browsing platforms like cgit or ancient GitHub. A major discussion point would be how to reliably ingest issue/PR metadata from centralized forges into this static model without relying on their JS-heavy UIs.

Offline-First, Email-Centric Pull Workflow Tool

Summary

A dedicated tool designed to aggregate and manage contributions (patches/diffs) via email subscriptions (the "pull model") rather than continuous web notifications (the "push model" of PRs/issues).
Core value proposition: Restoring an offline-friendly, distraction-minimized contribution process favored by Unix philosophists, solving the problem of "push tells you to do something now."

Details

Key	Value
Target Audience	Developers who prefer the mailing list/patch submission model (like Linux kernel/Sourcehut users), or those wanting to batch review work offline.
Core Feature	An IMAP/POP3 integration service that syncs relevant mailing lists into a local, downloadable data structure (e.g., standardized patch files), allowing offline branch creation, review, and generation of a reply patch to submit back.
Tech Stack	Python or Node.js (for robust email parsing/protocol handling), potentially using `git format-patch` internally.
Difficulty	High (Implementing reliable, authenticated interaction with various IMAP systems and correctly handling patch application and reply formulation crosses complexity barriers.)
Monetization	Hobby

Notes

Why HN commenters would love it: It directly appeals to users like bayindirh and throwaway150 who miss the unified, offline-capable patch submission model, avoiding the "pings of the PRs." It provides a technical solution for the philosophical debate between push and pull workflows.
Potential for discussion or practical utility: This service would generate significant interest in workflows centered around Git combined with traditional email communication, providing structured tooling for an arguably superior, though less fashionable, collaboration method.

Unified, Deployable Multi-Forge CI Runner Abstraction

Summary

A flexible, standardized Docker/Podman-compatible CI runner service that abstracts differences between GitHub Actions, GitLab CI, and Forgejo Actions, simplifying self-hosting of CI/CD environments.
Core value proposition: Allowing enterprises/individuals to easily self-host CI/CD pipelines compatible with multiple VCS platforms using a unified configuration layer, reducing vendor lock-in and resource exhaustion seen with heavyweight GitLab instances.

Details

Key	Value
Target Audience	Self-hosters tired of complex GitLab maintenance (`xrd`, `iamnothere`), or those needing CI compatibility across multiple Git forges (Forgejo, GitLab, GitHub).
Core Feature	A single runner binary (similar to Forgejo/Gitea runners) that accepts configuration specifying the target forge, translating the native YAML dialect (or a unified YAML dialect) into the necessary execution commands for that host.
Tech Stack	Go or Rust (for lightweight, minimal-dependency binaries), heavy reliance on containerization (Docker/Podman) for environment isolation.
Difficulty	Medium/High (The core difficulty lies in maintaining faithful compatibility layers for the nuances of Actions vs. GitLab CI YAML syntax, especially artifacts and branching logic.)
Monetization	Hobby

Notes

Why HN commenters would love it: Commenters expressed frustration with the resource intensity of GitLab (xrd noted 16GB VM exhaustion) and the desire for simple maintenance (homebrewer noted Gitea/Forgejo simplicity). This offers the ease of use of Forgejo runners married to compatibility with the features like GitHub Actions.
Potential for discussion or practical utility: This addresses the need for "better CI" (as noted by gchamonlive) in a self-hosted context, providing a concrete bridge between the popular Actions ecosystem and resource-frugal infrastructure.