javascript 框架_什么时候不使用JavaScript框架

javascript 框架

随着互联网的发展，Web开发的发展已超出其预期的能力（无论好坏）。 为了使粗糙的边缘更平滑，Web开发人员已经发明了许多框架，这些框架既小又小 。 这对开发人员来说是一件好事，因为浏览器碎片化和标准问题不胜枚举，特别是对于那些希望在API中添加新功能并希望这些功能使用更统一的语法的用户而言。 另外，在大多数情况下，框架都是开源的，这对每个人都非常有用。

现在，看到那些粗糙的边缘已经随着时间的流逝而磨损，并且不像以前那样尖锐，我们可能应该减少对我们创建的某些框架的使用。 在其他方面，我们只需要考虑为给定任务使用框架的成本。

我们可以做的事情

考虑一下谦虚的HTTP请求，它曾经是一个简单的GET的良好的50行功能，该简单的GET在Firefox和Internet Explorer中都可以使用。 例如，这是一个执行POST的简单函数； 作为主要的React数据泵，我们在Phone Janitor的生产中使用了一年多的时间：

   
   

    
    
 
     
     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 
     
     ) 
     
     ) 
     
     ; 
     
     


     
     } 
    
    
   
   

无需框架即可轻松重写此代码，以与Promises一起使用 ，可适应请求类型，或支持可能对您的应用程序至关重要的许多功能。 精心设计的吗？ 也许不会。 它坚固吗？ 当时是为了我们的需要。 要点是关于什么是什么不是什么，而不是关于我为什么还要使用其他东西的更多信息。

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

万物万物

我们使用的服务在各种用例中会尝试成为许多事物。 这确实是问题的症结所在。 为社区的利益而统一API是一件好事，因为有些事情是细微的，而且很难单独完成。 发明jQuery是因为浏览器的处理方式大相径庭，而JavaScript API的功能却不多。 但是，有一段时间，每个Web开发人员都包括jQuery，以便他们可以为简单的innerHTML选择文档对象模块（DOM）元素，这对页面加载时间产生了显着影响。 现在考虑该用例：

   
   

    
    
 
     
     // 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 src files	1个src文件
~40 lines of code per file on average	81行代码，包括注释（可悲的是，数量并不多）
npm package includes all of angular	不是包，不依赖任何东西，这只是另一个指令

我们自己的解决方案无法处理库处理的所有情况。 我们不需要这些情况，如果需要，我们可以很容易地以可移植到我们的工作流和其他框架的方式添加它们。 这是我们每个人都需要根据自己的特定需求决定的折衷类型。 两种选择都不可耻。

什么时候应该和不应该使用框架

我强烈建议知道特定工具的编码目的。 如果我们的目标是暂时将它们快速融合在一起，那么对它进行良好的设计可能并不重要。 如果要延长寿命，我认为使用框架工具是我们需要权衡的重点。 很难从一个框架过渡过来，特别是如果我们添加一些库进一步将我们纳入该框架。

如果只花一两天的时间来编写自己的解决方案，我会倾向于这一点。 如果需要一周或更长时间，则注意事项可能会更改。

编写自己的另一个好理由是，如果将自己耦合到一个在项目生命周期内可能不存在的框架上会很昂贵。 但是，如果这是一件非常复杂的事情，例如集成PDF支持，则您可能不想考虑编写自己的文件，因为这就是疯狂。

与任何类型的软件工程一样，将您的工作视为结构。 如果您要建造狗屋，那么您所做的任何事情都可能没问题。 如果您要建造摩天大楼，则必须做更多的规划。 我们在哪里划清界限？ 框架的作用与您要构建的材料和建筑样式的作用相同。 它是否适合环境，是否可以在以后需要时提供替换材料？ 尽管您的决定是您自己决定的，但我希望这些信息和这些示例可以为您提供指导。

Tod Hansmann将于2017年7月12日至15日在盐湖城的OpenWest上发表题为JavaScript：不使用框架的内容的演讲 。

翻译自: https://opensource.com/article/17/6/javascript-frameworks

javascript 框架