为什么需要自己实现前端框架

为什么需要自己实现前端框架

前端对框架(库)的大小更敏感

前端内容的渲染和交互效果的实现如果依赖JS框架(库)，需要先将这些框架(库)下载到客户端，此时框架(库)的大小将直接影响到前端的首屏渲染速度。框架(库)越小，加载的速度就越快，而随着功能的越来越全，框架(库)必然会越来越大，要保证性能，需要制定加载策略。

便于制定加载策略

解决框架(库)变大的常见加载策略是将框架分为核心部分和扩展部分，核心部分在首屏渲染前必须下载完成，并且这部分的加载文件尽可能的少和小，扩展部分则可以模块化方式来懒加载。

核心部分的JS在发布时，可对文件合并，数量尽可能少，单个文件在gzip压缩后最好不要超过20K。核心部分可以是实现“JS语言扩展(面向对象)，DOM操作API，数据交互方法(ajax)，导航策略，模块化底层实现，事件底层实现，模版解析”等。扩展部分一般是一些可异步加载的UI组件，例如：输入控件、弹出窗、动画API、文件上传及预览、图表控件、富文本编辑器等。

上面的实现模式，在主流的JS框架(库)中，有三类选择：一类是以ExtJS为代表的大而全的框架(库)，这类框架虽然功能满足，但往往无法拆分为核心部分和扩展部分来加载，因此基本不予考虑；一类是相对轻量的YUI3、Dojo等框架(库)；一类是近来流行的前端MV*系列Backbone、Ember、Angular，这类在充当核心部分时，还需要组合Underscore、RequireJS，jQuery等第三方库。

后面两类可以满足要求，但个人觉得不是完美的方案，因为在开发实际产品时，将这两类作为核心部分时，往往里面有很多是不需要的，而还有些需要自己来额外补充近来，可以是自己开发，也可以集成第三方的实现。而核心部分框架(库)如果是自己实现，则可以保证在功能完整的情况下，不多出其它的东西，加载的JS可以控制到最小，而且代码风格也统一。

便于扩展

前端代码与用户的交互直接相关，而交互的设计变化和不确定性非常大，现成的第三方实现往往难以直接利用，需要改造。有时改造第三方的框架，先要非常熟悉框架，当这个框架比较复杂时，这样的工作量和难度就大大加大了。而自实现的框架(库)则可以根据需要任意扩展，可以根据需求制定对应的规范和API。