一句话总结

我要重启我的博客写作课了。

亮点

• 我正在重启 2020 年开设的博客写作课。
• htmx 挺不错的，但还没完全达到我的预期。
• 我正在为之前的生酮网站 Is It Keto 寻找买家。

重启《登上 Hacker News 首页》

2020 年，我做了一门关于博客写作的视频课，叫作“Hit the Front Page of Hacker News”。我对课程内容很满意，也收到了学员的积极反馈，但总觉得没有给它应有的投入。

发布课程时，TinyPilot 正处在快速增长期，我根本没时间去推广课程或迭代内容。

在上一篇博文中，我向读者做了一项调查，询问他们接下来希望我做什么。在表示想看我讲课的人当中，结果如下：

这份数据可以有不同的解读，但我的结论是，大家尤其希望我来讲写作技巧。让我意外的是，“刻意练习”也排在了前列，虽然热情稍弱一些。

考虑到我已有的课程已经基本完成，而它在这次调查中排在第二或第三（取决于怎么算），我决定把原来的材料整理一下，重新发布一个 2024 版。

招募内测学员

Rob Fitzpatrick 的书Write Useful Books对我做教育产品的方式影响很大。他认为，在出书或发布视频课程之前，一定要先以直播授课的形式教一遍，这样才能根据真实学员的反馈来迭代。

我和妻子也即将在 8 月底迎来我们的第一个孩子，到时候我打算消失几个月专心陪伴家人。考虑开课时，距离预产期大概还有 10 周，而课程本身就要上 6 周，所以时间非常紧张。

我写了一段课程简介，给博客订阅者发了邮件，请感兴趣的人填写一份简短的申请表。有人提交申请后，我会根据他们填写的内容做个性化回复，并发送付款链接来锁定名额。

结果如下：

• 1,944 名订阅者收到了关于课程的邮件。
• 11 人填写了申请表表达意向。
• 7 人购买了课程。
  • 在填表后未报名的 4 人中，有 3 人是因为时间冲突。

选择视频平台

让我意外的是，视频通话领域几乎没有能真正替代 Zoom 的选择。自从 Zoom 被曝出在安全性上撒谎之后，我就一直尽量避开它，但在这个领域，它似乎别无他选。

过去几年工作中我一直在使用 Jitsi Meet，总体体验还不错，但在参加 Zoom 会议时，我能明显感觉到 Zoom 的质量更好。我本想找 Jitsi Meet 的付费版，但它所有的付费方案都标着“联系我们”，这通常意味着每月至少要 1000 美元。

所以，Jitsi 能用，就是有点笨重。它不支持录制，所以我的变通办法是：

1. 在笔记本电脑上主持课程视频通话。
2. 在台式机上加入该通话。
3. 在台式机上用常规录屏软件录制通话。
4. 把视频上传到PicoShare。
5. 把 PicoShare 链接通过邮件发给学员。

这比我想要的要复杂一些，不过也有个好处：即使演示文稿占满了笔记本的整个屏幕，我依然可以在台式机的显示器上看到所有人的脸。

如果你知道比 Jitsi Meet 更好的替代方案，请告诉我。

要不要淡化 Hacker News？

报名课程的学员中，约有一半表示他们对 Hacker News 本身并不是特别感兴趣。他们只是喜欢我的写作，想更多了解我的创作过程，所以即便课程聚焦于 Hacker News，他们也还是报名了。

回头看调查数据，大家对广义写作的兴趣似乎比对博客写作更大。而且没有人专门点名要学 Hacker News。

所以我在考虑，是否应该把重心从 Hacker News 转向更通用的内容。

我担心一旦偏离 Hacker News，就会失去自己的优势。教博客或写作的人有成千上万，我在那个大池子里很难脱颖而出。但如果专门教 Hacker News，我就是这个细分领域里最好的老师，因为根本没别人在做这件事。

