工程师对 Web 开发的那些信念

浏览器渲染性能与替代方案

• 有些人不同意浏览器“擅长”复杂、长生命周期的 DOM 树；也有人认为，数十年的优化让浏览器在动态树方面很难被超越。
• 提到的替代方案：内置数据绑定/模板的 WPF（Windows）和 Avalonia（跨平台）；以及游戏引擎和 WebGL/canvas 渲染器，它们很容易处理成千上万个动画对象。
• 例子：Figma、Google Docs/Sheets 以及 web 版 Photoshop 绕过了 DOM 的很大一部分，改用 WebGL/canvas/WASM；有些人把这看作 DOM 并不适合复杂 UI 的证据。

JavaScript、优雅降级与可访问性

• 一小部分声音很大的用户主张网站在没有 JS 时也应能工作，尤其是内容站点和简单 CRUD 应用，以提升健壮性、测试性和可访问性。
• 其他人认为禁用 JS 的用户几乎可以忽略，并且商业现实并不值得为了他们去设计。
• 反驳点：不稳定的网络在实践中也可能“禁用” JS；微型浏览器/爬虫不会运行完整 JS；而沉重的 SPA 在低端设备或移动设备上会降低用户体验。

SPA vs MPA、交互谱系与工具选择

• 一个大的主题是：Figma/Photoshop 经常被过度拿来作为在大多是 CRUD 的应用里采用 SPA 技术栈的理由。
• 一派观点：对于更简单的应用，偏好最少的 JS、服务端渲染的 MPA；复杂性应该留在后端；SPA 是一种“motte-and-bailey”（在富编辑器场景下显然正确，但对大多数应用来说论据很弱）。
• 另一派观点：SPA（React/Preact/Vue 等）在富交互场景下在架构上更简单，随着功能增加会累积收益，并且能提供更顺滑的 UI（例如分面筛选、地图）。
• 许多人指出了中间路线：渐进增强、局部 HTML 更新（类似 Turbolinks/Hotwire）、服务端组件、islands/SSR，以及把隔离的 SPA 小部件嵌入 MPA 中。
• UX 取舍：SPA 可能感觉更快、更流畅，但往往会处理不好历史记录、在间歇性连接下失效，并且会发送很大的 JS 包；MPA 如果不优化，可能会闪烁并显得“突兀”。

构建步骤、工具与 DX

• 有人认为“Web 不应该需要构建步骤”；构建流水线会增加延迟、复杂性，而且当回头维护老项目时经常出问题。
• 也有人为构建步骤辩护，认为它们能带来 tree-shaking、打包、HMR，以及通过 TS/Rust/WASM 实现静态类型，同时也指出 JS 构建工具链异常脆弱且变化很快。
• 提到的替代方案：简单的服务端 include、静态站点生成器，或者直接把管理界面嵌入后端服务，而不是单独做 Node 前端。

桌面应用 vs Web 应用与沙箱

• 一方更喜欢把重型应用作为原生桌面软件运行，并把浏览器视为文档查看器。
• 另一方则强烈偏好在浏览器中运行这类应用，因为有沙箱和更容易拆除，理由包括某些侵入式原生客户端（例如始终运行的后台进程）。
• 很长的子讨论争论浏览器是否比原生或移动应用“更安全”，还是说它只是另一层（非常复杂的）沙箱；同时也有人担心 Chromium 的单一化，以及应用商店双寡头的问题。

其他反复出现的主题

• 经常出现的张力是：“现在能工作的最简单工具” vs “未来可能覆盖更多需求的灵活工具”。
• 对简历驱动和潮流驱动的技术选择的抱怨。
• 观察到浏览器规范和引擎团队通常缺乏日常 Web 开发的视角；反过来，很多 Web 开发者也误解了引擎的约束。