Linear 怎么这么快？技术拆解

乐观 UI 与“同步引擎”

• 许多评论指出，核心思路大家都很熟悉：带后台同步的乐观客户端更新，类似 Meteor、Google Docs，或多人游戏里的客户端预测。
• “同步引擎”被视为一种正式化的方法，用来管理规范化的客户端状态存储、乐观变更和回收（reconciliation），一旦到位，能让 UI 代码更简单。
• 也有人认为这篇文章把这种模式过度包装成一种新颖或独属于“Linear”的东西。

正确性、一致性与失败模式

• 一个强烈的担忧是，乐观 UI 可能会“欺骗”用户：UI 在服务器提交前就显示成功。
• 讨论中提到的场景包括：网络失败、同步前标签页/浏览器关闭、长时间离线、模式漂移、冲突编辑、删除与编辑、重排序冲突。
• 有人说冲突率很低，优秀的同步引擎可以处理回滚、冲突解决和离线重试；也有人说这在实践中非常难，容易导致数据丢失和用户困惑。
• 浏览器存储的持久性也存在争议：它可能被清理，把它当作事实来源被认为很冒险。

延迟 vs 架构（本地优先 vs 快速 CRUD）

• 一方认为，通过合适的后端部署、高效的技术栈和良好的 SSR，典型 CRUD 操作可以达到约 30–100 ms，因此不需要复杂的本地优先同步。
• 另一方反驳说，全球延迟、物理距离和尾延迟意味着许多用户会看到约 300 ms 以上的往返时间，所以只有本地优先才能感觉“瞬时”。
• 讨论还涉及分片/租户本地区域与全局共享状态；而且“把数据库搬得更近”本质上还是在重新实现分布式同步问题。

实现细节与工具

• IndexedDB 常被使用，但被认为很笨拙；文中提到 idb、localforage、TinyBase 以及基于 SQLite 的 WASM 方案等封装。
• 有人提到专门的同步产品（Zero、Replicache、PowerSync 等），认为它们可以在不自建引擎的情况下实现类似 Linear 的行为；也有人不喜欢 DSL/厂商锁定，更偏好自定义、基于 SQL 的复制。

Linear 的 UX 与感知性能

• 对 Linear 的 UX 和速度，意见分歧很大。
• 支持者称它是最好的、最快的 Web 应用之一；相比 Jira 及类似工具是巨大提升。
• 批评者则报告高 CPU/内存占用、搜索和首次加载慢、界面令人困惑或“隐藏”、标签页行为不稳定、同步“卡住”状态，以及功能逐渐臃肿。
• 还有几条评论指出，核心交互时性能可能很好，但首次加载或搜索延迟削弱了“它就是这么快”的说法。

何时使用同步引擎

• 很多人认为本地优先同步很强大，但并不简单，最好留给那些真正需要瞬时、协作式 UX 的应用。
• 也有人认为，大多数应用更适合使用更简单、强一致的 CRUD，再配合针对性的后端和前端优化。