我不确定这个 1% 的数字是从哪里来的，但有 1400 万用户，这仍然会禁止 14,000 用户使用 Discourse。仅仅是为了添加一些 CSS 和性能调整？
至于“应该有多少用户能够阻止剩余的百分比利用他们最新的软件？”……为什么不能是远小于 1%、更接近 0% 而不是 1% 的数字呢？我认为 Discourse 应该采取相反的方法，除非有压倒一切的关键修复或主要功能绝对需要它，并且有广泛的用户需求，否则不要进行不必要的向后不兼容的更改。
这个问题的反面是“我们愿意牺牲多少用户来追求一些微不足道的便利，而这些便利对用户来说影响很小或没有影响？”一个微小的性能提升，在除仔细基准测试之外的任何东西上几乎都无法察觉，是否值得将 14,000 人从他们的社区中剔除？
论坛用户渴望什么样的“最新软件”……？这是一个论坛。人们阅读文本并回复文本帖子。令人震惊的是，开发人员一直在说“我们必须不断前进”，而你们的实际客户却说，等等，为什么，这些功能都没有意义，而且你们正在抛弃真实的人。
我觉得这与像 Discourse 这样稳定、旧的论坛软件应该采取的方法完全相反。如果你想试验新功能，那应该发生在人们必须明确选择加入的不稳定金丝雀分支上，而主分支应该默认是 LTS。你不仅没有提供渐进式增强，也没有提供优雅降级。这是一个选择，而不是软件开发固有的部分。你选择的进步速度超过了用户的跟进速度。
你们托管的社区根本没有选择。那些为你们的社区付费的人，而不是为了让你们成为技术演示和 JS 游乐场。
这就是为什么这是一个文化问题而不是技术问题。感谢你至少愿意大声说出来。你权衡了开发人员小时数与估计用户影响的成本，而在你的计算中，用户不如使其成为基本发帖版本所需的成本有价值。别无他法：你不像重视开发人员的捷径那样重视你的真实用户和社区 
抱歉稍微断章取义地引用这句话，但是……如果你停止用百分比来思考，而是从真实个体用户在其社区中的影响来思考，也许计算结果会不同？
这一切都有些斯大林主义，告诉人们他们基本上是一个可消耗的统计数据，因为他们太穷而无法升级硬件，或者因为他们不愿意和能够跳过安装另一个操作系统或兼容层或浏览器分支的障碍而让他们自食其果……只是为了让他们能够继续在他们已经参与多年的论坛上发布文本消息？
这是我期望从一个主要的新版本（例如完全重写）中看到的成本效益，而不是从一些次要的、对开发人员不可见的、可能带来一些微小性能优势的功能中获得的 =/ 我认为你们公司采取这种立场真的令人遗憾，但仍然……我真的很感激你们的坦诚。
好的。总之，抱怨够了。我有一个可能/有希望更具建设性的问题……
如果我们假设一个基本的 HTML 模式对少数用户有帮助，但 Discourse 不想自己投入资源来构建它……这对开源社区来说是否可行？它似乎太大了，不能成为一个插件，但又太小而不能成为一个独立的项目（例如 Discorkie）。
尝试将其范围限定为一个与当前 API 配合使用的替代开放前端是否可行，如果可行，是否有机会让这样一个（如果建成并经过测试）被“官方”接受/集成到主软件中以便也可以在托管的 Discourse 实例上使用（我的一个受影响的社区就在那里）？
沿着这些思路，你们是否有任何 API 版本控制/稳定性系统，供这样一个替代前端跟踪？
也许答案仍然是各种“否”，原因各不相同，如果是这样，那也没关系，但如果它在某种程度上是可行的……也许值得思考一下？不要求进行全面的可行性研究，也许只是一些直觉？
我不确定这样的东西是否能成功或得到维护。没有多少开发人员喜欢使用 HTML 和最少的 JS 来处理旧软件（但仍然有一些，比如 HTMX 的开发者）。只是一个想法。