与框架无关的选择和提示组件，采用Web组件构建。
嗨，HN，
在过去的几年里，我一直在多个前端技术栈（如 React、Vue、Angular 等）中工作，但我遇到的一个反复出现的挫折是：
核心 UI 组件，如选择框和通知，每次框架更改时都需要重写。
即使行为和用户体验基本相同，具体实现却与框架紧密耦合，这使得长期使用的 UI 逻辑异常脆弱。
因此，我决定尝试一种不同的方法：将 UI 原语构建为原生 Web 组件，然后根据需要为框架进行封装，而不是重新实现它们。
最终，我构建了两个组件：
- SeoSelect — 一个面向生产的选择组件
- 支持大数据集的虚拟滚动
- 多语言模糊搜索（包括韩语、日语和中文输入模式）
- 默认支持键盘和屏幕阅读器可访问性
- 零运行时依赖
- SeoToast — 一个轻量级、与框架无关的通知组件
- 多种位置和动画效果
- 重复消息分组
- SSR 安全行为
- 压缩后约 10KB
这两个组件首先作为纯 Web 组件实现，仅在改善开发者体验的情况下添加框架封装。
我并不是想取代框架——这更多是为了测试 UI 原语是否可以在框架生命周期之外存在，同时仍然适用于实际应用。
我非常希望能得到以下方面的反馈：
- 在生产中使用过 Web 组件的人
- 构建过跨框架共享设计系统的人
- 遇到过这种方法的局限性或尖锐问题的人
链接：
- [SeoSelect](https://www.npmjs.com/package/seo-select)
- [SeoToast](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!