"GitHub" Is Starting to Feel Like Legacy Software
GitHub’s web interface is increasingly seen as sluggish and awkward, with React-driven “modernization” changes like lazy loading and intercepted search breaking once-reliable workflows such as blame views, code review, and in-page find. Commenters contrast this UX drift and scope creep (social metrics, AI features) with the stability many developers value in long-lived tools, and note that core capabilities like notifications and review ergonomics lag behind older systems such as Phabricator. Some still regard GitHub as the best all‑round platform—especially thanks to its API—while others are experimenting with GitLab, local tools, or third‑party review UIs to reclaim performance and predictability.
Perception of GitHub as “Legacy”
- Many see GitHub as a big, aging Rails app with a bolted‑on feel: features feel scattered, some simple actions take too many clicks, and UI elements are hidden behind menus despite space.
- Others argue the tech stack (Rails vs React) is irrelevant; the problem is product design and UX decisions, not the framework.
UI Regressions and Lazy Loading
- A central complaint: lazy loading / virtualized views break basic browser behaviors like Ctrl/Cmd‑F and full‑document visibility (e.g., blame view, PR file lists, long diffs).
- Similar frustrations are reported with Slack, Jira, and GitLab: infinite scroll and partial rendering make search and navigation unreliable.
- Some defend this as an intentional performance tradeoff (smaller DOM, lower resource usage), but many feel the usability loss isn’t worth it.
Stability vs Constant “Modernization”
- Strong appreciation for tools that stay mostly the same (GitHub, VS Code), letting developers focus on other learning rather than re‑learning UIs.
- Others counter that GitHub has evolved substantially and positively (Actions, Codespaces, CI/CD integrations, Copilot), and that isolated annoyances don’t negate overall value.
- Several posters are wary that “modernizing” could further bloat and slow the UI, as already seen in parts of the site.
Code Review, Notifications, and Search
- Code review flow is viewed as underdeveloped relative to its importance: missing stacked diffs, code‑move highlighting, coverage indicators, and robust handling of rebases / PR versions.
- Collapsing large files or large diffs by default is seen as harmful for review quality.
- Notifications and Discussions are widely criticized as confusing or unusable; Actions logs have readability issues for some themes.
- Code search is viewed as only “moderately better”; some want deeper, AST‑based search.
Alternatives, APIs, and Local Tools
- GitLab is praised as faster and better in some respects, though also criticized for slow MRs and complex settings.
- GitHub’s API is seen as its strongest asset, enabling third‑party review tools and workflows, but its dual REST/GraphQL design and PAT transition are viewed as messy technical debt.
- Many recommend local or third‑party blame/diff tools (CLI, TUIs, IDE plugins) as better experiences than the current web UI.