作者回顾了与 CSS 的旅程：起初拥抱 Tailwind 以获取其结构，如今则转向原生 CSS。这一转变源于希望更深入地理解 CSS 并提升技能。作者详述了新的 CSS 结构，包括导入的重置样式、基于组件的样式、预定义的颜色变量，以及从 Tailwind 借鉴而来的字体大小系统。同时，作者利用工具类，建立全局样式基础，并有意识地管理间距。响应式设计更多依赖 CSS Grid 布局，而非 Tailwind 以媒体查询为核心的方法。构建系统在生产环境中使用 esbuild 进行打包，尽管在开发阶段并非必需。作者阐述了迁移的关键原因，包括对构建系统的依赖、CSS 知识的提升、Tailwind 的局限性，以及对更具语义化 HTML 的追求。最后，作者讨论了 @layer 等特性，在认可 Tailwind 优势的同时，也肯定其原则的价值。

作者已停止使用 Tailwind，但怀念其便捷的调色板。他们寻求替代 Tailwind 颜色系统的方案，以提升工作流程效率。作者希望获得预定义的调色板，尤其是便于在 CSS 中使用的方案。作者在 Mastodon 上征求调色板建议，并决定汇总回复内容。该帖子列出了多种调色板，如 uchū、flexoki 和 reasonable colours。此外，还提供了其他多种调色板与设计系统供参考。帖子中介绍了一系列颜色方案生成器，尽管作者认为它们使用较为困难。同时，还展示了其他颜色工具，包括色盲友好信息以及 oklch CSS 函数。作者希望该资源能对自己以及寻求 CSS 颜色解决方案的其他人有所帮助。

作者旨在编写不依赖 Node.js 的前端 JavaScript。遇到的一个主要挑战是缺乏有效的前端代码测试方法。此前尝试使用 Playwright，但因其速度较慢且需要 Node.js 而被认为不可行。为此，作者受 Alex Chan 关于极简浏览器内单元测试框架工作的启发，探索直接在浏览器标签页中运行测试。虽然 Chan 的方法侧重于单元测试，但作者希望在不经过 Node.js 构建流程的情况下，对 Vue 组件执行端到端集成测试。 作者选用 QUnit 作为测试框架，赞赏其“重新运行测试”按钮在调试中的便利性。该过程包括将 Vue 组件全局暴露，并创建一个 `mountComponent` 函数，用于在页面外部的不可见 div 中渲染这些组件。测试夹具（fixture）数据通过向专用端点发送 POST 请求重置数据库来管理。随后，一个基础测试会渲染一个组件并断言其内容。 遇到的关键问题包括等待异步操作完成，这促使作者开发了一个 `waitFor()` 函数。确定需要等待的正确元素或条件颇具挑战性，这也引发了关于重构应用程序以提升可靠性的建议。作者还尝试通过添加 CSS 类来标识元素，并注意到像 Testing Library 这样的库推荐更具可访问性的方法。 表单处理带来了困难，因为仅仅设置值是不够的，还需要触发相关的 DOM 事件。这一点凸显了 UI 测试库为何能够简化此类任务。测试覆盖率部分借助 Chrome 内置的开发者工具进行评估，但该过程需要特定的配置和操作才能与打包后的 JavaScript 配合工作。 尽管存在学习曲线，作者仍认为这段经历令人愉快，并对为前端项目构建自信可靠的测试套件充满乐观。此外，作者也在考虑进一步探索像 Testing Library 这样的库，该库提供与浏览器独占执行兼容的 UMD 构建版本，并正在思考如何将主要面向浏览器的测试集成到持续集成（CI）环境中。