我们在制作高效软件的过程中迷失方向了吗？—— 30 MB 的文档文件 vs 浏览器

阿波罗计算机DSKY用户界面单元（维基百科）

昨天，我爸爸告诉我他需要在他的笔记本电脑上安装 Microsoft Word 来处理他的 doc 文件。

他还想把他文档文件转移到工作电脑上，以便在办公室继续工作。我觉得一个网页应用可能适合他。

我向他展示了 Google 文档选项，因为他已经有一个 Google 账号，而且它更易于使用，是基于云的，并且会自动同步。

我在 Google Docs 中设置了他的文档文件，而且……当我在这个文档文件中输入任何内容时，需要几秒钟才能在屏幕上看到。这个文档文件大小约为 30 MB，包含一些图片和简单的表格，但主要是文本。不幸的是，Chrome 和/或 Google Docs 无法处理它。

他不想为 Microsoft Office 付费。所以我给他安装了 LibreOffice，并且我也在上面测试了他的文档文件。它的速度比闪电还快。

在这之后，我一直思考今天的软件标准。我们在性能方面的软件开发是否在倒退？最新的、酷炫的、现代的工具、框架和语言是否在效率方面让我们倒退？

看来硬件规格被提高了，以处理这类网页应用。如果我们只有纯原生应用的话，浏览器就变得没有必要了。比如，为什么手机需要配备8GB或16GB的内存呢？

网页需要原生渲染，而不是一些UI渲染引擎的封装。你不能在配置良好的笔记本电脑上用Google Docs打开一个约30MB的Word文件，因为浏览器需要更多的内存和CPU使用。

我觉得我们在开发优化、高效且高性能的应用程序方面迷失了方向。我们需要解决这个问题。即使在1966年，只有2KB内存的阿波罗计算机也能将人类送上月球，但在2024年，你却无法在浏览器中处理一个约30MB的文档文件。

我专注于 web，因为今天整个行业的人都在为未来集中精力于 PWA 应用程序。

API 的优化在网页和原生应用中也非常重要。因为 API 的性能会影响应用的整体性能，这里我要稍微自夸一下，我想谈谈我开发的一款用于监控 API 的产品，它可以帮助优化 API，网址是 https://onradar.io。Onradar（由 https://altlab.com 提供）提供了 API 的可用性监控和基于流的监控。你可以在流编辑器中创建可能的用户场景及其相关的 API，并让 Onradar 每天 24 小时进行测试。如果有任何问题，它会通知你。

感谢阅读！