我一直用一套非常基础的工具（主要是 TypeScript 和 jsdom）来开发原生 web 组件，这已经成了我持续进行的一个实验。目标：在运行时尽量不依赖任何东西，并利用 web 组件的突出特性：尽量小巧、无状态的组件。
简而言之，这似乎很简单：编写 TypeScript 代码，将其转换为 JavaScript，然后“赚到好处”。理论上来说。但是，实际上涉及到了打包工具、编译器和树摇等操作。供应商锁定可能让你难以脱身。回顾一下过去两年中的更新，这可以作为未来更新的一个参考。这种方法并不总能带来积极的结果。在我看来，许多软件系统组件，比如最基本的 UI 元素，应该有独立且更为保守的更新周期。并非所有的 Web 前端，例如边缘设备上的配置界面，都易于更新。
Web 组件规范的目的是提供一系列即插即用的元素，以减少对框架的依赖。Web 组件只是解决了 React、Angular 等框架也试图解决的特定问题，但这些框架也因此需要遵循特定的开发流程、通用惯例和职业路径。简单来说: 当您的 UX 团队发布了基于 Tailwind 和 React 的 Web 组件库时，使用其他框架或纯 HTML 会更加困难。
为何要重新发明轮子？每当我采用一个新的现代框架时，它似乎都是已有的事物的不同组合，加上层层叠加的包，增加更多的抽象层次。我对软件中的抽象并不介意，但当信息抽象使我难以理解当前标准时，确实让事情变得简单。然而，我发现很难就信息架构做出明智的选择。界面是一切的基础，这也是为什么它们如此关键。
今天的工具链包含了一个对我而言稍微过大一些的依赖树。这带来了一个重大的维护挑战：框架发展迅速，频繁更新，在生产环境中不断增长的依赖和频繁的更新需求会带来不小的负担。我想知道为什么这些框架会这么“沉重”。
然后我对打包工具感到反感：TypeScript 本身已经为简单的、无状态的组件如“捆绑”、“树摇”和方法提供了支持，它主要解决了依赖单页面应用模式带来的问题。我明白这将大大减少我可使用的功能，但我已经准备好接受这些后果，并恢复我的理智。
我也想尽量避免使用运行时组件。运行时组件会在用户端引入依赖，这也是我希望避免的情况。最终，这会使项目不得不负责维护，这是我不愿意看到的。让我们看看没有它我能走多远吧。
基本规矩。这不是演习：我们得认真对待：遵循UHU（低于100）的规则：我们保持在运行TDD循环所需工具的依赖限制之内。这个限制让我们必须选择性地添加或排除功能。这个限制将防止我为了只导航第三方接口而开发过多功能。
我想更多地关注TypeScript并深入研究它的功能。通常，我们在使用TypeScript时并没有太多思考，只是不断调整配置，直到它能正常工作。结果发现它功能丰富，而且文档非常非常详尽。
JSODM是我选择的组件测试环境。Web组件标准的实现还在讨论中，我认为它仍在发展中。这种方法在理论上有一些限制，但我想要看看能把它推到什么程度。
Node 已经提供了测试工具，我也想更深入地研究一下。性能已经满足要求，到目前为止，我使用起来非常顺畅。最终，我想构建一批没有任何运行时依赖的纯 vanilla.js 网页组件，并同时开发相应的工具。修改组件的源代码后，在一个步骤中对模拟的 DOM 进行清晰的 TDD 循环应该是可能的。
体验给 Windsurf.Idea 点赞：大约花费了 40 个小时将项目推进到现在的状态。Windsurf 确实有助于代码重构和对代码库进行“意见主导的修改”。我从将一个 web 组件绑定到一个 JSDOM 对象的概念开始，这将允许组件在内存中安装。过程的另一个方面是使用 TypeScript。在将我的 TypeScript 源文件挂载到 JSDOM 之前，我仍然需要将其转换为有效的 JavaScript。我开始尝试使用 TS 编译器，发现可以在挂载组件的同时进行编译。但是速度较慢，有点让人受不了。那多个组件的多次测试怎么办？好吧，这里有缓存（我还没有尝试）或内存文件系统（in-memory filesystem）来加快构建时间。
注：此图为流程图或图表，具体详情请参阅图像。
整个过程还包括文档方面的工作。将组件转变为可以运行的演示程序应相对简单，最好是在组件的源代码中使用文档标签。例如，TSDOC 是一个有用的工具，可以连接到 TypeScript 文档解析，并允许添加自定义标签。最终，这才是真正的开始：进入一个深坑，即创建一个小工具链来帮助我构建一些非基础的纯 web 组件，这些组件仍然具有实用性。
经过一些研究，我发现音频Web组件这一话题相当吸引人：它包含了大量的数学内容，并且展示了技术、时代和其他因素的多样性。Web MIDI在提供配置各种音频设备的平台方面已经取得了很大进展，这也得到了应用案例的支持。我现在会看看能用这些工具建立多少基础组件。
看来看看结果我对 Windsurf.ai 或其他类似工具在未来帮助我的努力非常有信心。早期的 CodePilot 结合 ChatGPT 主要激发了我最近的尝试，而 Windsurf 确实让我感到升级了。这个月我已经用了 40% 的信用额度，感觉物超所值。我不常轻易称赞 GenML 工具，但在 Windsurf 的情况下，我真的从这个工具中学到了很多。与大语言模型的聊天和代码库互动的过程非常令人满意，这让我有足够的时间来审查规范，做出明智的决策，并在项目中积累大量的新信息。
代码库因其简约而引人入胜。实际上，支持主要 TDD 循环的工具依赖项少于 100 个，并且其中似乎也包含了文档生成的功能。这主要使用 commander.js、TypeScript、TypeDoc 和 memfs。
使用内存文件系统来编译 TypeScript 代码并让所有流程更快是一项大挑战。我期待通过缓存测试结果进一步缩短构建时间。
命令行工具可以包含底层框架的内容。单元测试涵盖了大部分类，即使面对复杂的更改，也感觉毫不费力。我能理解这种讽刺，即我在现有工具之上再建一层来简化开发。
相关链接
随时随地看视频
