Decker：一个继承 HyperCard 与经典 Mac OS 遗产的平台
文章摘要
Decker 是一个用于创作和分享交互式文档的多媒体平台，支持声音、图像、超文本和脚本化行为，可以直接在浏览器里试用。它明确宣称自己建立在 HyperCard 的遗产和经典 Mac OS 的视觉美学之上，保留了 HyperCard 那种简单和易学，同时加入了大量或细微或明显的体验改进：深度撤销历史、滚轮和触摸屏支持、更现代的键盘导航、批量编辑操作。
Decker 的用途相当开放：做电子杂志（E-Zine）、整理笔记、做演示、造冒险游戏，或者仅仅是涂几笔 1-bit 像素画。它整体的「ditherpunk」（抖动朋克）美学被作者描述为温馨、略带怀旧，并提供了有趣而独特的创作约束。作为原型工具，Decker 鼓励拥抱一种草图式的、不完美的方式。完成的 deck 可以保存为独立的 .html 文档，在浏览器里自执行，可以放在任何能托管或嵌入网页的地方分享。Decker 同时原生运行于 macOS、Windows、BSD 和 Linux。
对于更复杂的项目，Decker 配备了一门名为 Lil 的新脚本语言，深受两者影响：Lua（一门常被嵌入工具和游戏引擎的命令式语言）和 Q（APL 家族中用于时序数据库的函数式语言）。作者称 Lil 容易上手，也足够常规，不会让有编程经验的用户感到别扭，但同时包含一些惊喜，比如隐式的标量-向量算术和内建的类 SQL 查询语言。几行 Lil 就能做很多事。
Decker 提供了一小组内建交互式控件用于构建界面，还有定义新控件的机制。自定义控件及其定义可以通过系统剪贴板复制粘贴，这意味着它们能在任何可以分享或存储文本的地方传播。用作者的话说，每个 deck 都是一套可重用零件的工具箱，可以被收割下来用到另一个项目上。
Decker 也对命令行友好：从源码构建时会附带 Lilt，一个独立的 Lil 解释器，能够「无头地」读取、写入、操作甚至执行 Decker 文档。Lilt 的依赖比 Decker 本身还少，因此可以编译成跨平台的 APE 可执行文件，用来写到处都能跑的 shell 脚本。作者甚至提到有一个跑在 POSIX AWK 上的 Lil 解释器。Deck 以面向行的文本格式存储，能与 Git、SVN 这类现有版本控制工具良好互操作。
最后一段带着明显的立场：Decker 不包含广告、遥测、游戏化、「垃圾生成器集成」（slop-generator integration，即 AI 集成）或其他任何侵犯用户隐私和自主性的东西。项目在 GitHub 上开源，采用宽松的 MIT 许可证；macOS 和 Windows 的二进制版本定期发布在 Itch.io 上，社区每年七月和十二月举办 Decker 主题的 Game Jam。站点上还列出了大量示例（导览、Sokoban、打砖块、CHIP-8 解释器、手柄输入演示）和社区库（绘图、统计、PDF 导出、Twine 的 .twee 格式读取、动画辅助、缓动函数、大整数、视觉小说模态框与精灵动画、网格寻路、Hershey 矢量字体、音效生成等）。
HN 评论精华
这条帖子拿到 381 分和 100 多条评论，讨论气氛相当温和，主要分为三条线：Decker 作者本人下场答疑、HyperCard 的怀旧与技术史考据、以及「今天还有没有这类工具的位置」的实用讨论。值得一提的是，Decker 的作者 RodgerTheGreat 在帖子里非常活跃地回复了多条质疑。
作者亲自下场
thataccount 说他前几天正在用 Decker，但发现文本字段的字号调整功能很有限，只能做标题却没法让它更大。RodgerTheGreat 解释说 Decker 的字体由固定尺寸的位图构成，附带的 fonts.deck 示例里有多种不同尺寸的额外字体和一个编辑器，另外最近还新增了处理矢量文本的 hershey 库。
面对最尖锐的一条批评——donohoe 说「我怀念 HyperCard，从怀旧层面爱这类项目，但如果你指望它在今天（2026）对真实项目有用，那就是彻底浪费时间」——作者的回复相当有力：「我每天都在用 Decker 写的个人应用。itch.io 上有超过 300 个用 Decker 做的游戏、杂志、视觉小说和玩具。上个月第一个完全用 Decker 做的游戏在 Steam 上发布了。我们既不活在过去，也没有浪费时间。」
janci 提出了一个技术性问题：看起来应用状态主要维护在控件里，让他想起 Delphi；有没有类似的、能像 UI 控件那样可视化创建和组合的数据结构表示概念？作者回答说 Decker 重度强调「具象化数据」（reified data）的概念，把信息表示为 deck 内的有形实体——你可以创建「装置」（contraptions）作为特定应用的专用数据容器/编辑器，也可以把复合数据表示为 deck 里的一系列卡片，或者把卡片当作通过事件通信的封装「对象」；紧急情况下还可以用字段的 .data 属性把任意数据编码为 JSON 超集。
jandrese 的长评论表达了对 Lil 取代 HyperTalk 的遗憾，并给出了一个 HyperTalk 的经典演示流程：打开空白脚本、拖个字段命名为 myname、拖个按钮打开它的脚本看到 on mouseUp / end mouseUp，在中间填两行 ask "What is your name?" 和 put it into card field myname，点按钮就弹出对话框，输入名字后名字出现在字段里。他强调这种直接性在现代开发环境中已经消失：按钮的脚本住在按钮内部，页面上的一切都可以有自己的脚本，页面本身有脚本，stack 本身也有脚本，背后还有一整套消息传递机制。「这是我见过的最直觉的编程环境。」他还指出最了不起的地方是这一切都在一个随操作系统附带的应用里：无需安装、无需先买产品，它就在那里等着被发现，一个无聊的孩子可能因此发现终身的热情。
RodgerTheGreat 逐条回应，给出了 Decker 版本的等价代码：
on click do
myname.text:alert["What is your name?" "string"]
end
他承认 Lil 比 HyperTalk 多一些「像编程语言」的标点，但简单例子依然简单，而且在他看来，拥有一等的集合类型（列表、字典、表格）和更丰富的 APL 式运算符，能让 Lil 在扩展到更复杂程序时表现好得多。他还提供了一个反面的个人经历：「作为一个孩子，我记得我在 HyperTalk 的『近似英语』结构上挣扎得非常厉害；它让脚本足够易读易懂，但在你要写新脚本时几乎提供不了任何帮助。」他还提到按钮控件提供的「Action…」对话框可以用 GUI 帮用户生成简单脚本，作为学习函数调用语法的脚手架。jandrese 回敬说：你的例子里有句点、冒号、方括号，还有一个别人可能预期是逗号的空格，对第一次编程的人会显得更吓人。
「限制激发想象力」
zeroq 贡献了本帖情感浓度最高的一段：他担心 HyperCard 已经太老，广大受众无法理解那是一种多么非凡的体验。「六七岁时我做了一套英文单词集合，带着我自己写的定义和发音，用的都是基础构件，跟在笔记本上写这些词一样容易和直觉。人们用同样的原语做出真正的游戏或者会计应用。最棒的是——在那个年代它看起来一点也不廉价。」他用了一个精彩的类比：这就是那种恐怖谷效应，让《辐射 1》里一个只有两屏、几个精灵跑来跑去的小村庄感觉庞大而充满人烟，而《辐射 3》有真实建筑和配音的完整 3D 世界却显得扁平、无魂、空洞。
giantfrog 接道：「辐射的类比太完美了。限制激发想象力。我想这也是为什么本质上无限制的 AI 模型产出的东西如此缺乏想象力。」temp0826 补充：「约束真的会孕育创造力。demoscene 大概是我最喜欢的例子。」
analog31 从另一个角度谈「不显廉价」：他更早，从大型机的文本屏幕和基于文本的微机开始——因为一切都是屏幕上的文本，一个孩子也能做出「看起来就像软件」的东西，哪怕内部实现远不及商业软件精巧。等到他用上 68k Mac 这样的图形计算机，这件事就变难了：能写终端窗口里跑的程序，但要让它们「看起来像软件」就得深潜进庞大类库的不可穿透的运作方式。「HyperCard 是极好的中间地带。它的控件看起来就和操作系统的基础 UI 控件一样，用户可以点按钮、编辑文本字段。就像软件一样。」他还提到 Visual Basic 也做到了，但 VB 得到了支持而 HyperCard 被砍掉了。
HyperCard 为什么死了：技术史考据
InsideOutSanta 提出了一个反复出现的批评：许多现代 HyperCard 再诠释都卡在了原作的黑白美学上，这限制了它们的受众广度。「即便在 HyperCard 还相关的年代，Apple 无法把色彩作为一等特性引入，正是有效杀死这个产品的原因。」（不过 jdeltia 直接回了一句：「Decker 有颜色！」）
由此展开了一段扎实的技术史。andrelaszlo 问：Myst 不是用 HyperCard 做的吗，他们怎么绕过限制的？pasquinelli 说 Myst 用的是修改版，更早的《Cosmic Osmo》用的是原版。Cyberdog 补充说他们用了第三方 XCMD 扩展来加入 HyperCard 原生不支持的功能，比如全彩支持。kalleboo 加了一层细节：在 HyperCard 的最终版本里，Apple 甚至捆绑了一个第三方彩色 XCMD 来假装 HyperCard 支持彩色，但功能非常受限（从磁盘插入 PICT 文件！改按钮颜色！用彩色绘图工具？那是什么？）。他后来还揭示了更完整的死因：Apple 从没在 HyperCard 2 里把颜色 hack 进去，因为他们对 HyperCard 3 的计划太宏大了——它将成为 QuickTime 的一部分，让 HyperCard stack 成为以 QuickTime 影片形式投递的多媒体应用，包括嵌入网页；但那正是 Apple 螺旋下坠的时期，项目被砍。WorldMaker 补充了游戏史细节：Cyan 在 Myst 之前的所有游戏都用 HyperCard（Cosmic Osmo 和 Spelunx）；Myst 在早期 Mac 版本上跑在 HyperCard 里，后来换成了 Broderbund 为了在 Windows 光盘、主机等平台发行 Myst 而建的跨平台运行时（ScummVM 称之为 Mohawk）；Riven 也主要在 HyperCard 里设计和原型，但从一开始就更直接地面向那个运行时。
jandrese 提出了另一个死因判断：「我认为更大的问题是 Apple 停止发布 HyperCard 开发环境、只发 Player，以及后来完全停止开发和支持。他们本来有个非常酷的东西，但因为不直接贡献利润，公司层面就把它做掉了。」
scelerat 给出了一个耐人寻味的时间线判断：「浏览器和 Web 开发直到大概 2010 年才追上 1994 年 HyperCard 的交互性和能力。真正的杀手级应用最终是网络本身，但对任何用过 HyperCard 建东西的人（人数很多）来说，等到这些组件和事件驱动开发的模式成为现代开发工具箱的一部分时，它们已经像是来自一个精致过往的回声了。」
「今天有没有这类工具的位置」
mbreese 提出了本帖最有实用价值的一条支线：今天还有没有这类界面的位置？他想到的是 HyperCard stack 这样的自包含应用，也包括 FileMaker 数据库甚至 Access 数据库——界面连着数据库，作为一个自包含应用。这些带脚本语言的工具支撑了大量小企业应用，都是由「可能有点技术但不懂完整编程语言」的用户开发的。「如果你是个小店，需要一个小数据库，你今天用什么？有默认选项吗？Notion？」
chrisweekly 答 SQLite，swiftcoder 立刻反驳：「SQLite 没有内建用户界面。FileMaker 这类东西的价值不在底层存储机制，而在于让你快速围绕它构建自定义应用的所见即所得界面构建能力。」
whartung 给出了本帖最好的一段说明为什么这个空缺是真实的：「虽然显示看起来简单（一个网格、几个控件），一个 Web UI 的 CRUD 应用哪怕在今天是例行公事，也并不简单。虽然我已经二十多年没碰过这两者，你可以在几分钟的拖放里创建表、得到一个可导航的界面和一个 CRUD 详情页。它就在那里，在你的机器上，没有任何认知负担，随时可用。再花十分钟，你就有一份可打印的报表从激光打印机里吐出来。」他还点出了一个常被忽视的细节：「开箱即用，这些屏幕看起来『还行』。你的一堆字段会漂亮地填满窗口。你不会面对一张 21 英寸 × 12 英寸的空白荒芜画布，姓名、地址、城市/州/邮编和两个按钮全挤在左上角。『天啊为什么字体这么小？』所以你不用掉进兔子洞去让你的简单表单达到基线的『能看』。」
mike_hearn 给出了一个 HN 读者可能不知道的答案：Oracle APEX 相当流行，「你在 HN 上从来听不到它，因为低代码工具的目标用户群和 HN 群体重叠不多，但它非常庞大」——在某份 IDC 调查中它是最受欢迎的低代码产品，200 万以上应用、50 万开发者。pjmlp 补充说 FileMaker 和 Access 仍在销售，微软在面向 Web 时更倾向推 PowerApps；另有人提到 Airtable、Tiddlywiki 和 4GL 系统这个历史类别。sixdimensional 认为这在 AI/LLM 时代是一片完全开放的创新领域。
j-pb 则给出了一个有趣的当代替代方案：「我发现我们在某种意义上把它拿回来了。如果你让 LLM 写一个 CLI 并让它自己用，那么它把『用户界面』隐藏到了足够程度，以至于你基本能在几天里造出任何应用/功能，而且感觉『专业』。AI 作为 UI，带着某种通用的可供性。」
其他值得一提的碎片
cure_42 连发两条说 Decker 看起来很适合 e-ink 设备（比如 Boox Note 系列），「在墨水屏上它比大多数现代界面好看多了」。mempko 提出了一个观察兼呼吁：「等等，你是说人们在 LLM 之前就 vibe 创造应用了？这太美了。我小时候爱 HyperCard。如果它加上网络，会比浏览器更优越！请各位有点乐子，别再因为别人 vibe coding 就贬低他们。让人们再享受一次乐趣吧。」jandrese 泼了盆冷水：能从远程站点加载 stack 页面会既惊人又是彻底的安全噩梦，HyperCard 的安全模型完全不适合那种活动——90 年代 HyperCard 病毒已经是问题，只是难以传播所以影响有限。
tangentstorm 说他为了教八岁女儿编程，已经开始做一套 Decker 教程（deck + 视频）。k310 回忆说他在一家火箭科学公司里用 HyperCard 写一次性的科研应用，通过 HyperBasic XFCN 出图，其中一个是给主管用的光学传感器权衡模拟器，图形能输出 EPS 让技术文档组直接导入报告；另一个是用内建字段做的表单，被他老板「偷走」用于生成编程项目的文档，输出是 Postscript 的 Unix man page 格式。「当你老板偷走文档工作时，那是个大胜利。」
felixding 贡献了本帖唯一的挑刺：标题应该是「classic Mac OS」而不是「classic macOS」。