Don’t Roll Your Own …

不要“自造轮子”……

By Susam Pal on 23 May 2026 作者：Susam Pal，2026年5月23日

This is going to be a rant about modern web design practices. But before I get to that, let me begin with a familiar principle from the world of cryptography. Among software developers, and especially among those who work on security-sensitive systems, there is a well-known maxim: Don’t roll your own crypto. 这是一篇关于现代网页设计实践的吐槽。但在进入正题之前，我想先从密码学界的一个著名原则谈起。在软件开发者中，尤其是那些从事安全敏感系统开发的人员中，有一句广为人知的格言：不要自造加密算法（Don’t roll your own crypto）。

This does not mean that nobody is allowed to write cryptographic code. Someone has to. It means that, for ordinary production software that protects sensitive data of users, we should not rely on a private, unreviewed implementation that has not been vetted by the wider software development community. We should use established, vetted software packages or tools wherever possible. 这并不是说没人可以编写加密代码，总得有人去写。它的意思是，对于保护用户敏感数据的普通生产环境软件，我们不应依赖未经审查的私有实现，也不应使用未经过更广泛软件开发社区验证的代码。我们应尽可能使用成熟、经过验证的软件包或工具。

Fortunately, it is now standard industry practice to avoid rolling your own crypto and instead use cryptographic algorithms and packages that have been peer reviewed and stood the test of time. It wasn’t so some twenty years ago. I have seen several flawed home-grown RC4 implementations early in my career, with issues like improper initialisation vectors, predictable keystreams and partial leakage of plaintext into ciphertext, putting sensitive data of users at risk. 幸运的是，避免“自造加密轮子”，转而使用经过同行评审且经受住时间考验的加密算法和软件包，如今已成为行业标准做法。但在二十年前并非如此。我职业生涯早期曾见过几个有缺陷的自研 RC4 实现，它们存在初始化向量不当、密钥流可预测以及明文部分泄露到密文中等问题，将用户的敏感数据置于风险之中。

But today, major e-commerce websites or banks typically do not use home-grown cryptography for its web services. In fact, in regulated domains such as payments, healthcare and personal data processing, doing so could violate requirements for strong cryptography, possibly leading to hefty financial penalties. 但如今，大型电子商务网站或银行通常不会在 Web 服务中使用自研的加密技术。事实上，在支付、医疗保健和个人数据处理等受监管领域，这样做可能会违反强加密要求，并可能导致巨额经济处罚。

Website design is obviously not cryptography. A broken scroll bar is not the same kind of failure as a broken encryption scheme. But I wish there were a similar maxim for website design as well. There are many aspects of websites where, I think, developers should not be rolling their own X, especially when X is something browsers already do well and something users depend on every day. Here I present a list of such X. 网页设计显然不是密码学。一个损坏的滚动条与一个损坏的加密方案并不是同一种性质的故障。但我希望网页设计也能有类似的格言。我认为，在网页的许多方面，开发者都不应该“自造轮子”，尤其是当这个功能浏览器已经做得很好，且用户每天都在依赖它的时候。以下是我列出的一些此类功能：

Don’t roll your own page scrolling. Don’t roll your own link navigation. Don’t roll your own text selection. Don’t roll your own context menu. Don’t roll your own copy and paste. Don’t roll your own password field. Don’t roll your own date picker. 不要自造页面滚动。不要自造链接导航。不要自造文本选择。不要自造右键菜单。不要自造复制粘贴。不要自造密码输入框。不要自造日期选择器。

Of course, there are valid scenarios where you may need to roll your own X. But here I want to focus on the cases where you should not roll your own X, and how doing so can lead to a worse user experience, at least in my experience. I am not saying that nobody should ever build anything themselves. As someone who does a lot of creative computing myself and develops fun tools from time to time, I am a big proponent of developing your own stuff. 当然，在某些合理的情况下，你可能确实需要自造这些功能。但我这里想重点讨论的是那些你不应该自造的情况，以及这样做如何导致更糟糕的用户体验——至少在我的经验中是这样。我并不是说没人应该自己构建任何东西。作为一个经常进行创意计算并时不时开发一些有趣工具的人，我非常支持开发自己的东西。

But when it comes to developing user interface features for serious websites that people need to use to get their work done, I wish the software development community were more conservative in deciding what fancy feature goes into a website and what is left out. Do keep in mind that I am no expert in user experience. Far from it. So none of what I am saying here should be taken as a recommendation. But I am a user of the Web, and as a user, I have found some modern web design patterns to be frustrating. This post is a lament from one user of the Web, not a design guide. 但当涉及到为人们需要用来完成工作的严肃网站开发用户界面功能时，我希望软件开发社区在决定哪些花哨的功能该加入网站、哪些该舍弃时能更保守一些。请记住，我不是用户体验方面的专家，远非如此。因此，我在这里所说的任何内容都不应被视为建议。但我是一名 Web 用户，作为用户，我发现一些现代网页设计模式令人沮丧。这篇文章是一位 Web 用户的感叹，而非设计指南。

