旅行者在机场打开汇率页面时，最常问的不是"今天的市场走势如何"，而是"这10万越南盾到底值多少韩元"。SudangHelp的开发者最近分享了一个反直觉的发现：用户要的不是金融仪表盘，而是一个能在断网时依然能用的数字答案。
这个项目的核心矛盾很有意思。现代前端开发默认网络畅通，框架、构建工具、实时数据流都是为这个前提设计的。但旅行场景恰好相反——机场Wi-Fi不稳定、国际漫游未开通、本地SIM卡还没买到。用户需要的是一个"先能打开，再谈功能"的页面。
开发者最终选择了最朴素的技术栈：纯HTML、CSS和原生JavaScript。没有React，没有构建流程，没有依赖管理。这个决定的直接好处是运行时极小，静态文件极易缓存。对于一个只需要处理五个临时状态（源货币、目标货币、输入金额、最新汇率、URL预设国家）的工具来说，框架带来的复杂度远大于收益。
核心的汇率换算代码被刻意写得很"无聊"：先检查汇率表中是否存在两种货币，然后用标准公式计算。开发者解释这种设计哲学：计算器的价值不在于算法多精巧，而在于极端情况下的行为是否可预期。当网络请求失败时，页面不会崩溃，而是静默降级到预设的默认汇率，并显示数据更新时间。
真正的技术挑战在离线场景。页面通过Service Worker缓存自身文件，同时把汇率数据存入IndexedDB。每次成功获取新汇率后，数据会被更新到本地存储。当用户再次打开页面时，即使完全断网，也能立即看到上次缓存的汇率——虽然可能不是最新数字，但足够完成"这顿饭大概多少钱"的即时判断。
URL设计也服务于这个场景。/vietnam/、/japan/、/thailand/等不同路径对应不同国家的默认货币对，但背后都是同一个静态HTML文件。这种路由方式让离线缓存可以针对特定国家的常用货币对做优先级排序，减少首次加载时的数据量。
这个案例提供了一个值得思考的技术选型视角。不是"原生JavaScript比框架好"这种非黑即白的结论，而是对工具复杂度的诚实评估：当产品的核心用户价值是"可靠地给出答案"时，任何增加故障点的技术选择都需要被质疑。一个能在飞机上打开的汇率页面，可能比一个在5G环境下流畅运行的金融App更符合旅行者的真实需求。
热门跟贴