从后端到前端的转变：如何选择框架？

这样的悲惨实例。

你可能会说：“谁在乎呢，只要能运行就可以了”。对于身体健全的人来说可能没什么问题，但那些需要依赖辅助技术的人将完全无法访问你的部分应用程序。

如果你没有道德上的强迫，也许会受到金钱的驱使。你需要认真考虑这样的一个事实：可访问性（A11Y）的疏忽实际上代表着巨大的经济风险，无论是在失去商业机会方面，还是在遭到诉讼威胁方面。

此外，因为急于让应用程序可运行，JavaScript 专家可能会忽略了进行搜索引擎优化（SEO）。这可能会造成很大的伤害，因为持续不断地烧钱可能对任何造成致命打击。如果产品没有吸引力，产品的质量再好都没有用。

敏捷的丧失

像 Bootstrap 和 React 这样的框架很吸引人，因为它们提供了令人难以置信的前期速度。Bootstrap 通常被认为是一种优秀的原型设计工具。不过原型工具天生就能带来低成本、低保真度的产品。

甚至“bootstrap”这个词也成了使用有限资源的代名词。在“good-fast-cheap”的模式中，你选择了 fast 和 cheap——无论这些决定是否是有意识的。换句话说，你选择投资一个充满技术债务的产品。

不相信我说的？考虑一下未来你的造型开始变得过时的情况。新的竞争带来了更吸引人的用户体验，是时候升级你的游戏了，否则你将地位不保。

你开始进行品牌重塑，调整 Bootstrap 无穷无尽的变量列表。经过一阵的折腾，却发现你所希望的改变只有在让轮换所有开发人员之后才能保持一致。

此外，你真正想要的深度定制涉及构建复杂的 CSS 特性，以覆盖 Bootstrap 对选择器的自由使用。

你想要修改布局，但发现每个组件都使用 col 类进行硬编码。可悲的是，每个元素都在以不同的屏幕分辨率争夺空间。一个变更需要其他五个甚至更多的地方也做出修改。

这并没有那么糟糕，除非做出每个变更都需要深入到不可读的结构、样式和行为代码中，这些代码都在 render 函数中，而这些函数要在每个组件文件的末尾才能找到……

几个月后，在喝了 10 磅咖啡之后，你为再次加入竞争做好了准备（但其实那不是真的）……

如果你的目标是短期收购，你可能会不在乎。但请记住，技术的灵活性和敏捷性就是力量。如果产品的长期愿景是一台缓慢倾斜的机器，你可能会发现自己在谈判桌上处于下风。

问题的影响

在飙升的劳动力成本、诉讼风险、错失的商业机会、有限的客户获取以及无法迅速掌控局面之间，看似微不足道甚至明智的技术决策突然之间对现实世界的商业产生了影响。

对于正在处理某些类型应用程序的一些企业来说，我所讨论的一切都在完全掌控之中。然而，其他致力于其他类型应用程序的企业可能会盲目陷入长期的承诺和高维护的噩梦之中。

请记住，与开发相比，软件将在维护中度过大部分时间。通过快速搜索，我找到了以下有关维护成本分配的经验法则：

以下是一个 10 年期的成本投入情况，初始投入 100 美元，年度维护费用为 20%：

如你所见，维护成本仅用了 5 年就超过了开发阶段。在第 7 到第 8 年间超过了 60％的总成本阈值。

当然，这只是一种简化的成本示例。最有可能的情况是，在应用程序的整个生命周期中，项目越大，维护起来就越困难。从长远来看，短期目标可能导致长期后果，这种后果只会随着时间的推移而复杂化。

我也想知道如何将这些不可维护的项目排除在这些规则之外，因为维护成本变得如此之高，以至于项目直接以失败告终，并被抛弃……

根本原因

我相信，从服务器端到客户端应用程序的重大转变，将大量有才华的开发人员从后端拉到了前端。由于优势和劣势的不同，这些程序员开始改变前端的开发方式。

