浏览器打开30万行Excel只需300ms？拆解office-engine的浏览器办公野心

原创

alex 1小时前阅读数 2 #头条

浏览器打开30万行Excel只需300ms？拆解office-engine的浏览器办公野心

多源交叉验证：从HN社区视角看项目前景与挑战

一个宣称“300ms打开30万行Excel”的项目，在Hacker News上只拿到6个Points和1条评论，这条评论还只有短短一句“interesting!”。这个反差本身就值得琢磨一下。来源：HN原文来源：HN评论

我查了下这个叫office-engine的仓库。README开头写得挺有野心：“View & edit DOCX, XLSX, PPTX in the browser. Progressive loading, formulas, real-time collab, saves to original format.” 这些功能单拎出来任何一项都够做个产品了，何况是打包在一起。仓库里也确实有e2e测试、playground、示例文件，包括一个300k行的sheet和一个305页的deck。来源：README

但技术社区的反应冷得有点异常。6个Points在HN上基本属于“没人看”的档位，那条唯一的评论“interesting!”甚至没有展开任何技术层面的讨论。要么是读者觉得这个性能声明太夸张，不值得深究，要么是项目本身缺乏足够的公开演示来支撑这个数字。我不确定具体是哪种，但两种可能都指向同一个结论：目前这个300ms的成绩还停留在自说自话的阶段。来源：HN评论

更值得留意的是README里那句“Loads progressively like Google Docs”。这个类比选得挺巧妙，Google Docs确实是渐进加载的标杆，但它是服务端渲染方案，文档数据在服务器上解析好，浏览器只负责展示。office-engine走的是纯前端路线，依赖Web Worker和IndexedDB在客户端做渐进加载。这两者的底层逻辑完全不同，把Google Docs当作体验基准可以，当作技术参照就不太合适了。来源：README

量化地看，19个commits的仓库加上1条HN评论，说明项目还停留在早期原型阶段。一个技术demo和一个生产可用的编辑器之间，隔着公式计算、协作冲突处理、格式保存这些硬骨头。300ms的打开时间如果属实，最大的卖点是“no server”——零服务器成本，这确实是个实实在在的优势，尤其对中小型应用来说。但当前这个状态，我更愿意把它看作一个性能验证，而不是一个可以交到用户手上的工具。来源：仓库状态来源：HN原文

所以回到那个反差：HN社区的反应冷淡，未必是项目不行，更可能是大家还没看到值得投入注意力的证据。300ms打开30万行XLSX是个很抓眼球的数字，但数字背后如果缺少可复现的演示、可验证的测试和真实场景的反馈，它就只是个数字。项目方需要做的，是把demo做得更硬核，把性能基准做得更透明，让质疑的人自己去跑一遍。到那时候，HN的评论可能就不止一条了。这个项目目前的状态，我判断还是一个值得跟踪的早期原型，距离“浏览器里的Office”这个目标，还有相当一段路要走。来源：HN原文来源：HN评论

原文：

Show HN: Open a 300k-row XLSX in the browser in ~300ms, no server · 来源：Hacker News

参考来源：