何时不应使用 JavaScript 框架

随着互联网的发展，Web 开发已经远远超出了其最初的预期能力——有好也有坏。为了消除粗糙的边缘，Web 开发人员发明了大量的框架，有小的，也有不小的。这对开发人员来说是好事，因为浏览器碎片化和标准问题比比皆是，特别是对于那些希望在 API 中使用新功能并为这些功能提供更统一语法的人来说。此外，在很大程度上，这些框架都是开源的，这对每个人都很好。

现在，看到那些粗糙的边缘已经被时间磨平，不再像以前那样尖锐，我们可能应该减少使用我们创建的一些框架。在其他方面，我们只需要考虑为给定任务使用框架的成本。

我们可以自己做的事情

考虑一下简单的 HTTP 请求，曾经对于在 Firefox 和 Internet Explorer 中都能工作的简单 GET 请求来说，这是一个很好的 50 行函数。例如，这是一个执行 POST 的简单函数；我们在 Phone Janitor 中将其用于生产环境超过一年，作为我们主要的 React 数据泵

function postMe(name, data, callback, onError) {
    var request = new XMLHttpRequest();
    request.onreadystatechange = function() {
        if (request.readyState != 4 || request.status != 200) { return; }
        var body = JSON.parse(request.responseText);
        if (body.error) {
            onError(body.error);
        }
        else {
            callback.(body);
        }
    };
    request.open("POST", '/api/' + name, true);
    request.setRequestHeader("Content-type", "application/json");
    request.send(JSON.stringify(data));
}

这段不使用框架的代码可以很容易地重写以与 Promise 一起工作，适应请求类型，或支持任何对您的应用程序至关重要的功能。它是否经过精心设计？也许不是。它是否健壮？对于我们当时的需求来说是这样的。重点不是它是什么或不是什么，而是我为什么要使用其他任何东西。

如果我不想编写自己的 HTTP 请求引擎，那么有很多选择。但是，它们都有成本。它们有多大？我如何将它们包含在我的代码中，以及它如何影响我的工作流程？它们还在执行哪些不必要的事情，从而浪费执行时间？如果我花了一个小时（这大约是我们花在代码和测试上的时间）来实现这个函数以满足我的所有需求，那么与集成一个库来做同样的事情相比，这会节省大量时间吗？我们每个人都会有不同的答案。

满足所有人的需求

我们消费的服务试图满足各种用例的多种需求。这实际上是问题的关键。统一社区的 API 是一件好事，因为有些事情很微妙，而且很难独自完成。jQuery 的发明是因为浏览器的工作方式截然不同，而 JavaScript API 没有太多内容。曾经有一段时间，每个 Web 开发人员都包含 jQuery，只是为了选择文档对象模型 (DOM) 元素进行简单的 innerHTML 操作，这会对页面加载时间产生明显的影响。考虑一下现在的用例

// Author's note, this is mostly for example, don't manipulate DOM unless you know what that means for your app

var el1 = document.getElementById(id_Name);
var el2 = document.getElementsByClass(class_Name); // returns array
var el3 = document.querySelector("div.user-panel.main input[name='login']");

// Want it in a jquery style function name?

var $ = document.querySelector; // Or get fancier if you wish
var el4 = $("div.user-panel.main input[name='login']");

在很多地方我们仍然包含 jQuery 来做这件事（例如，普通的 WordPress 主题）。不要只听我的一面之词；请随意查看它是否包含在内。现在，没有 jQuery 我们也能做很多事情。

即使我们使用框架

但这不仅仅是我们如何以及何时使用框架的问题；也关系到我们如何处理功能和附加组件。例如，考虑将 Google Visualization 集成到 Angular 框架中。在 MobilSense，我们严重依赖图表向管理团队报告——但我们也使用 Angular 1.5。那么，我们如何将更新功能集成到我们应用程序的图表中呢？

我们的选择是使用 angular-google-chart 或开发我们自己的解决方案。虽然 angular-google-chart 是一个出色的库——我在其他地方使用过它，并且我感谢作者免费支持他的项目——但我们决定自己做，原因现在很明显。以下是它们的比较

我们自己的解决方案不能处理库处理的所有情况。我们不需要这些情况，如果我们需要，我们可能会很容易地添加它们，并以一种可移植到我们的工作流程和其他框架的方式添加它们。这是我们需要根据我们自己的特定需求来决定的权衡类型。任何一种选择都没有什么可耻的。

我们何时应该以及不应该使用框架

我强烈主张了解编写给定工具的目的。如果我们的目标是快速拼凑一个临时存在的东西，那么对其进行良好的工程设计可能并不重要。如果我们追求长久性，我认为我们需要更认真地权衡使用框架工具。框架很难摆脱，特别是如果我们添加进一步将我们束缚在框架中的库时。

如果编写您自己的解决方案只需要一两天，我倾向于这样做。如果需要一周或更长时间，那么考虑因素可能会改变。

编写您自己的解决方案的另一个好理由是，如果将自己与一个可能不会在您的项目生命周期内存在的框架耦合起来会付出高昂的代价。但是，如果这是一件非常复杂的事情，例如集成 PDF 支持，您可能不想考虑自己编写，因为那样会陷入疯狂。

与任何类型的软件工程一样，将您的工作视为建筑。如果您正在建造狗窝，那么您做的任何事情都可能没问题。如果您正在建造摩天大楼，您需要做更多的规划。我们如何划分它们之间的界限？框架的作用与您正在建造的建筑的材料和风格的作用相同。它是否适合环境，我们以后需要时可以获得替换材料吗？虽然您的决定是您自己的，但我希望这些信息和示例能帮助您做出指导。

Tod Hansmann 将在 2017 年 7 月 12 日至 15 日在盐湖城举行的 OpenWest 大会上发表题为 JavaScript：何时不应使用框架 的演讲。