当然，这只是一个假设，但我认为下面这个图表有助于解释我们正处在一个恶性循环之中：

你可能已经注意到图中使用了引号，这是有原因的。“Highly skilled”只是相对于其他开发人员引入前端工具能力而言的，“Complexity”是相对于被解决的问题而言的，“Low skilled”是相对于目前在生产环境中使用的工具的复杂性而言的。

我们可以合理地假设“Highly skilled”开发人员正在引入工具来弥补他们在前端方面的不足，而不是增强整个组织的能力。例如，从使用 CSS 框架中获益最多的人是维护 CSS 能力最差的人。

我经常从 Bootstrap 支持者口中听到的一句话是“创建一个漂亮的原型是多么容易”。同样，React 的支持者会说：“永远不离开 JavaScript，我喜欢这种感觉。”

如果这些情况在你的组织中很常见，那么你的技术栈可能更多的是为传统后端开发人员的需求而设计的，而这些开发人员恰好在前端工作。

我曾经目睹过一场关于基础设施解决方案的激烈辩论，其中一方指出：

“为了让琐碎的任务变得更加容易，反而让简单的任务变得更加困难。”

当我看到我们的团队试图使用 Bootstrap 和其他替代方案解决问题时，我反而觉得没有这个必要。在我看来，他们试图使用笨拙的解决方案来规避微不足道的问题。对于这些工具的支持者来说，他们好像在为严峻的挑战提供解决方案。

解决方案

CSS 框架

为了减少对 Bootstrap 等框架的依赖，我的建议是停止将特定于框架的类直接应用于 HTML。相反，我会鼓励下面这样的做法：

%our-warning-button {
   @extend .btn;
   @extend .btn-warning;
}
.empty-shopping-cart-button {
  @extend %our-warning-button;
}

这种方法有助于将应用程序与 CSS 框架分离，可以将它们视为内部 CSS 框架的“装饰器”。你现在可以轻松地替换框架、覆盖样式，甚至可以在不牺牲前期速度的情况下发布自己的代码。

集中样式的能力意味着 UI 设计人员可以处理 CSS，不需要陷入组件的迷宫之中。通过使用领域特定语言，还可以与整个组织内的非技术团队成员和利益相关者进行更好的沟通。

最后（也是最重要的），你在结构和风格之间有了分离的关注点。

SPA 框架

这可能具有争议的，感觉就像一个令人难以置信的长期骗局，但我建议从 React 切换到 Vue.js，原因是：

你在这里看到的是 Vue 的“单文件组件”，它鼓励对关注点进行分离。我非常喜欢 Vue（以及它对简约性的承诺）。

我认为使用 Vue 有一个非常强大的商业理由，因为它降低了非 JavaScript 开发人员参与贡献的门槛。除了专业技能的价值，还会释放出忍者们在其他方面的专长。

不要误会我的意思，Vue 具有 React 等框架的所有特征。它非常灵活，可以让你创造任何你喜欢的项目。类似地，React 的实现方式更加容易掌握（虽然远不到 Vue 那样的程度）。

总的来说，我的建议采用强制分离关注点的编码实践。简化成一套简单的规则：

切勿在模板中放入任何不直接引用预先计算的数据、方法或组件的内容。

仅通过自己设计的类应用样式，并不惜一切代价地避免使用 style 属性。

如上所述，再加上将代码库划分为智能组件和非智能组件，应该可以保持 HTML 足够的逻辑和样式自由。它可能会消除一些捷径，但长期的可维护性收益可以补偿前期的成本。

英文原文：

活动推荐

QCon 北京 2019 将为大家呈现业界前端领域的前沿技术实践和未来展望，此外，100+ 国内外一线技术团队负责人也会聚焦架构设计、人工智能、工程实践、性能优化、云上安全等 26+ 领域，探索最值得参考的技术实践案例。大会报名最后 5 天，点击阅读原文或识别二维码获取大咖经验。有任何问题欢迎联系票务小姐姐 Ring，电话 / 微信：17310043226