In front of you are two personal websites, each used as a blog and to display basic contact info of the owner:

1. One is a complex CMS written in PHP that requires a web server, multiple workers, a Redis cache, and a SQL database. The site also has a big frontend component that loads as a Single Page Application and then performs navigation by requesting the content in JSON form, which then gets “rehydrated” client-side.
2. The other is a collection of static HTML files and one or two CSS files. No JavaScript anywhere.

If you didn’t know any better, you would expect almost all normal users to have [2] and professional engineers to have something like [1], but it’s actually the inverse: only few professional software engineers can “afford” to have the second option as their personal website, and almost all normal users are stuck with overcomplicated solutions.

Weird as it might be, it’s not a great mystery why that is: it’s easier to spin up a Wordpress blog than it is to figure out by yourself all the intermediate steps:

1. Buy a domain
2. Find a hosting platform
3. Configure DNS
4. Find an SSG (or handcraft everything yourself)
5. Learn how to setup a deployment pipeline

And so, while we software engineers enjoy free hosting & custom domain support with GitHub Pages / Cloudflare Pages / etc, normal users are stuck with a bunch of greedy clowns that make them pay for every little thing, all while wasting ungodly amounts of computational power to render what could have been a static website in 99% of cases.

Last week I spoke at SquiggleConf in Boston about my experience writing a language server for HTML. Most of the talk is tactical advice on what to do (or avoid) when implementing one, but I concluded the talk with a more high-level point, which I will now report here fully as conclusion to this blog post.

When I published SuperHTML, I discovered that it was the first ever language server for HTML that reported diagnostics to the user. I wrote a blog post about it, it got on the frontpage of Hacker News and nobody corrected me, so you know it’s true.

I originally found it a funny thing, but thinking about it more, it’s a bit sad that this is the case. Linters do exist, and people can get diagnostics in their editor, but that’s usually tooling tied to a specific frontend framework and not vanilla HTML, which leads to people opting to use frameworks even if they don’t really have a real need for all the complexity that those frameworks bring.

And that’s bad in my opinion. Not because of an abstract appreciation for simplicity, but because the web doesn’t belong just to software engineers. The more we make the web complex, the more we push normal users into the enclosures that we like to call social networks.

Don’t you find it infuriating when lawyers and accountants fail to clarify how their respective domains work, making them unavoidable intermediaries of systems that in theory you should be able to navigate by yourself?

Whenever we fail to make simple things easy in software engineering, and webdev especially, we are failing society in the exact same way.

This is not something that startups or big tech can solve for us, their economic incentives are just too misaligned, so I invite you all to help make the web more accessible, partially as a matter of taking pride in our craft, and partially because the web used to be more interesting when more of it was made by people different from us.

这是一篇关于个人博客的文章，作者 Loris Cro 讨论了一个看似矛盾的现象：为什么专业的软件工程师往往使用简单的静态 HTML 网站（如 Github Pages），而普通用户却依赖复杂的内容管理系统 CMS （如 WordPress）。

作者用两个例子进行了对比：一个是依赖 PHP、SQL 数据库、Redis 缓存和单页应用的大型 CMS 站点，另一个则是纯静态的 HTML 和 CSS 文件。虽然我们可能认为普通用户会选择简单的静态站，而专业开发者更倾向于复杂的方案，但实际情况却完全相反。

作者指出，这种现象并不奇怪，因为普通用户难以掌握配置静态网站的多个步骤，如购买域名、配置 DNS、选择静态站点生成器（SSG）等，反倒是复杂的 CMS 系统提供了一键式的解决方案，比如 WordPress。

而另一方面，许多软件工程师能够通过 GitHub Pages 等平台免费托管静态站点，避免了额外费用。然而，普通用户被迫为这些过度复杂的解决方案支付高昂的成本，并且这些系统消耗了大量不必要的计算资源，尽管 99% 的情况下，静态站点就足够了。

普通用户为达成目标总是追求更好更简洁的体验，而服务商迎合了他们的需求，为他们简化流程、优化体验、提供付费服务。用户在不自觉中就为昂贵且浪费的东西买单了，到头来竟是给自己上的枷锁。

在文章的后半部分，作者介绍了他在波士顿 SquiggleConf 会议上分享的一项成果 —— 他开发的 SuperHTML 语言服务器。这是首个为 HTML 提供诊断功能的语言服务器，它为用户提供编码问题报告。

然而令人遗憾的是，虽然 HTML 的原生简洁性应让更多人使用它，许多人还是依赖复杂的前端框架，即使他们并不真正需要这些框架带来的额外功能。

作者进一步反思了技术复杂化的趋势，他认为，网络的复杂性正在将普通用户推向封闭的社交网络，使他们无法自由构建自己的网站。

作者借此批评了软件工程师对复杂性的盲目追求，认为这类似于律师或会计行业故意设置的 “门槛”，让外行人难以涉足并依赖他们的专业服务。这种技术壁垒阻碍了普通用户参与互联网创作的机会。

最后，作者呼吁所有开发者不要仅仅为了技术创新而增加复杂性，而是应该简化工具和流程，让互联网重新变得对普通人更具可访问性。毕竟，网络不应只是软件工程师的领地，而是所有人都能自由创作和表达的平台。

原文的表述更激烈：“普通用户却被一群贪婪的小丑所困，这让他们为每一件小事付出代价，同时浪费大量的计算能力在 99% 的情况下呈现静态网站。”