用 React 重写后,GitHub UI 越来越慢

我不得不注意到——最近 GitHub 的界面变得越来越慢。以前反应迅速的功能现在变得异常缓慢。GitHub 似乎在做一些奇怪的事情,我实在无法理解那里发生了什么。

你们在 GitHub 上开发,你们不是用 GitHub 来开发的吗?你们难道没有注意到这个问题吗?到底发生了什么?

每当遇到让我抓狂的慢速网站时,我都会打开开发者工具进行性能分析。说不定能发现问题并提交反馈,让问题得到解决。

以一个典型例子为例,这是在 PR 中从“对话”标签切换到“已更改文件”标签时的性能分析结果。

在查看分析结果之前,请注意这需要超过5秒。在2025年,这样的情况如何能被接受,我实在无法理解。

图0:用 React 重写后,GitHub UI 越来越慢

若深入分析,你会发现GitHub使用Turbo技术预加载下一页并通过内容替换实现无页面刷新切换。此类操作通常作为性能优化手段,但在此场景下却显得完全不合理。

元素周期表

如果你在家尝试并玩弄一下,你会发现在新标签页中打开“已更改的文件”链接实际上快了两倍:

图1:用 React 重写后,GitHub UI 越来越慢

而且不仅如此——第一个配置文件中的客户端后处理实际上比从服务器加载 HTML 更耗时。整个事情完全说不通。

最令人抓狂的是新的加载条,因为它让我意识到整个过渡过程有多慢:

图2:用 React 重写后,GitHub UI 越来越慢

各位……能不能让过渡过程足够快,以至于不需要新的加载条?比如,既然客户端路由已经实现了,为什么还要重新创建一个比完整页面重新加载更慢的体验?使用单页应用(SPA)的初衷就是为了避免这种情况。客户端路由应该瞬间完成。

这是GitHub上众多性能问题之一。以前并不是这样。现在浏览多个PR和问题简直是一种折磨。想象一下,你有20个PR需要找出哪个引入了回归,而每次点击都需要超过5秒才能显示内容。

更不用说差异视图本身了——是的,就是那个在浏览大型PR时会定期冻结2秒的视图——也许这与它渲染了数千个带有相同内联SVG图标的不可见加号按钮有关:

图3:用 React 重写后,GitHub UI 越来越慢

图4:用 React 重写后,GitHub UI 越来越慢

或者,你知道的,也许不尝试渲染100 000 DOM节点也会有帮助。

当你调整开发工具窗口大小以对该功能进行性能分析时,整个窗口会冻结3秒钟。

这种情况会有所改善吗?🔗

因此,当一些热门问题与性能相关时,GitHub似乎也关注“大规模平台协作” 重点领域在路线图中,也许情况会有所改变?

让我们查看路线图,看看是否能找到任何内容 相关内容与性能相关。你找到了吗?

