【译】当不使用JavaScript框架时

很是有价值的建议：哪些框架是合理的，哪些并不合理。

做者：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工做。

---

欢迎扫描二维码关注公众号，天天推送我翻译的技术文章。