If you want to create a button from scratch, you must first create the universe
239 points
• 1 day ago
• Article
Link
文章有力地论证了开发者应优先使用原生 HTML 元素，而不是从头造自定义组件。以一个简单的 button 为例，作者展示了要让一个组件真正可用且无障碍，实际上需要满足一系列出乎意料的复杂要求。原生按钮天然处理键盘交互、屏幕阅读器角色、焦点管理和表单集成，而把这些功能在自定义元素上重现则必须逐一精心实现并反复测试。
作者详细说明了复现基本按钮行为所需的大量工作：为组件设置正确的无障碍角色、提供能涵盖图标按钮等细微场景的可访问标签、管理焦点状态、并支持多种指点设备。每一步都会增加复杂性，例如必须为鼠标、触摸和触控笔等事件分别添加监听器，这些细节常被忽视但对一致的用户体验至关重要。
除了交互之外，文章还强调了表单集成的艰巨性。原生按钮在表单上下文中会自动处理验证、提交和状态管理；要在自定义元素中复刻这些功能，就要维护一张由属性与特性构成的网络、处理表单验证 API，并确保元素与 shadow DOM 之间的同步无误——这往往意味着要写上数百行代码才能实现浏览器本来就提供的功能。
在技术分解的结尾，作者将手工实现这些功能形容为一项既容易出错又难以维护的"西西弗斯式"任务。原生 HTML 几乎零成本的实现与为达成部分功能所需的近 500 行复杂 JavaScript 之间的差距，给出了明确的警示：重新发明轮子不仅低效，而且有损可访问性和性能。
总之，文章强烈呼吁采用语义化 HTML，尽可能依赖浏览器内置能力。它回应了诸如自定义样式或框架兼容性等常见反驳，指出现代 CSS 与不断演进的 Web 标准越来越便于在不放弃原生可访问性优势的前提下定制原生元素。依托平台能力可以让组件更健壮、便于维护且更具包容性，避免不必要的技术债务。
The article presents a compelling case for why developers should prioritize native HTML elements over creating custom components from scratch. Using the example of a simple button, the author illustrates the surprisingly complex array of requirements necessary to make a component truly functional and accessible. Native buttons inherently handle keyboard interaction, screen reader roles, focus management, and form integration, all of which must be painstakingly re-implemented and tested when building a custom element from the ground up.
The author walks the reader through the immense technical effort required to replicate basic button behavior. This process involves ensuring the component has the correct accessibility role, creating accessible labels that handle nuances like icon-based buttons, managing focus states, and implementing support for various pointing devices. Each of these steps introduces layers of complexity, such as adding listeners for mouse, touch, and stylus events, which are often overlooked but are essential for a consistent user experience.
Beyond simple interaction, the article highlights the heavy lifting required for form integration. A native button automatically handles validation, submission, and state management within a form context. To recreate these features in a custom element, one must manage a web of attributes and properties, handle form validation APIs, and ensure proper synchronization between the element and the shadow DOM. This results in hundreds of lines of code to achieve what the browser already provides for free.
By the end of the technical breakdown, the author emphasizes that hand-coding these features is a Sisyphean task, prone to errors and difficult to maintain. The discrepancy between the zero-effort native HTML implementation and the nearly 500 lines of complex JavaScript required to reach partial functionality serves as a stark warning. The core takeaway is that reinventing the wheel is not only inefficient but detrimental to accessibility and performance.
Ultimately, the article serves as a strong advocate for semantic HTML, urging developers to rely on the browser's built-in capabilities whenever possible. It addresses common counter-arguments—such as the need for custom styling or framework compatibility—by noting that modern CSS and evolving web standards make it increasingly easy to customize native elements without abandoning their inherent accessibility benefits. Relying on the platform ensures that components are robust, maintainable, and inherently inclusive, sparing developers from unnecessary technical debt.
124 comments • Comments Link
• 不断重复实现像 Buttons 这样基础的 UI 组件，暴露出 Web 作为"文档中心"的本质与现代企业把 Web 当作"应用中心"使用之间的错位——后者往往需要原生元素难以提供的自定义行为。
• Apple 对操作系统美学的严格把控，加之原生 HTML/CSS Widgets 进展缓慢，迫使开发者转向高度定制的设计系统，而这些系统常为保持统一的品牌体验而牺牲了可访问性和一致性。
• 虽然像 Flash 这样的遗留技术常被视为性能低下，但在熟练的内存管理下，它们在当时表现出色；它们的衰落留下了空白，使得如今以 JavaScript 为主的重量级框架难以高效弥补。
• Safari 拒绝在内置标签上支持自定义元素扩展，阻断了向更简洁、更语义化的 Web Components 演进的路径，迫使开发者去构建臃肿且易出错的替代品，而不是利用已有的原生行为。
• 可访问性仍然是个争议性话题：一派将现有合规标准视为针对掠夺性诉讼的"敲诈工具"，另一派则认为 AI 驱动的工具很快会通过弥合非辅助代码与用户需求之间的差距，使人工合规变得过时。
• LLMs 越来越多地被用来弥补糟糕代码中的可访问性缺口，但过度依赖 AI 可能会固化不良模式，并掩盖对稳健、原生架构基础需求的忽视。
• "原生与自定义"之争因跨浏览器行为不一致而复杂化：即使是基础的原生组件在不同平台上表现各异，也会促使开发者构建自己的抽象层以确保体验可预测。
• 依赖第三方组件库通常比从零开始更经济，但这会带来依赖臃肿的问题，并可能让开发者丧失对诸如表单提交和 Pointer Events 等基础浏览器交互实际工作方式的理解。
• 对"AI 辅助可访问性"能否真正解决结构性问题存在显著怀疑：现代界面不仅要读取屏幕文本，还需要复杂的、有状态的交互，而当前的 LLM 代理可能难以可靠地复制这些交互。
• 目前的 Web 开发可说陷入停滞：对高保真定制设计的渴望与对高性能、标准兼容应用的需求相互冲突，导致大量开发资源被浪费。
总体而言，这场讨论反映出对当下 Web 状态的深层挫败感：标准 HTML Widgets 的固有限制推动着开发者走向复杂的自定义解决方案，而这些方案往往可访问性更差且性能更低。在理想上应更多利用原生浏览器功能，但现实是为了在不同平台上保持一致的品牌化界面，开发者不得不做出折中。有人把 AI 视为解决可访问性和简化实现的灵丹妙药，另一些人则怀疑过度依赖大型框架和"自造"UI 组件反而暴露了整个行业的低效率。归根结底，Web 仍在从文档交付媒介向应用平台转型，这一进程正被浏览器标准的不一致以及对 UI 未来方向缺乏共识所阻碍。 • The constant re-implementation of basic UI components like buttons reveals a misalignment between the "document-centric" nature of the web and the "application-centric" requirements of modern businesses, which often demand custom behaviors native elements cannot easily provide.
• Apple's rigid enforcement of OS aesthetics, combined with the lack of progress on native HTML/CSS widgets, forces developers toward bespoke design systems that frequently neglect accessibility and consistency in favor of maintaining a uniform brand experience.
• While legacy technologies like Flash are often dismissed as poor-performing, they were surprisingly capable for their time when developed with memory management expertise, and their decline left a void that current JavaScript-heavy frameworks still struggle to fill efficiently.
• Safari's refusal to support custom element extensions on built-in tags hinders the path to cleaner, more semantic web components, forcing developers to build bloated, error-prone alternatives instead of leveraging existing native behaviors.
• Accessibility remains a contentious field, split between those who view current compliance standards as a "racket" for predatory litigation and those who argue that AI-driven tools will soon render manual compliance efforts obsolete by bridging the gap between non-accessible code and user needs.
• LLMs are increasingly used to patch accessibility gaps in poorly written code, though reliance on AI for these tasks risks reinforcing bad patterns and ignoring the fundamental need for robust, native architecture.
• The "native vs. custom" debate is complicated by cross-browser inconsistency; when even basic native components behave differently across platforms, developers are incentivized to build their own abstractions to ensure a predictable user experience.
• Relying on third-party component libraries is often more economically efficient than ground-up development, but this shift creates dependency bloat and risks losing the understanding of how fundamental browser interactions—like form submission and pointer events—actually function.
• There is significant skepticism regarding whether "AI-assisted accessibility" will actually solve structural issues, as modern interfaces require more than just reading screen text; they require complex, stateful interaction that current LLM agents may struggle to replicate reliably.
• The current state of web development is arguably stuck in a period of stagnation, where the desire for high-fidelity custom design clashes with the need for performant, standard-compliant applications, resulting in high levels of wasted developer effort.
The discussion reflects a deep frustration with the current state of web development, where the inherent limitations of standard HTML widgets drive developers toward complex, custom solutions that are often less accessible and less performant. There is a palpable tension between the ideal of using native browser features and the practical reality of building modern, brand-aligned interfaces that behave consistently across platforms. While some see AI as a panacea for fixing accessibility and simplifying implementation, others remain skeptical, viewing the reliance on large frameworks and "do-it-yourself" UI components as a sign of industry-wide inefficiency. Ultimately, the consensus suggests that the web is still maturing from a document-delivery medium into an application platform, a transition that remains hindered by inconsistent browser standards and a lack of consensus on the future of UI design.