随着互联网的发展，程序员发明了大量的框架，既小巧又功能丰富。这对程序员来说是有益的，因为浏览器碎片和标准化问题很多，特别是对于那些想要API中的新功能以及更加统一的语法功能的用户而言。另外，在大多数情况下，框架都是开源的，这对所有人来说都是非常好的。

现在，很多问题已经渐渐地被解决，实际开发中，程序员可能不需要使用那么多框架，从项目成本而言，程序员应该学会只给特定的任务添加框架，而非所有的。

考虑一下简单的HTTP请求，一旦在Firefox和Internet Explorer中简单的几行GET代码就可以获得良好的功能。例如，以下是一个简单的功能，可以执行POST：

这个无框架代码可以轻松地被重写为使用Promises适应请求类型，或支持可能对应用程序至关重要的任何数量的功能。这就像外卖一样，需要什么点什么。

如果不想自己写HTTP请求引擎，现在的编程工具也可以提供许多辅助工具，但这往往都是有成本的。程序员需要思考：如何将那些框架和库包含在代码之中，这些又将如何影响工作流程？它们有哪些不必要的功能会浪费执行时间？如果因为引入了这些框架而需要单独花时间测试，岂不是浪费了很多成本。

统一API以达到更大的利益是件好事，因为有些事情是很细微的，很难单独做的。jQuery由于浏览器做的不同而有所不同，JavaScript API没有太多的东西。有一段时间，每个Web程序员都在用jQuery，因为这样可以为简单的innerHTML选择文档对象模块（DOM）元素，并对页面加载时间产生明显的影响。现在考虑一下下述用例：

我们仍然在很多地方，例如，一般的WordPress主题都包含jQuery。

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

我们的选择是使用angular-google-chart或开发我们自己的解决方案。虽然angular-google-chart是一个很奇妙的库，但我们还是决定自己做，这是二者对比：

我们自己的解决方案不能处理库的所有情况，但我们并不需要处理所有情况，根据具体需求选择合适的方式，都是最明智的。添加框架很难过渡，特别是进一步添加库之后，如果只需要一两天就可以自己编写解决方案，为什么不自己写呢？

总结：一到两天能写出来解决方案的就自己写，用个框架也要测试微调。超过五天才能写出来的，再考虑用框架。