展示HN：你能将文件转换推向浏览器的多远？
嗨，HN，
我一直在实验将文件转换尽可能多地推向浏览器的可行性。去年，我尝试将 LibreOffice 无头模式编译为 WASM。我能得到的最小构建大约是 150MB——仅仅为了将 DOCX 转换为 PDF，这个体积实在太大了。于是我转向了一种混合的方法。
如今，大约 90% 的转换是在客户端使用 WASM 进行的（FFmpeg、PDF/图像工具、电子表格等）。较重的边缘案例则回退到一个小型服务器管道（LibreOffice、Pandoc、Poppler）。
主要的挑战并不在于库本身，而在于：
- 浏览器的内存限制
- 处理大文件时不冻结用户界面
- 仅在需要时懒加载大约 30MB 的 WASM
- Safari 与 Chromium 行为差异
FFmpeg.wasm 的运行速度大约是原生速度的 10% 到 20%。对于小型和中型文件来说是可以接受的，但对于大型媒体文件就不太合适了。我还尝试在浏览器中使用多线程的 FFmpeg，但还没有找到稳定的设置。
我很好奇其他人如何看待客户端处理与完全服务器端管道之间的权衡。
→ anythingconverter.com
查看原文
Hi HN,<p>I’ve been experimenting with how much file conversion can realistically be pushed into the browser.
Last year I tried compiling LibreOffice headless to WASM. The smallest build I could get was ~150MB — far too large just to convert a DOCX to PDF. That’s when I shifted to a hybrid approach.
Today ~90% of conversions run client-side using WASM (FFmpeg, PDF/image tooling, spreadsheets, etc.). The heavier edge cases fall back to a small server pipeline (LibreOffice, Pandoc, Poppler).<p>The main challenges weren’t the libraries themselves, but:
browser memory ceilings
handling large files without freezing the UI
lazy-loading ~30MB of WASM only when needed
Safari vs. Chromium behavior differences<p>FFmpeg.wasm runs at roughly 10–20% of native speed. Acceptable for small/medium files, less so for large media.
I also experimented with multithreaded FFmpeg in the browser, but haven’t found a stable setup yet.
Curious how others think about the tradeoff between client-side processing vs. fully server-side pipelines.<p>→ anythingconverter.com