Building Prosefly

Sun, 11 Oct 2026 00:00:00 GMT

Why build another one?

I had already built Typlog. Why start Prosefly too? I think static websites make more sense now, especially with AI. When content lives in Markdown and MDX files alongside the website’s code, AI can read and edit it directly, and work on articles and pages together.

How content is stored and how I write it are two separate things, though. I still want a friendly visual editor. Formatting and inserting images feel more comfortable there; I don’t want to edit source every time.

AI has also made it easier to build your own theme. You can change the website to suit your ideas and define its frontmatter fields along with it. For a book review, for example, you could add an author and a rating to the schema.

In Typlog, those fields are predefined by me and are not easy for users to change. Prosefly reads the frontmatter schema defined in the project’s text files and generates the editing interface from it. When making a new template, I don’t have to start by checking whether the platform supports the fields I want.

Development order

I spent a long time designing the visual editor before starting the complete platform. Most of my attention was on the editor: the files would be Markdown and MDX, but I wanted a visual writing experience. I wanted that part to be mostly ready first.

Once the editor was close to complete, I started working on Prosefly. Even then, I did not jump straight into the web app. I created a GitHub org, made several Astro themes and templates, and then started building the Prosefly platform.

Working on templates first gave me actual websites in which to organize content, define frontmatter, and see how the editor fit. By the time I started the platform, I already had content to edit and websites that used it.

A wrong turn

The platform runs on Cloudflare Workers and needs to keep data separate for each org. I initially chose Workers for Platforms. It lets a platform deploy and run users’ Worker code, but my main need at that point was to separate data between organizations.

The project became much more complicated. I had already spent a lot of time on the editor and made several templates, but building the platform kept getting harder. At one point, I considered giving up.

Later, I realized that Durable Objects could handle the data separation I needed. Each org’s data could live in its own Durable Object. It would still be one application, without deploying and managing separate Workers for that purpose. Switching to this approach made the platform much simpler, and I kept going.

开发 Prosefly

Sun, 11 Oct 2026 00:00:00 GMT

为什么又做一个

我已经做了 Typlog，为什么又要做 Prosefly？我觉得现在更适合做静态网站了。尤其是有了 AI 之后，内容保存成 Markdown、MDX 文件，和网站代码放在一起，AI 就可以直接读取、修改，也方便同时调整文章和页面。

不过，保存成文件和怎样写文章，是两回事。我还是想要一个友好的可视化编辑界面。调整格式、插入图片这些操作，用编辑器做会舒服一些，没有必要每次都去改源码。

有了 AI，自己做一个 theme 也容易多了。网站可以按自己的想法改，文章需要哪些 frontmatter 字段，也可以跟着网站一起定义。比如写书评时，想加作者和评分，就可以在 schema 里加上。

在 Typlog 里，这些字段都是我预先定义好的，用户不方便改。Prosefly 则直接读取项目中用文本定义的 frontmatter schema，再按它生成编辑界面。这样我做新模板时，就不用先考虑平台有没有提供对应的字段。

开发顺序

我先花了很久设计 visual editor。当时还没有开始做完整的平台，主要精力都放在编辑器上：最终保存的是 Markdown、MDX，写作时又希望有可视化的体验，我想先把这一部分做得差不多。

等编辑器接近完成，才开始做 Prosefly。不过，之后也没有马上写 web app。我先创建了 GitHub org，做了几个 Astro theme 和 template，然后才开始开发 Prosefly platform。

先做模板，有机会把内容组织和 frontmatter 的定义放进一个实际的网站里，看看编辑器怎样配合。到开始写平台时，已经有了可以编辑的内容，也有了使用这些内容的网站。

选型走了弯路

平台用的是 Cloudflare Workers，需要按 org 分开管理数据。我一开始选了 Workers for Platforms。它可以让平台部署和运行用户的 Worker 代码，但我当时主要想解决的是不同组织的数据分离。

结果把项目弄得特别复杂。编辑器已经花了很多时间，模板也做了几个，到了平台这一层，却越做越麻烦，一度打算放弃。

后来才发现，Durable Objects 就可以做我需要的数据分离。每个 org 的数据放在各自的 Durable Object 里，应用还是同一个应用，不需要为此去部署和管理不同的 Worker。换成这个方案后，平台简单了很多，我才继续做了下去。

lepture — Code, words, and everyday life.