另一个问题是，我在博客上取得的成绩大多都与 Hacker News 有关。在个人博主中，我在 Hacker News 上的表现算是相当突出的。如果改教更通用的写作课，我的资历就没那么亮眼了——我的博客不怎么赚钱，也没有庞大的订阅量可以炫耀。

与此同时，我觉得买我课程的人大多是先认识我这个人，然后才发现我的课程的。他们并不是在搜索“世界上最懂 Hacker News 的专家”时找到我的。

也许结论是，我不必太担心要和大量竞争者比拼，因为无论如何，学员找到我的路径很可能都是通过我本人或口口相传。

这一版课程按原本聚焦 Hacker News 的形式已经完成了 95%，所以我打算先按这个版本发布。结束之后，再把材料改编成更通用的课程。

学习 htmx

过去两年里，htmx 越来越频繁地出现在我的视野中。我的朋友Cory Zue 就在使用 htmx，这也引起了我的兴趣。

很长一段时间里，最大的障碍是我根本没明白 htmx 的意义何在。

htmx 官网首页的第一句话就是：“为什么只有 <a> 和 <form> 才能发起 HTTP 请求？”我看到这句时的反应是：“能让任意 HTML 元素发送任意请求当然好，但 JavaScript 本来就能让任意 HTML 元素发送任意请求。难道就为省几行 JavaScript，就要引入一整套新方法论吗？”

真正让我理解 htmx 的是那本Hypermedia Systems。这本书由 htmx 的作者撰写，解释了 htmx 背后的动机，并详细介绍了多个使用场景。

如果让我向四年前的自己安利 htmx，我会这么说。

给过去的自己的 htmx 安利词

还记得你刚开始学做网站时，是怎么写 HTML 的吗？

<form action="/users" method="POST">
  <input name="first-name" placeholder="First name" />
  <input name="last-name" placeholder="Last name" />
  <input type="submit" value="Add user" />
</form>

今天你不会再这么写了，因为你不想让用户提交表单时整个页面都重新加载。整页刷新又慢又让人分心，尤其当你只是想显示一句“用户添加成功”的时候。而且如果服务器拒绝了输入，你也不想把用户已填的内容全清空掉。

所以，你会转而用 JavaScript，写成这样：

document.addEventListener("DOMContentLoaded", () => {
  document.querySelector("form").addEventListener("submit", (evt) => {
    evt.preventDefault(); // Block default submit.
    fetch(`/users`, {
      method: "POST",
      credentials: "include",
      headers: {
        Accept: "application/json",
      },
      body: JSON.stringify({
        firstName: document.querySelector("[name='first-name']"),
        lastName: document.querySelector("[name='last-name']"),
      }),
    })
      .then((response) => {
        if (response.ok) {
          return response.json();
        }
        // TODO: Handle errors too.
      })
      .then((result) => {
        // TODO: Handle success.
      });
  });
});

JavaScript 代码不算多，但每次要用到表单就得重写一遍。你可以把重复代码抽出来复用，但那样又会把界面逻辑分散到好几个文件里。每次让前端与服务器交互，都得多一道摩擦。

或者你会转向 React 或 Vue 这样的重型框架，结果就是你的代码和最终在浏览器中呈现的内容之间隔了无数层 JavaScript 抽象。

htmx 承诺让你回到刚学网页制作时的那种简单。与其先写 HTML 再把所有逻辑丢给 React 或手写事件处理，不如把 htmx 集成进来，然后把表单写成这样：

<form hx-post="/users" hx-target="this">
  <input name="first-name" placeholder="First name" />
  <input name="last-name" placeholder="Last name" />
  <input type="submit" value="Add user" />
</form>

然后 htmx 会让一切直接生效，无需你再写任何自定义 JavaScript。

我目前使用 htmx 的体验

为了试水 htmx，我一直在用 htmx 重写ScreenJournal 的部分功能。ScreenJournal 是我的开源影评应用，有点像电影版的 Goodreads。或者说，它是一个开源、界面有点丑的 Letterboxd。

