在软件开发领域，框架的使用已成为一种常态。然而，本文将探讨一种不同的策略：无框架开发。通过高治理的方式，可以在不依赖第三方框架的情况下进行开发，这不仅可行，而且是一种值得追求的策略。那么，什么是“高治理”呢？高治理是指利用经验和知识，保持控制并做出明智决策的能力。使用框架意味着选择将一定程度的治理权交给第三方。只要框架带来的益处能够抵消失去的治理，这并不是一个错误的决定。但往往在最不适当的时机，框架会成为开发的障碍。这是因为所有框架都基于假设，而所有的假设都有漏洞。因此，不仅放弃了治理权，还不得不解决由于假设漏洞造成的障碍。
本文是系列文章的第一部分，探讨了开发无框架应用程序的背景、动机和架构方法。第二部分将展示无框架应用程序的实现。第三部分将反驳反对无框架应用程序开发的论点。
有了工作应用程序，可以更好地反驳反对实现无框架解决方案的论点，这也是本文的灵感来源。虽然框架确实承担了很多繁重的工作，但通常也伴随着更多的成本。开发者的学习曲线成本增加，增加了专有扩展，降低了透明度，锁定了供应商，甚至更糟，锁定了版本。放弃编程模型的控制或破坏架构以适应专有框架，从长远来看都是有成本的。
反对直接操作DOM的论点是一个治理问题。数据绑定通常使用专有层来执行DOM操作，但代码通常对开发者是不透明的。理想情况下，设计师可以在不影响视图代码的情况下更改表示。但实际上，设计师的知识仅限于有效的HTML。他们不会插入声明式绑定扩展，因此开发者仍然必须在HTML中添加数据绑定扩展。
探索了各种模板策略——从在HTML中嵌入模板到在服务器上托管模板。TodoMVC使用了流行的Handlebars模板引擎，它提供了标准的模板语法和过程。TodoTemplate将模板处理隔离开来，以防止表示从视图中泄露。
将jQuery（一个库）与应用程序架构进行对比是极其可疑的。具有讽刺意味的是，MVP架构不是专有的，是完全开放的，透明的，可调试的，易于教学和学习。奇怪的是，反对jQuery的论点忽略了MVP。很难找到对不同专有MVVM框架应用的不透明数据绑定内部的清晰和详细解释。这些问题的出现是因为低治理实践强化了对内部缺乏智力好奇心的持续缺乏。
就像之前的论点一样，依赖管理论点错误地将苹果和橙子进行比较。jQuery的目的是操作DOM，而RequireJS是支持依赖模块加载的首选。如果依赖管理没有“内置”，这并不重要，因为高治理将其留给开发者决定适合他们需求和目标的正确方法和工具。
除非打算编写自己的测试框架，否则必须有一个单元测试库。这个事实使反对使用无框架的论点失去了信誉，如下图所示。
相反，支持依赖注入（DI）的论点更难驳斥。这是因为依赖注入是由SOLID设计模式普及的，其中“D”代表依赖注入，并且由测试驱动开发（TDD）使用，其中DI用于执行模拟。
支付卡行业（PCI）合规意味着遵守特定于信用卡处理的数据安全标准。这个论点有两个令人困惑和矛盾的方面。首先，这个论点是针对jQuery的，作为一个库，jQuery没有被要求提供“厨房水槽”功能集。其次，这个论点忽略了真正的问题：PCI合规是应用程序的要求吗？如果不是要求，那么拥有它就违反了YAGNI。
人员配置论点的荒谬性使得这个反驳看起来毫无意义。这个论点类似于声称由于ASP.NET程序员的供应充足，很难找到C#开发者。这两者并不是互斥的。然而，感兴趣的不仅仅是好的开发者，而是理解使用框架所带来的挫折、障碍、成本和好处的高治理开发者。
不幸的是，这个论点将一致性与一致性混淆了。一致性正是高治理所关注的。非常相信开发者的知识、学习和推理能力，以一致地做出明智的决策。这就是为什么治理是开发的一个重要方面。
YAGNI的反论点在这里也适用。需求决定了应用程序所需的安全级别。开发者可以从许多库、编程模式和加密技术中进行选择。
幸运的是，有许多库、模式和解决方案可供选择，这些选择来自于愿意分享他们最喜欢的工具、方法和成功经验的高治理开发者社区。这些开发者避免了导致障碍的漏洞假设、反模式和锁定。他们渴望低摩擦学习、透明度、平滑的调试体验，最重要的是促进高治理开发，这有利于常识决策和控制，而不是习惯和一致性的实践。