Brolly 推出一个由表格和 ASCII 图表构建的天气网站
York 开发者 Jacob 在 Met Office 的改版减少了他一次性能够浏览的信息量之后,建立了一个移动优先的网站。
By Ryan Merket · Published
Primary source: Brolly
Why it matters
Brolly shows how a solo developer can use AI to ship a differentiated consumer utility while keeping the product's defining interface decisions human-designed.

Jacob,一位来自 York 的开发者,只以名义发布作品,他于7月25日发布了 Brolly,这是一个面向更愿意扫描表格而不是滑动卡片的人的天气网站。在一篇发布帖中,他表示英国 Met Office 的重新设计增加了空白、滚动和动画,使他无法获得想要的一目了然的预报。
Brolly 将七天预报转换为单列的移动宽度文本。它的 York 预报 以当前温度、风速、紫外线和空气质量开头,然后依次呈现每日状况、逐小时降水、花粉和历史比较。由井号和短横线构成的条形图取代了主流天气应用中的图表、图标和地图。
Jacob 表示他“主要是为自己做这个站点”。这一限制使 Brolly 比许多面向消费者的天气界面拥有更清晰的产品论点:在一次向下滚动内放置最大有用信息,保留比较小时和日的能力,并使每个视图都可以被加入书签。
作为文档设计的预报
Brolly 不同寻常之处在于它把预报当作文档而不是仪表盘来处理。七天表格将温度、平均风速、阵风和降水保持在固定列中。选择某一天会改变下面的逐小时部分,而不会将用户带入单独的屏幕。Brolly 还保留了前一天的天气,回答了“今天实际上比昨天更热、更冷或更湿吗?”这一常见问题。
Jacob 从 Plain Text Sports 获得了美学灵感,该项目以类似的简约界面压缩实时比分和赛程。根据 Brolly 的技术与设计说明,他把大量手工设计工作放在基于字符的可视化上。他偏好的例子是花粉热力图,它用标点显示逐小时强度,并用星号标记每日峰值。
Brolly 在 URL 中存储已选位置、日期和展开的部分。因此,用户可以将精确的预报视图发送给其他人,而不是通用的城市登陆页。该设计避免了交互式网页产品中一种越来越常见的弱点:当页面被分享或重新打开时,应用状态消失。
Met Office 已经承认促使 Jacob 发起该项目的权衡。其刷新应用的常见问题表示,新设计在一个屏幕上显示的信息更少,因为之前的布局在小设备上可能感觉杂乱。该机构表示已使布局更紧凑,并在探索减少不必要滚动的方法。Brolly 则做出相反的界面押注:当信息保持一致结构时,一些用户会接受更密集的屏幕。
在小型网络栈上的纯文本风格
Brolly 的界面看起来像终端输出,尽管它仍然是一个常规的网络应用。Jacob 用 Go 编写,搭配 HTML、JavaScript 和 CSS,使用 PocketBase 处理服务器端路由,并用其 SQLite 数据库存储聚合统计和预报缓存。轻量的 JavaScript 在用户在日期间切换时重新加载服务器渲染的部分。
天气和位置信息来自 Open-Meteo,其服务汇集了 30 多个天气模型。Brolly 将位置预报缓存五分钟以减少对上游 API 的调用。Jacob 表示完整服务作为一个容器运行在伦敦的 512MB DigitalOcean 实例上。
该实现也反映了使用当前 AI 编码工具构建的单人副业项目的经济学。Jacob 表示他手工定义了 Brolly 的架构、结构和界面,同时使用 AI 实现了大量部分。“没有它我没有时间构建这个站点,”他写道,并补充说他保留了精选的可视化和设计问题自己处理。
这种分工对成品很重要。Brolly 的价值在于信息层次和小的交互决策,而不是检索和渲染预报所需代码的数量。AI 减轻了实现负担,而 Jacob 保留了区分该站点的产品选择。
早期流量检验了极简基础设施
Brolly 的公开统计页面 显示,截至7月25日晚些时候,页面浏览量为 37,187,预报查看量为 24,064,估计独立访客为 12,678。以上为 Brolly 自行聚合的数据,该站并未披露其如何计算独立访客,除称其为估计值。检查时,预报和空气质量缓存命中率均在 90% 以上。
这一关注突增也暴露了小型部署的局限。一些早期用户报告了数秒的加载时间,促使 Jacob 检查缓存和页面渲染路径。另一位用户将部分延迟追溯到 Brolly 的自定义字体,这对一个以速度和视觉克制为核心承诺的产品来说是一个尴尬的依赖。
用户也对“纯文本(plain text)”一词提出了质疑。Brolly 发送的是样式化为纯文本外观的 HTML;使用命令行客户端请求预报仍然会返回标记。Jacob 表示他会考虑真正的纯文本模式。
这一区别将 Brolly 与已建立的面向控制台的天气服务 wttr.in 区分开来。wttr.in 支持终端文本、浏览器 HTML、PNG、JSON 和 Prometheus 输出,并提供可直接从 shell 查询的人类可读位置路径。Brolly 提供的是更窄的浏览器体验,具有更强的移动导航、前一天比较以及针对花粉、紫外线和空气质量的详细字符化视图。
早期对 curl 支持的请求指向了 Brolly 最明确的扩展路径。一个真实的 text/plain 响应会将相同的紧凑预报变成开发者可以放入终端、脚本和状态栏的内容。它也将迫使 Jacob 保持产品最与众不同的限制:当移除所有装饰元素时,预报仍然可读,这正是 Brolly 能够工作的原因。