一个典型的重写例子是用 htmx 重构通知偏好设置页面。我有一个页面，让用户可以设置希望收到哪些邮件：

通知页面原本需要大量自定义 JavaScript 来实现以下功能：

• 通过 fetch 提交表单内容，而不是刷新页面。
• 在请求进行中禁用表单输入。
• 在请求进行中显示加载动画。
• 如果请求失败，显示错误信息。

以下是从原生 JavaScript 迁移到 htmx 的对比：

• 重构前（113 行）
• 重构后（85 行，减少了 25%）

总体代码行数变少了，尤其是 JavaScript 少了很多。逻辑从前端移到了后端，而我更偏爱后端代码，因为后端代码比 UI 代码更容易测试。

以下是我目前使用 htmx 的一些体会：

htmx 增加了一层抽象，但很直观

• 用 Vue 和 Angular 时，我完全搞不懂它们是怎么把我的代码变成网页应用的。
• 而 htmx 的行为足够直观，看过它的运作方式后，我觉得自己大概也能重新实现一个 htmx。

htmx 的错误处理不太尽如人意

• htmx 的模型假设你向服务器发送请求，然后把服务器的响应放到页面上的某一个元素里。
• 问题在于，成功时我想替换整个 HTML 表单，但出错时，我希望保持表单不动，只在表单下方显示错误信息。
• htmx 给出的答案是让服务器重新渲染包含用户所有输入的 HTML 表单，但我不喜欢这种做法——它把原本已经存在的内容完全重渲染了一遍，还扩大了 XSS 漏洞的攻击面。
• 我可以通过自己写事件处理来绕过这个问题，但那样就有点像是在跟框架对着干了。

htmx 削弱了内容安全策略（CSP）

• 我喜欢把CSP当作防范跨站脚本（XSS）的最后一道防线。
• htmx 大体上与 CSP 兼容，但由于 htmx 功能太强，攻击者一旦能够写入自定义 HTML，就等同于能够写入任意 JavaScript。
• 例如
  • <form action=/delete-account" method="post" onload="this.submit()">
    • CSP 会阻止这段代码执行。
  • <form hx-post="/delete-account" hx-trigger="load">
    • CSP 却会允许这段等效代码执行。
• 你仍然可以用 htmx 写出安全的应用，但它确实让 CSP 无法再作为抵御 XSS 的可靠底线。

出售 Is It Keto

我这周注意到，Amazon 在某个时候改了联盟链接的机制，导致 Is It Keto 上 90% 的联盟链接都失效了。这个网站仍能通过 Google AdSense 带来收入，但我已经没有时间去维护它了。

我正在寻找愿意接手这个网站的人，如果是来自独立开发者或有志创业者的靠谱报价，我愿意低于市场价出售。

总结

完成了什么？

• 开始以小班形式讲授博客写作课。
• 通过把 ScreenJournal 的大量功能迁移到 htmx 来学习 htmx。
• 录制了课程的第一节加餐内容。

经验教训

• 我对课程中 Hacker News 这个切入点的依赖，并没有我原先想的那么大。
  • 如果有人要上我的课，很可能是因为喜欢我的写作本身，而不是因为我的文章在 Hacker News 上表现有多好，所以我应该多想想这类学员到底是什么样的人。

下月目标

• 录制四节课的可发布版本。
• 开始销售新版课程。

求助

视频通话平台

如果你对符合以下条件的视频通话平台有推荐，请告诉我：

• 必须：支持最多 10 人、时长 90 分钟的通话。
• 必须：参与者无需创建新账号或安装软件即可加入通话。
• 必须：费用不超过每月 80 美元。
• 加分项：支持录制视频通话。

课程平台的使用经验

如果你作为讲师或学员使用过 Maven 或 Udacity 这类课程平台，欢迎分享你的经验。