Of all the things I mentioned above, the one that bothers me the most is custom scroll behaviour on websites. I am used to how page scrolling responds to my mouse, touchpad or keyboard input. When you override the default scrolling behaviour of the web browser with your own implementation, it ‘breaks’ the page for me. The page now moves too slowly or too quickly when I scroll. Keyboard scrolling may or may not work. You take something I am so familiar with that I don’t even think about it, and turn it into something unfamiliar that I now have to think about. 在上述所有事项中，最让我困扰的是网站上的自定义滚动行为。我已经习惯了页面滚动对鼠标、触摸板或键盘输入的响应方式。当你用自己的实现覆盖浏览器的默认滚动行为时，这对我来说就“破坏”了页面。页面滚动时要么太慢，要么太快。键盘滚动可能失效，也可能正常。你把我原本非常熟悉、甚至无需思考就能使用的东西，变成了一个我不熟悉、现在不得不去思考的东西。

Custom link navigation is another pet peeve of mine. Web browsers can already handle links very well. You could say that this is the whole reason web browsers even exist. Following links is their bread and butter. You shouldn’t have to mess with that behaviour at all. If you think you need to, reconsider what you are trying to achieve and whether it is really so important as to disrupt normal link navigation. 自定义链接导航是我的另一个痛点。Web 浏览器已经能很好地处理链接了。你可以说这就是 Web 浏览器存在的全部理由。点击链接是它们的基本功。你根本不应该去干扰这种行为。如果你认为有必要这样做，请重新考虑你想要实现的目标，以及它是否真的重要到需要破坏正常的链接导航。

The worst offender I have found here is GitHub. When you click on a link on GitHub, say, a file link or an issue link, it triggers a massive piece of functionality implemented in JavaScript that handles the link click for you. If you don’t believe me, visit your favourite project on GitHub using Firefox or Chrome, type F12 to open the browser’s developer tools, then go to the ‘Debugger’ or ‘Sources’ tab, find ‘Event Listener Breakpoints’ on the right sidebar, expand ‘Mouse’ and select ‘click’. Then click on a link on GitHub and see what happens. 我发现最糟糕的例子是 GitHub。当你点击 GitHub 上的链接（比如文件链接或 Issue 链接）时，它会触发一段用 JavaScript 实现的大型功能代码来为你处理点击事件。如果你不相信我，可以用 Firefox 或 Chrome 访问你喜欢的 GitHub 项目，按 F12 打开开发者工具，进入“调试器”（Debugger）或“源代码”（Sources）选项卡，在右侧边栏找到“事件监听断点”（Event Listener Breakpoints），展开“鼠标”（Mouse）并勾选“click”。然后点击 GitHub 上的一个链接，看看会发生什么。

I’m sure I am not the only one who has noticed that, on GitHub, a clicked link sometimes takes too long to load. Ironically, it is often faster to open the link in a new tab than to wait for GitHub’s JavaScript code to handle the navigation in the current tab. 我相信不止我一个人注意到，在 GitHub 上，点击链接有时加载时间过长。讽刺的是，在新标签页中打开链接，往往比等待 GitHub 的 JavaScript 代码在当前标签页中处理导航要快得多。

A custom password input field is another such hazard. Fortunately, custom password input fields have become rarer over the years. The password input field that comes with the web browser is generally well equipped to handle passwords. It can offer to save passwords, fill them in later and generate strong passwords for new accounts. It can also warn when a password is submitted over an insecure HTTP connection, work well with password managers and autofill, and cooperate with mobile keyboards and accessibility tools. If you replace the browser’s password field with your own fake version, you may break all of that. You may also end up using an ordinary text field and masking it yourself, in which case the password may be treated by the browser, the operating system or assistive tools as ordinary visible text rather than as a password, thereby exposing the password in ways you did not intend. 自定义密码输入框是另一个隐患。幸运的是，这些年来自定义密码输入框已经越来越少了。浏览器自带的密码输入框通常具备处理密码的完善功能。它可以提供保存密码、稍后自动填充以及为新账户生成强密码的功能。它还可以在通过不安全的 HTTP 连接提交密码时发出警告，与密码管理器和自动填充功能良好协作，并与移动端键盘和辅助工具配合使用。如果你用自己伪造的版本替换浏览器的密码框，你可能会破坏所有这些功能。你最终可能只是使用了一个普通的文本框并自己进行掩码处理，在这种情况下，浏览器、操作系统或辅助工具可能会将密码视为普通的可见文本，而不是密码，从而以你意想不到的方式泄露密码。

Custom date pickers are another common annoyance. I know that do 自定义日期选择器是另一个常见的烦恼。我知道 <input type="date"> 的确……