共有 111 条评论

  1. 自GitHub开始用React重写所有内容以来,其性能一直在迅速恶化。

    现在几乎无法查看差异,因为它们经常无法加载、渲染不正确,或者速度极其缓慢。

    • 是的,这次转向React确实令人烦恼。GitHub也停止支持旧版浏览器。

      我的备用笔记本是一台旧款 MacBook,运行 Firefox 78.15.0esr。大约一年前,我便无法再用它查看 GitHub 文件和问题讨论。虽然大多数时候还能查看 README,但现在必须使用 Chromium 或另一台电脑才能在不克隆仓库的情况下阅读代码。

      如果他们愿意设置 esbuild 目标,其实可以轻松为旧版浏览器生成 JS 代码。

      • 微软的几乎所有服务——管理中心、Entra、Defender等——加载速度都非常慢,并且会显示更多的“银色闪烁效果”。

    • 自从 React 重写以来,一切都变得更糟。一切都变得更加缓慢和卡顿。像“后退按钮”这样的功能也一直出现异常(我多次报告过这个问题,经过长时间的延迟后他们修复了几次,但几周后又会再次出现故障——我已经放弃了)。

      一些设计决策也令人费解,比如将“新建问题”放在一个小弹出窗口中,而不是直接使用全屏页面(除非你设置了模板)。屏幕使用率不到一半的设计毫无帮助,只会降低问题报告的质量,因为这简直是糟糕的用户体验。令人费解。我真怀疑设计/开发这个功能的人是否自己用过 GitHub(他们撤销了其他一些荒谬的“你们是怎么认为这是个好主意的?!”功能,但没有撤销这个)。

      我还有很多其他抱怨和 bug;点击“显示原始代码”通常更适合查看代码(或直接本地克隆)。这简直令人尴尬。但报告这些问题毫无意义,因为没有任何改进,情况只会越来越糟。

      GitLab 曾是“GitHub 克隆版”,但现在 GitHub 似乎正在变成“GitLab 克隆版”,将一切变成一个缓慢、卡顿且勉强能用的混乱系统。

      • > 像“后退按钮”这样的功能也一直行为异常

        啊,好,看来不只是我一个人遇到这个问题。在 GitHub 上,后退按钮会带你回到多少个页面已经变得不可预测。有时它会直接带你到一个损坏的、永远加载不完的页面。这些问题在网页上本应早已解决。

        • 在单页应用(SPA)中,这种情况经常发生。原来让客户端代码负责路由会导致大量脆弱性。

    • 我特别欣赏当差异是新增一个文件时,计算差异或背后正在做的事情仍然需要很长时间。

    • 我不知道具体背景,但在我的M1 Mac上,当差异超过5000行时,差异查看器几乎无法使用。

      • 这就是你的第一个问题。如此规模的差异本身就太大了。

        • 经过多年的计算技术进步,到了2025年,居然还无法显示5000行差异,这实在令人失望。

          • 我的意思是,如果你需要审查超过5000行的代码,这表明你的PR(拉取请求)过于庞大,应该拆分成更小的更改。

            • 这不一定是代码。我有时需要审核翻译内容,这类工作通常是批量处理的(单次批次包含数千个字符串)。这类内容缺乏结构性,不像审核某些复杂的多线程算法那样,只需快速浏览确保结构完整,没有突兀的文本块或不必要的粗俗语言即可。

              总之,之前能正常工作,现在却不行了。回应不应该是“你操作方式不对”。

            • 当你在大型代码库中重命名一个广泛使用的类型,或尝试将其他许多事情拆分成小改动时,这种做法毫无意义。我完全理解偏好结构良好的小改动,但“大改动就是错误”的极端观点是错误的。

            • 我并不总是审查代码。有时我只是在查看两个代码版本之间的差异,而这些差异可能包含多个提交。

            • 如果有人添加了一个5000行文件,我通常更愿意将其作为一个整体进行审查。而且,有时一个5000行文件是完全合理的。

    • 我对他们于2023年发布的关于此主题的技术博客文章感到困惑:https://github.blog/engineering/architecture-optimization/cr

      他们完全重新设计了代码导航功能,改用 React 动态加载代码。其中一个引入的回归问题导致在使用 Ctrl+F 搜索单词时,搜索结果会出现重复项。他们解决此问题的方案是:将源代码按字符分解,为每个字符分配独立的 HTML 节点……

      不用说,除了性能极差(在我的笔记本电脑上显示需要几秒钟)外,这还引发了新问题(例如无法搜索某些复合表情符号)。最糟糕的是,他们似乎对这个 hack 感到自豪,因为他们为此写了一篇博客文章。

      • 在GitHub Actions日志中查找字符串简直不可能。更不用说打开大型日志时,需要花费数秒的动画滚动才能到达末尾。

        虽然有“查看原始日志”按钮,它会打开一个纯文本文件,我的浏览器可以立即加载并搜索(想象一下),但对于仍在运行的任务无效。

      • 哇,这篇文章太棒了。他们观察到他们的页面运行不佳,因为它有太多 DOM 节点,而他们甚至没有讨论过尝试使用更少的 DOM 节点来创建一个可用的页面的想法。相反,他们添加了各种复杂性和更多节点 (!) 来让它勉强运行。

        一个网络浏览器可以很好地渲染和搜索一个无聊的纯 HTML 语法高亮源文件。

    • 就连热爱 React 的科技博主,如 Theo Browne,也对 GitHub 在这方面的表现提出了严厉批评。

      据我所记得,他们将差异页面设置为在某些元素发生变化时,强制更新页面上的所有响应式元素,而不是仅更新发生变化的那个元素。

    • 最近有一段视频对此进行了讨论,并配有很好的可视化演示 [0]

      问题的根本原因与 React 的设计理念和团队设计的响应模型密切相关。简而言之:React 采用了一种 倒置的状态管理模型 [1].

      在 Vanilla、Vue、Svelte、Solid 等基于信号的响应模型中,你需要通过将代码移入响应式回调函数来显式 选择加入 状态变化。事实上,在几乎所有你编写的代码中,你通常都需要显式地选择加入状态变化。

      而在 React 中,你需要显式地_选择退出_状态变化,即将代码移出响应式回调函数——因为整个组件函数本身就是响应式回调函数(因此,任何位于该函数路径中且不应触发重新渲染的状态都必须通过钩子函数移出)。

      这种根本差异使得 React 在大规模应用中难以做好,因为需要非常清楚地知道如何在组件内部放置状态,以及如何通过备忘录优化性能 [2](这是 Vue 和 Svelte 开发者几乎从未考虑过的问题)。React 团队花了两年时间构建编译器来自动管理备忘录,但从我看到的基准测试来看,这几乎没有带来任何差异。

      在此期间,Vue 正在开发“Vapor Mode”[3],该模式绕过虚拟渲染树(VDOM),使其与 Svelte、Solid 以及原生 JavaScript 几乎持平,同时仍保留了易于理解的响应式模型。

      [0] https://youtu.be/INLq9RPAYUw

      [1] https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-mo

      [2] https://tkdodo.eu/blog/ 备忘录化的艰难历程, https://tkdodo.eu/blog/the-useless-use-callback

      [3] https://www.vuemastery.com/blog/the-future-of-vue-vapor-mode

      • 是的,你不能把遇到的每个性能问题都归咎于一个特定的主题,仅仅因为你看到了一段YouTube视频。

        如果你查看性能图表,你会发现大部分时间都花在重新计算CSS样式上。不幸的是,我无法深入研究,因为我的机器上没有遇到相同的问题。也许这与成千上万个渲染的DOM节点有关——我不知道,但这与响应性无关。

        • 这不是因为YouTube视频,而是因为YouTube视频提供了一个很好的演示。我从90年代末就开始使用JS,见过各种前端技术栈的兴衰,所以对我来说, React具有这种倒置的特性,而正是这种倒置的特性是导致其在大规模应用中实现良好性能成为一项技术挑战的根本原因,因为它要求工程师仔细考虑备忘录和状态放置——这是在原生JS和早期框架如KnockoutJS中不会发生的事情。

      • 有趣的是,将此与布兰登·罗德斯(Brandon Rhodes)在2022年设计模式演讲中对React的评估进行对比,该评估本质上是对观察者模式的批判:https://www.youtube.com/watch?v=pGq7Cr2ekVM?t=28m45s 。(值得注意的是,在演讲后半段,当他用一个以图形用户界面为动机的示例描述中介者模式时,他提前说道:“我知道我刚才告诉你们要使用React”……但随后描述听起来对我来说非常像是React本身就是中介者模式的实现!)

        • 所有现代前端框架本质上都是观察者模式,区别在于状态变化的传播方式存在两种流派。

          在基于信号的平台(Vue、Svelte、Solid)中,信号会触发特定订阅者和回调函数,开发者需主动选择订阅状态变化。

          在 React 中,尽管 `useEffect` 看起来与 Vue 的 `watch` 非常相似,但它们的行为完全不同,因为整个组件都被注册为回调。

          我上面第二个链接 [1] 中的代码示例值得一看,因为它非常清楚地展示了这些库在代码上有多么相似,但在传递更新信号的方式上却有多么不同。

    • 他们使用的是原生 JavaScript 吗?如果是的话,这很了不起。

      • 他们使用原生 JavaScript 超过十年。他们是 PJAX 技术(实际上与 HTMX 的工作原理非常相似)的早期倡导者:https://github.com/defunkt/jquery-pjax

        我猜想,随着时间推移,他们越来越难招聘到不坚持用 React 重新构建一切的前端开发者,最终他们放弃了。

        • 我认为有两个原因:

          1. 早期 Web Components 的倡导者[1]对“原生”Web Components 非常热衷。Web Components 是低级 API,缺乏框架的易用性,没有库的帮助就难以使用。对于少数由真正信仰者构建的元素来说,这没问题,但当你将它扩展到复杂应用中的每个组件,并且涉及公司范围内的团队时,你就需要声明式和响应式 API 带来的易用性和一致性设置。

          2. GitHub Next 团队选择使用 React 进行开发,因为他们需要高效的开发体验来快速推进工作,且该团队独立于生产应用程序团队运作。我认为他们首个被整合的功能是 Projects,且他们可能已证明其组件具备更优的开发体验(DX)。基于开发体验的论点,招聘策略将随之确立。

          我见过几次类似情况:Web Components 团队认为其核心价值在于无需依赖外部库,因此坚持不使用辅助库,结果却因追求易用性而被专有框架取代。若他们当初使用了易用的 Web Components 辅助库,或许就能继续沿用该技术。

          讽刺的是,这些过渡通常比框架到框架的迁移要容易得多,因为Web组件具有固有的互操作性。我仍然认为这是Web组件的优势:从道德和实际角度来看,技术应该尽可能容易迁移。

          [1] GitHub 对 Web 组件非常热衷,他们经常派代表参加 W3C 会议来推动相关工作,但过去 10 年间,原团队的大部分成员已离开公司。

          • > Web Components 是低级 API,缺乏框架的易用性,除非有库来辅助。对于少数由真正信仰者构建的元素,这没问题,但当你将它扩展到复杂应用中的每个组件,并涉及公司级团队时,你就需要声明式和响应式 API 带来的易用性和一致性设置。

            GitHub 确实拥有自己的声明式半响应式 Web 组件框架。它相当不错!

            https://github.github.io/catalyst/

            它与 HTML 中已发布的(更轻量、更简单的)Invoker Commands API 有一些相似之处(它们共享主要作者):

            https://open-ui.org/components/invokers.explainer/

          • > 2) GitHub Next 团队选择使用 React 进行开发,因为他们需要高效的开发流程来快速推进工作,且该团队独立于生产应用程序团队运作。我认为他们首先整合的是项目,他们可能能够证明他们的组件具有更好的 DX。从人体工学论点出发,招聘论点就会成立。

            外界也有一种印象,即 GitHub Next 团队也面临着使用大语言模型 (LLM) 的巨大压力,特别是在新功能的构建方面。

            似乎存在一种明显的“乌罗波罗斯/滚雪球效应”,即大型语言模型(LLMs)由于在React代码上接受了大量训练,因此对React最为熟悉。正因如此,我们的目标应是将项目迁移至React和React Native,以充分利用LLM带来的“速度与生产力提升”。

            我目前就像一枚即将被牺牲的棋子,卷入自己日常工作中关于是否应更多转向React以让高管和股东对我们的“AI无处不在”战略更满意的冷战。唉。

      • Github最初于2008年使用Ruby on Rails开发。React于2013年向公众发布(尽管在此之前已在Facebook内部使用)。

        如果我们通过Wayback Machine[0]查看2010年Github的源代码,可以发现当时他们与大多数网站一样使用了jQuery。

        [0] https://web.archive.org/web/20100115102310/http://github.com…(有趣的是,elan/plex 显示为最近更新的仓库!)

      • 他们当时使用了Web Components,现在仍然在使用。但他们聘请了一支团队进行实验,以构想GitHub UI的未来,而该团队使用React构建了所有内容。目前,该团队的工作正在被移植到生产环境的UI中。

        • 只需使用那个能让React渲染速度提升1000倍的工具,比如million JS之类的东西

        • 此外,作为他们那次荒谬的 React 重写的一部分,除了让一切变得慢得离谱,他们还搞砸了基本功能,比如 Safari 上的前后按钮,这个问题直到最近才修复,但在长达 9 到 12 个月的时间里,iOS 用户根本无法使用。

          真心觉得参与推动这次重写的人都该被解雇。

          • 我知道你只是在表达 frustrations,但你传播的“做这件事的人应该被解雇”的 meme 相当有毒。这样的决策绝非一人之过,即便真是如此,你所感知的问题也与未被感知的问题进行了权衡。而且,即使这确实是一个纯粹的错误,那也只是……一个错误。你因为犯错就被解雇了吗?

            我想我真正想说的是,如果像你这样的人能降低言辞的激烈程度,减少愤怒,增加同理心,互联网会是一个更好的地方。

            感谢你的倾听。

      • 我记得以前大部分都是服务器渲染的?

        • 大部分仍然是服务器渲染的。

          • 我认为现在大部分内容都是通过JSON API加载的,HTML则通过React在JS中渲染。也许甚至全部都是?

            例如,文件概述页面有14个(!)请求(/recently-touched-branches、/latest-commit、/overview-files/{branch}等)。

            问题列表使用了5个(!) GraphQL API请求。我没有深入研究为什么需要五个请求。

      • 现在大部分UI都是React,尤其是最常用的区域。

        • 父评论实际上在询问他们使用 React 之前在做什么……别担心,你可能误解了他们,这没关系!

    • 我怀疑这是 React。GitHub 应用刷新通知需要 3 到 4 秒,而我的列表中只有大约 20 条通知。

  2. 很明显,他们让一群初级开发者负责前端开发,我惊讶的是它还能正常工作。

    之前的AJAX实现也有其反对者,但至少它非常接近纯HTML在HTTP上的实现。

    • 有时功能已经无法正常工作。例如最近,我使用 Firefox 时无法创建组织。点击绿色按钮后页面会卡住。不明白他们怎么会搞砸这个功能,但切换到 Chromium 后就能正常使用。这本应只是提交表单的简单操作,但不知为何他们搞砸了。

      • 使用Ctrl+Enter在新标签页中打开问题… 他们是怎么搞砸这个功能的?

    • 也许他们已经将大部分开发工作交给了AI?

    • 别忘了,他们投放到前端的许多初级开发者都是GitHub Copilot。Vibe编码已成为GitHub的新指令,因为他们对内部测试非常认真。

  3. 它也变得越来越不稳定。去年10月或11月左右,我发现每周都会遇到一些SPA的性能问题。因为某些组件在视图上方出现或消失,导致我失去滚动位置。问题列表显示的是数小时前的状态且未刷新。某个按钮无法正常工作。页面加载后,标题以下的内容没有样式。我展开构建详细信息,但每次阶段完成后它都会自动折叠关闭。文件名标题出现两次。新评论没有显示。如此这般。

    看到一个花了15年时间逐渐融入可靠基础设施背景的工具,现在却变成一个 intrusive、令人分心的混乱,这非常令人沮丧。

    使用jujutsu几个月后,它几乎完全取代了我对git的使用。这虽然有些奢望,但正如jujutsu通过整合过去数十年的版本控制系统(VCS)实现了重大改进,我希望有人也能为与jujutsu协作的工具做同样的事情。GitHub的PR功能令人遗憾地停滞不前,因为其流行度使得修复核心UI设计问题变得极为困难,这些问题包括多标签页、时间线不连贯、编辑提交、缺少“8条更多评论”提示,以及如今不断出现的单页应用(SPA)卡顿问题。

    GitHub剩下的最大特點是同事和潛在貢獻者已經登錄的網絡效應,可能會有一場競爭,一方通過雙向同步(參見git-bug)來中和這一效應,另一方則是GitHub解決其可用性問題。微軟對破壞性變更的傳奇般抵抗意味著有一個非常大的窗口期。

    • 我最讨厌的 GitHub UIUX 问题是,当我处于某种复杂视图时,无法返回根仓库页面,或者无法在 5 次点击内到达作者的个人资料。

    • 代码审查变得少了很多乐趣(它们从来就不是很有趣),因为你的滚动条总是卡住

  4. 我很高兴看到我的感受得到了验证。我总是对一些原本良好、功能强大的软件被改得更糟感到不满,因为有一个庞大的工程团队必须处理某些事情,他们改变了这些事情,结果导致软件质量下降。

    我注意到 GitHub 的 UI 变得迟缓,以为可能是自己出了问题或“我的机器”有问题,因为 GitHub 不会这样做……但我想,要阻止一群开发者、经理和产品经理做出改变以证明他们仍值得留任,确实很难。

  5. 我忍受着这一切,这就是为什么我正在构建https://githero.app

    顺便说一下,我在GitHub工作了三年,他们非常清楚速度问题是整个产品线的大问题。曾有一个为期一年的跨团队努力来改进这些问题,但在我看来,主要目标并未实现,这一点显而易见。

    • 这看起来很酷!你有隐私政策吗?

      • 谢谢!

        好问题。我现在还没有,但可以尽快准备一份。无论如何,我不会存储任何用户信息。当你登录时,流量会直接从你的浏览器发送到 GitHub。

    • 你希望提供哪些在GitLab中找不到的功能?

      • GitLab是一个完全不同的平台。

        这个项目旨在解决最广泛使用的Git服务中糟糕的用户体验问题。我不敢尝试说服整个团队或公司迁移到GitLab,但这个项目可以轻松被采用。

      • 我的主要目标是提供比 GitHub 更现代、更流畅的体验,添加一些额外功能,如推送通知、通知分类、更好的编辑体验等,并集成桌面应用与本地 Git。

        • 我的观点是,已经有许多 GitHub 的替代方案,因此你需要更明确地定义自己的定位。

          • 这并非 GitHub 的替代方案,而是替代前端。后端仍为 GitHub。

  6. 作为一个有趣的反向用户界面体验示例,这段视频解释了为什么McMaster-Carr网站的使用体验如此流畅:https://youtu.be/-Ln-8QM8KhQ

    它与 GitHub 有许多不同之处(没有用户生成内容,每天主要是静态页面),但看到浏览体验可以如此出色确实令人感兴趣。这合乎逻辑,因为该公司价值很大程度上取决于让用户快速轻松地找到所需内容。

  7. 代码查看器对于超过一百行的文件完全无法使用。我不得不克隆它并在本地浏览。

    这种情况至少持续了一年。难道GH没有人实际使用自己的网站吗?

  8. 它与Facebook的用户界面以及FB for Business下的所有内容(管理广告、Instagram评论等)非常相似。这显然是因为React以及客户端渲染逻辑的广泛使用。

    考虑到像 GitHub 这样的网站实际上只需要管理如此少的交互性和 DOM 状态,这简直令人难以置信。

  9. 它的性能下降得如此严重,我甚至怀念起过去那令人愉悦的用户体验。现在,我的项目都托管在自宅的一台旧树莓派上运行的 forgejo 实例中,与之相比,它的速度快得令人惊叹。

  10. 你用过其他微软的网络服务吗?它们都又慢又糟糕

    • 确实,与Azure Dev Ops相比,GitHub仍然快如闪电。

      自微软收购GitHub以来,Azure Dev Ops一直处于停滞状态,运行缓慢如蜗牛,且缺少一些相当重要的功能,但微软也拒绝正式放弃它。

  11. 使用符号浏览器(或类似工具)在文件中追踪定义很方便,但这会导致浏览器后退按钮完全失效。通常URL会切换到之前的历史记录状态,但页面内容却不会更新。尝试用更改后的URL重新加载页面也无法正常工作,原因不明。

    如果这个功能能正常工作,那将是一个非常棒的特性。

  12. 我开发了一个与 GitHub 提交请求界面竞争的工具(codeapprove.com)

    该工具基于 Vue 构建。我最初的 5 或 6 次尝试在处理大型差异时速度非常慢。经过大量优化后,现在我对它的响应速度感到非常满意。

    我并非在为自己打广告(这更多是个个人兴趣项目而非商业项目),而是想说明:利用 GitHub 的 API 结合前端框架,确实可以打造一个响应迅速的 GitHub PR 界面。关键在于是否用心。目前尚不清楚 GitHub 是否真正重视这一点。

  13. GitHub、Facebook、Reddit、Instagram(网页版)……这些主流网站正变得越来越难以使用。我的直觉是“单页应用(SPA)的问题”,但我相信可以打造出优秀且流畅的SPA。我漏掉了什么吗?

    • 你能做到?我还没见过。

      • 十年前的Google Maps还不错。还有刚推出时的Gmail。那时候的客户端硬件也更差。

        注意,我没有提到它们的_当前_版本……

      • 确实可以这样做,但这需要一套远落后于应届毕业生和编程训练营的技能,并且要放弃当前领导层的口号“所有工程师都是可替换的,所以随便把那个随机团队扔过去学习React就行了”。

        在几乎所有FAANG公司中,前端工程师的薪资都低于普通软件开发工程师,因此你看到很多前端工程师想转行。这种管道中很少保留高级人才。

        • > 前端工程师的薪资在几乎所有FAANG公司都低于普通软件开发工程师

          根据我过去五年的经验,查看两份招聘广告并比较薪资范围,通常是相同的。哪家FAANG公司还在这样做?

  14. 我正在构建一个新的Git托管服务,专注于性能并使用HTMX。例如,比较页面加载时间:

    https://gitpatch.com/gitpatch/git-demo

    https://github.com/git/git

    • 与Codeberg相比如何?

      • Codeberg的界面与GitHub非常相似,因此作为GitHub的替代品非常出色。它基于Forgejo,这是Gitea的分支。

        Gitpatch 则有所不同。它从头开始实现了新的存储后端和 Git 库。它还采用基于补丁的模型进行代码审查,而非拉取请求,其中使用特殊命名的分支提交补丁和补丁堆栈。

  15. 将 GitHub 恢复到 2012 年的任何提交。只需代码、PR、问题,快速且可靠。删除其他一切并将其抛入大海。我愿意为这个产品支付更多费用。

  16. 我仍然认为使用经典的服务器端模板 + JavaScript 的渐进增强来构建网页前端是更优的选择。

    可惜一切都必须用 React 重写。

  17. 这让我想起Casey Muratori和Robert Martin关于干净代码及其对性能影响的讨论……但并非因为讨论内容。他们使用GitHub作为讨论平台,当输入数百个字符的段落时(Ctrl+F表情符号,约四分之一处)遇到了严重延迟:

    https://github.com/unclebob/cmuratori-discussion/blob/main/c

  18. 哇,经过十年对单页应用(SPA)和那些华而不实、完全多余的框架的盲目模仿,每个网页界面都变得一团糟!没人能预料到这一点。

  19. 如果你只是需要一个存放代码的地方,自托管的Gitea非常简单。

    你的可发现性将降至接近零,而且设置动作会更复杂。此外,你还需要制定一个备份计划。

    但,你将把代码托管在自己的机器上,微软将完全置身事外,如果你将仓库设置为“私有”,就不会为AI提供数据。

  20. 更慢且更常出现故障,堪称完美组合!

    • 他们在大规模改版中引入的导航问题(后退按钮、分页问题等)令人抓狂

  21. 我很高兴有人记录了这一点。这让我快疯了。我最近几周一直处于高压工作状态,因此工作流程中的各种小问题都变得格外明显。PR“标签”之间的UI切换是其中最糟糕的。

  22. 相关持续讨论(即由于原帖已发布数月,我推测其与以下内容相关):

    GitHub pull requests were downhttps://news.ycombinator.com/item?id=44799494 – 2025年8月(113条评论)

  23. 是的,即使在某些元素无法正确渲染样式且按钮无法正常工作的情况下。我希望有一个使用更基础 HTML 的 GitHub 前端,以便在旧版浏览器和较低网络速度下也能正常运行。

  24. 他们不能用 AI 重写整个系统以提升速度吗?

  25. > 你们在 GitHub 开发,难道不是用 GitHub 来开发的吗?

    他们可能在使用内部测试版,以便在正式发布前先“吃自己的狗粮”。

  26. 有趣的是,GitHub 仍在使用 React,而 Edge 已经开始迁移到 Web Components,这与 React 相关的性能问题有关。

  27. 网站在我这里不断崩溃。我以为这是微软在搞他们惯用的把戏。

  28. 有趣的是,iOS应用在我这里运行得非常流畅。

    性能、易用性和整体适配手机尺寸的能力,原生应用能做到如此出色真是令人惊叹。

    我希望网页界面能像原生iOS应用一样流畅。

  29. 如今用户体验设计出现全新范式:取消即时页面切换和加载状态,而是让用户留在同一页面直至内容加载完成,加载完毕后再显示。

    • 现代浏览器已默认通过服务器渲染页面实现这一功能。无需任何JS黑客手段。(且浏览器界面会正确显示加载状态。)

      • 现代浏览器甚至可以通过View Transitions CSS在服务器渲染页面之间进行动画过渡。

  30. 我的电脑一遇到任何“动态”JavaScript按钮开始加载就会卡死!终于发现我不是唯一一个遇到这个问题的人,真好!

  31. 我一直好奇为什么 iOS 上的后退按钮在 GitHub 上无法使用,这种客户端路由的缺陷完全说不通

  32. 一旦公司实现市场主导地位,唯一能迫使公司关注用户体验的只有其管理层。

  33. 显然,如果你在这样的网站上使用任何类型的JavaScript,事情就会变得一团糟。Git解决方案如Forgejo正在超越GitLab和GitHub,它以令人难以置信的速度渲染一切。

    令人失望的是,开发者仍然试图为大型网站如Git上的JavaScript辩护。

  34. 我立即注意到侧边栏和其他更新后的速度变慢。我以为他们会很快修复它,但没有… 现在看来,他们似乎只支持这种浏览方式!

  35. 今天发生故障,时机真是巧合

  36. 哦哦,我知道这个!因为这是微软!

  37. 我注意到查看差异是个痛点,无法加载整个内容。

  38. 在网页开发中,前端产品开发人员没有动力去加快功能的实现——公司的一般做法是“先发布,后优化”。

    GitHub是少数几家会关注性能的公司之一,但在绝大多数情况下,东西只是变得稍微慢了一些,没人会在意。

  39. 因为微软收购了他们。

    • 微软收购后,GitHub 确实有所改善,并开始实现长期以来被要求的特性。(那封在收购前发布的公开信“亲爱的 GitHub”之类的。)

      这是最近的事情。

      • 是的,还记得从代码视图复制任何内容时也会复制行号吗?这是一个相对较小的CSS修复,但花了数年时间!

        我一直不明白为什么之前没有修复这个问题,因为这真的不算太难。通常当$big_corp收购$small_outfit时,事情会变得更糟而不是更好,这是因为$big_corp的过度干预政策、文化冲突、领导层不真正理解他们收购了什么,以及类似的问题。

        无论对微软有何评价:在他们收购 GitHub 后的那一年或两年里,许多大小问题都得到了修复或改进。

      • 大公司做事向来不快

        就像一场极度缓慢的车祸

  40. 有时感觉DNS出了问题,因为页面就是无法加载,有时只有导航栏能加载,但没有内容——这就是你所说的状况吗?

  41. 这是TurboLinks和Rails

    • 之前确实是这样(加上Web Components),但我们现在讨论的这个糟糕版本是React,它简直就是问题的主要根源之一。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

链接收藏


京ICP备12002735号