摘要：在其他方面，我们只需要考虑针对特定任务时所使用框架的成本。当我们必须使用或不应该使用框架时我强烈主张要了解编写某个工具的目的。
非常有价值的建议：哪些框架是合理的，哪些并不合理。
作者：Tod Hansmann
来源：https://opensource.com/articl...
翻译：疯狂的技术宅
说明：本专栏文章首发于公众号：jingchengyideng 。
Image by : opensource.com
随着互联网的发展，网络发展已经远远超出了预期——不管是好的还是坏的方面。为了打磨粗糙的细节，web开发人员发明了大量的框架，既有小巧又的也有不那么小巧的。这对开发人员来说是一件好事，因为浏览器的碎片化和标准问题比比皆是，特别是对于那些想要新的API功能和更多统一语法的用户而言。此外大多数框架都是开源的，这对每个人都是有好处的。
现在可以看到这些粗糙的细节已经随着时间被逐渐打磨掉掉，不再像以前那么尖锐了，所以我们应该适当的减少一些框架的使用。在其他方面，我们只需要考虑针对特定任务时所使用框架的成本。
一些事情可以自己来做考虑一下简单的HTTP请求，曾经是一段50行的函数，就可以在 Firefox 和 Internet Explorer 中完成简单的GET搞作。举个例子，这里有一个简单的函数可以完成POST操作；我们曾经在网站 Phone Janitor（网址：https://phonejanitor.com/ ）的生产环境下使用它超过一年，并把它作为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请求引擎，也会有很多选择。不过它们都是有代价的。它们有多大？我该怎样在自己的代码中包含它们，以及它是如何影响我的工作流程的？他们还做了哪些不必要的事情消耗了时间？如果我花了一个小时（这是我们花在代码和测试上的时间）来实现这个功能以满足我所有的需求，那么与集成一个库来来实现同样的功能相比，会节省很多时间吗？对此我们每个人都会有不同的答案。
所有人的一切问题我们使用服务（services）来满足各种不同的需求。这才是问题的症结所在。为了社区利益而统一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主题)。不要随意相信我说的话，你可以自己去看看到底是不是这样。如果没有它们，我们几乎什么也做不了。
即使我们使用框架这不仅仅是我们如何以及何时使用框架的问题；它还涉及到我们如何处理特性和附加组件。例如，例如，将 Google Visualization 集成到 Angular 框架中。在 MobilSense ，我们严重依赖图表向管理团队提供报告——但我们也使用Angular 1.5。那么怎样做才能把新功能集成到我们的应用程序的图表中呢？
我们可以选择 angular-google-chart 或开发自己的解决方案库。虽然 angular-google-chart是一个很棒的库，我在其他地方也使用过它，同时很感激作者贡献他的免费项目——但是由于一些显而易见的原因，我们自己实现了相关的功能库——以下是他们的特征对比:
| Angular-Google-Charts | 我们自己的库 |
|---|---|
| 20个源码文件 | 1个源码文件 |
| 平均每个文件约40行代码 | 包括注释在内的81行代码(遗憾的是，没有太多的注释) |
| 被npm集成到angular中 | 不是一个包，不依赖任何东西，它只是另一个指令 |
我们自己的解决方案并不处理所有情况，也并不需要处理这些情况，如果一旦需要，我们可以很容易地扩充它们，并且以某种方式移植到我们的工作流和其他框架中。这是我们每个人都需要根据自己的具体需求做出的权衡。这两种选择都不丢人。
当我们必须使用或不应该使用框架时我强烈主张要了解编写某个工具的目的。如果我们的目标是一种暂时的、需要快速拼凑的东西，那么可能并不需要将其工程化。但是如果是需要被长久使用的东西，我认为使用框架工具是更合适的。一个框架一经使用便很难摆脱，特别是假如我们添加了一些库，这将进一步把我们和这个框架绑定在一起。
如果只有要一两天的时间来编写自己的解决方案，我就会倾向于这样做。如果有一周或更长的时间，我也许会改变自己的主意。
另外一个自己编写的库的理由是，使自己的项目依赖一个可能不适合你的项目生命周期的框架，代价是很昂贵的。但是，如果你要做的是一件非常复杂的事情，比如集成PDF支持，那么您可能完全不愿意考虑自己编写，因为这会把你逼疯。
与任何类型的软件工程一样，把您的工作看作是在修建一栋建筑。假如你是在造一个狗窝，实际上无论怎样都可能很好。但是如果你正在修建摩天大楼，那么就必须做更多的规划。我们应该在哪里画一条线？框架的作用与你正在使用建筑材料和建筑风格的作用是一样的。它是否适合环境，以后可以在需要时替换材料吗？虽然怎样做出决定是你自己的事情，但是我希望这些信息和例子能够帮到你。
关于作者：
Tod Hansmann - 托德·汉斯曼（Tod Hansmann）是一名技术专家，他是一名程序员，并指导新人，关注着常常被当今技术爱好者忽视的旧的开发方式。同时也是一名软件架构师，整天都在解决问题。在他看来，开源是解决问题的最佳工具。他目前在Phonejanitor.com工作。
欢迎扫描二维码关注公众号，每天推送我翻译的技术文章。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/84509.html
摘要：前端日报精选中的组件通信问题详解页面的渲染过程面试中问什么问题加实现图片前端压缩并上传用画一个迷宫中文译当不使用框架时疯狂的技术宅在翻译面向编程连续改造个网页掘金周刊技术周刊期知乎专栏技术周刊包管理的前世今生众成翻译版发布 2017-07-31 前端日报 精选 React中的组件通信问题详解 Weex 页面的渲染过程面试中问什么React问题？HTML5 file API加canvas...
摘要：概述本文为协议的第九章，本文翻译的主要内容为安全性相关内容。安全性考虑协议正文这一章描述了一些协议的可用的安全性考虑。连接保密性和完整性连接保密性是基于运行的协议的。使用一个合适的状态码的关闭帧有助于诊断这个问题。 概述 本文为 WebSocket 协议的第九章，本文翻译的主要内容为 WebSocket 安全性相关内容。 10 安全性考虑（协议正文） 这一章描述了一些 WebSocke...
摘要：概述本文为协议的第九章，本文翻译的主要内容为安全性相关内容。安全性考虑协议正文这一章描述了一些协议的可用的安全性考虑。连接保密性和完整性连接保密性是基于运行的协议的。使用一个合适的状态码的关闭帧有助于诊断这个问题。 概述 本文为 WebSocket 协议的第九章，本文翻译的主要内容为 WebSocket 安全性相关内容。 10 安全性考虑（协议正文） 这一章描述了一些 WebSocke...
摘要：它不过是硬币的另一面。因此，既然我们能够接受与通过这种方式混合在一块儿，那么是时候让介入并向我们展示硬币的另一面了第三阶段的并不是一个激进的改变，是因为我们这个行业从一开始就注定和应该是在一起的。 React框架刚刚发布的时候，JSX颠覆了很多人的想法。习惯了HTML标签与JavaScript代码分离的前端工程师们，看到JSX大概都会不禁吐槽：这些奇怪的标签出现在JavaScript里...
阅读 1425·2021-09-22 15:43
阅读 2132·2019-08-30 15:54
阅读 1100·2019-08-30 10:51
阅读 2068·2019-08-29 18:35
阅读 411·2019-08-26 11:58
阅读 2460·2019-08-26 11:38
阅读 2418·2019-08-23 18:35
阅读 3604·2019-08-23 18:33
