使用 Web Components 构建的、与框架无关的 Select 和 Toast 组件
1 分•作者: dgseo•5 天前
Hi HN，
过去几年，我一直在使用多个前端技术栈（React、Vue、Angular 等），并且一直遇到一个反复出现的烦恼：
核心 UI 组件，比如下拉选择框和提示通知，每次框架变更时都要重写。
即使行为和用户体验基本相同，实现方式也与框架紧密耦合，这使得长期存在的 UI 逻辑出乎意料地脆弱。
因此，我决定尝试一种不同的方法：将 UI 原语构建为原生 Web Components，然后选择性地为框架进行封装，而不是重新实现它们。
因此，我构建了两个组件：
SeoSelect — 面向生产环境的下拉选择框组件
虚拟滚动，适用于大型数据集
多语言模糊搜索（包括韩语、日语和中文输入模式）
默认支持键盘和屏幕阅读器的无障碍访问
零运行时依赖
SeoToast — 轻量级、与框架无关的提示通知组件
多种位置和动画效果
重复消息分组
SSR（服务器端渲染）安全行为
~10KB gzipped
这两个组件首先被实现为纯 Web Components，仅在需要提升开发者体验时才添加框架封装。
我并不是想取代框架——这更多的是关于测试 UI 原语是否可以在框架生命周期之外存在，同时仍然适用于实际应用。
我非常感谢那些有以下经验的人的反馈：
在生产环境中使用过 Web Components
构建过跨框架共享的设计系统
遇到过这种方法的局限性或棘手问题
链接：
https://www.npmjs.com/package/seo-select
https://www.npmjs.com/package/seo-toast
很乐意回答问题或讨论权衡取舍。
谢谢！
查看原文
Hi HN,<p>I’ve been working across multiple frontend stacks over the past few years (React, Vue, Angular, etc.), and one recurring frustration kept coming up:<p>Core UI components like selects and toast notifications get rewritten every time the framework changes.<p>Even when the behavior and UX are essentially the same, the implementation is tightly coupled to the framework, which makes long-lived UI logic surprisingly fragile.<p>So I decided to experiment with a different approach:
building UI primitives as native Web Components, then optionally wrapping them for frameworks instead of re-implementing them.<p>As a result, I built two components:<p>SeoSelect — a production-oriented Select component<p>Virtual scrolling for large datasets<p>Multilingual fuzzy search (including Korean, Japanese, and Chinese input patterns)<p>Keyboard and screen reader accessibility by default<p>Zero runtime dependencies<p>SeoToast — a lightweight, framework-agnostic Toast notification component<p>Multiple positions and animations<p>Duplicate message grouping<p>SSR-safe behavior<p>~10KB gzipped<p>Both components are implemented as pure Web Components first, with framework wrappers added only where it improves developer experience.<p>I’m not trying to replace frameworks — this was more about testing whether UI primitives can live outside framework lifecycles while still being practical for real-world applications.<p>I’d really appreciate feedback from people who have:<p>Used Web Components in production<p>Built design systems shared across frameworks<p>Run into limitations or sharp edges with this approach<p>Links:<p>https://www.npmjs.com/package/seo-select<p>https://www.npmjs.com/package/seo-toast<p>Happy to answer questions or discuss trade-offs.<p>Thanks!