最近有一些关于技术独立性的好文章。
Brad Frost 认为设计系统本身比任何特定技术更高层级
… 它不会把所有赌注押在一个技术上，系统能够适应工具、技术和趋势的必然变化。
Jonathan Snook 认为 Mustache 是一个不错的选择 用于其他技术独立的模板化
我喜欢它因为它简单，而且它要求在看到模板之前完成大量的数据处理工作。
这是我在最近的一次研讨会上使用的一张幻灯片
我主要指的是 **完全的 HTML 独立性**。HTML 来自哪里对我来说并不重要。
- Drupal 生成了 HTML 吗？没问题。
- HTML 在 JSX 中吗？没问题。
- 它是 Mustache 模板吗？没问题。
- 我像精英黑客一样编辑完全原始的 HTML 吗？没问题。
- 我正在 Nunjucks 中将片段拼凑在一起吗？没问题。
- 这是 Rails ERB 东西吗？没问题。
我关心的是最终输出。无论是什么创建最终的 HTML，我都负责使其干净、可管理、可访问、语义化且高效。
需要说明的是，我确实 **关心** 技术栈。我了解不同技术的优缺点（或者至少我努力了解，并可以进行研究）。只是当戴着我的前端开发人员帽子时，我最关心的事情是最终到达浏览器的 HTML 代码块。
所以，一个小小的旁注，我敢打赌，精通 HTML 并成为一个通用的开发者会让你更有竞争力。
我已经这样说了很多年了。我也这样说过内容迁移。尽可能地忽略它存储在什么地方，只导入输出（实际上远不止 HTML）。
这排除了 WP 中的短代码、论坛中的 bb-代码（一些让我在过去几年里头疼的东西）。在我 2014 年迁移的一款软件中，后端似乎对日期进行了错误处理，但在前端看起来很好。解决方案是修补主题/皮肤，使其将输出的值直接发送到一个新的软件。效果很好，最终省去了很多脑力。
我并不完全同意这一点。至少在 CMS 的情况下，组织和 UI 需要尽可能地适合客户/管理员。因此，无论你是否关心 HTML 来自 Drupal 还是其他地方，你都应该为了付钱给你的客户而这样做。
我不明白你的观点。我当然不认为你应该构建不适合客户的 UI。
我认为 Ryan 想要表达的意思是，如果客户不喜欢你选择的 CMS，那么 HTML 看起来如何就不重要了，因为他们不会使用它。我同意 CMS 的决定应该考虑到输入和输出。可能需要在某一方面做出一些妥协，但客户需要对前后端都满意。
恕我直言，结论应该改为“无论在浏览器中创建什么 DOM”。所有这些 JavaScript 模板化东西根本不会创建 HTML，它只是 JavaScript 操作 DOM（除了 JSX 的服务器端预渲染）。还有其他情况，HTML 可能会对 DOM 的实际外观产生错误的印象。例如，可选的 HTML 元素/属性，如“tbody”，会在 DOM 中自动创建。
你可能会觉得这个评论很吹毛求疵，但根据我的经验，DOM 和 HTML 之间的区别会导致很多混淆，只是因为这些术语经常被错误使用。始终是 DOM 才是重要的。
我完全同意。我以前是全栈开发人员，需要关心后端和前端世界，但现在我仅仅是前端开发人员，只需要关心我的 HTML、CSS 和 JavaScript。这使我的生活更轻松，让我可以运用最佳实践，让后端天才去寻找如何最好地提供我给他们的数据和 HTML。
我很感谢像这样的文章。我在一个 CMS 上工作了 14 年多，我们最近才迁移到 mustache，原因是一样的。时间证明了什么有效，什么无效。所有模板、配置、显示、图形等… 尽可能地符合行业标准。
当遇到尊重我将数据/内容移入移出系统、控制其使用和显示方式的专有系统时，我知道他们具有长远的眼光。
将权力和控制放在正确的人手中，可以使每个人的生活更轻松。程序员应该编程，设计师应该设计，内容编辑应该编辑内容。这是一个简单的方案。（万岁，简单的系统）