前端对框架(库)的大小更敏感
前端内容的渲染和交互效果的实现如果依赖JS框架(库)，需要先将这些框架(库)下载到客户端，此时框架(库)的大小将直接影响到前端的首屏渲染速度。框架(库)越小，加载的速度就越快，而随着功能的越来越全，框架(库)必然会越来越大，要保证性能，需要制定加载策略。
便于制定加载策略
解决框架(库)变大的常见加载策略是将框架分为核心部分和扩展部分，核心部分在首屏渲染前必须下载完成，并且这部分的加载文件尽可能的少和小，扩展部分则可以模块化方式来懒加载。
核心部分的JS在发布时，可对文件合并，数量尽可能少，单个文件在gzip压缩后最好不要超过20K。核心部分可以是实现“JS语言扩展(面向对象)，DOM操作API，数据交互方法(ajax)，导航策略，模块化底层实现，事件底层实现，模版解析”等。扩展部分一般是一些可异步加载的UI组件，例如：输入控件、弹出窗、动画API、文件上传及预览、图表控件、富文本编辑器等。
上面的实现模式，在主流的JS框架(库)中，有三类选择：一类是以ExtJS为代表的大而全的框架(库)，这类框架虽然功能满足，但往往无法拆分为核心部分和扩展部分来加载，因此基本不予考虑；一类是相对轻量的YUI3、Dojo等框架(库)；一类是近来流行的前端MV*系列Backbone、Ember、Angular，这类在充当核心部分时，还需要组合Underscore、RequireJS，jQuery等第三方库。
后面两类可以满足要求，但个人觉得不是完美的方案，因为在开发实际产品时，将这两类作为核心部分时，往往里面有很多是不需要的，而还有些需要自己来额外补充近来，可以是自己开发，也可以集成第三方的实现。而核心部分框架(库)如果是自己实现，则可以保证在功能完整的情况下，不多出其它的东西，加载的JS可以控制到最小，而且代码风格也统一。
便于扩展
前端代码与用户的交互直接相关，而交互的设计变化和不确定性非常大，现成的第三方实现往往难以直接利用，需要改造。有时改造第三方的框架，先要非常熟悉框架，当这个框架比较复杂时，这样的工作量和难度就大大加大了。而自实现的框架(库)则可以根据需要任意扩展，可以根据需求制定对应的规范和API。
便于统一开发规范
不同的JS框架(库)，调用方式往往也不同（模块化规范，DOM操作API，面向对象语法糖等）。在使用第三方框架(库)，特别是组合多个第三方框架(库)时，如果要实现产品代码书写规范的一致，需要实现自己代码来包装第三方框架(库)，达到调用接口的书写风格一致。自己实现的框架(库)则可以免去这一步骤。
减少升级带来的风险
有些第三方框架(库)在版本升级后，API、浏览器兼容性支持度、实现理念可能会发生变化。例如：ExtJs3和ExtJs4的差别就非常大，如果产品急于ExtJs3开发，想升级到4几乎就要做产品重构了，而且ExtJs4不再支持低版本IE浏览器。当组合使用多个框架(库)时，其中一个升级也可能会引起彼此之间的兼容性问题。还有可能出现引用的框架(库)在升级前，在产品中没有出现问题，升级后，因为框架(库)的理念变化，导致不再适合在当前产品中使用，否则会出现性能问题。
什么情况适合使用第三方实现
(1) 非“核心库、影响到产品集成与结构的部分、常用UI组件”
为了保证性能和扩展的方便，核心包和常用的UI组件可以选择自实现。因为难以找到一个第三方框架可以包含所有的核心包所需的功能，这样核心包就会由多个第三方包组合加上部分的自行实现。在组合第三包时，往往会带来很多不需要的代码，这样就不能保证核心包的精简。UI组件往往因为需要依赖于一些核心库(框架)，常用的UI组件自己实现，一来是可以依赖自己的核心库(框架)，减少大小，一来是这些常用UI组件往往会在系统的中大量使用，对页面的的视觉等待加载时间会有大的影响，或者是有深入的个性化需求，自己实现量身打造，并且方便扩展。
(2) 复杂的UI组件
复杂的UI组件，例如：富文本编辑器，日历，动画效果，图表等。这些不会影响产品的架构，技术方向和性能，而实现又比较复杂，当产品需要时，可以选择合适的第三方实现，通过模块化方式异步加载。如果有个性化需求，而其又没有扩展接口，则可尝试修改其源码。
(3) 文件小、依赖少、功能单一
很多人会将自己些的一些框架(库)放到github上开源。像kissy，qwrap等大而全的框架(库)很少会有人去将其用到自己的产品中，一般是去学习它们的实现理念。而对于SeaJS等只实现单一功能，并且文件小，不依赖其它第三方库(框架)则大受欢迎，很多公司和个人都在自己的产品中使用。
(4) jQuery
jQuery是个特例，虽然一般只用到了它的DOM操作和ajax相关的API，这种情况下，要引入一个gzip压缩后30多K的文件，不算小了。但是jQuery太流行，它的写法已经成了前端开发事实上的规范，大家都会用它，而且很多第三方UI组件/框架/库都依赖它。
最后的总结
上面提到的问题的性质需具体情况具体分析，根据应用产品的场景和开发团队要求，可能是大问题，也可能不是问题。如果有一个稳定的前端团队，并且开发的产品打算长期优化，那么积累并完善自己的框架(库)就非常有必要了。当团队没有积累，而又有产品开发的进度限制时，可以根据产品的形态和场景，先选择成熟的第三方库（不一定是当前非常流行的），在长期的产品的优化和完善过程中会不断发现问题并解决问题，这个过程可以逐步来构建和完善自己的框架（库）。