从事前端开发以来，尤其是接触了 React、Vue 后，发现越来越多的项目在使用 ElementUI 或 Ant Design等 UI 框架时，会重新封装一套自己语言的在框架之上。
我之前也通过这样的方式，来解决大量页面采用同样风格和结构时，通过简单的配置即可生成这个页面。
之所以说是“之前”，因为我发现永远不要低估产品经理，以及要对项目有一定的远见。通常我们很难预料到这个项目会发展到什么复杂程度。
学习成本
我问过一个准备离职正在交接的同事，我问她为什么你会觉得这样封装会好，她给我的答案是，“简单快速” 或 “之前的人交接给我就是这样的”。
我认同确实这样开发可能在项目刚立项时，对前端开发来说，简单又快速。
但对于日后交接这个项目的人，会极大的增加交接成本，因为除了框架外，还得熟悉之前前端自己定义的一套语言，因为每个框架都有不同的设计模式和结构，所以不会存在行业通用的封装格式。
我遇到一个从事物流行业的同事，他们正在开发维护的一套物流订单管理系统。我在聊天时提到这个问题，他说他们公司也是通过这样的方式，在 ANTD 上重新封装一套，那我说交接的时候不会很麻烦吗，他说在他们公司，新入职的同事通常需要 3-4 个月的时间来熟悉他们的代码。这个项目已经产生无数迭代的代码，重构几乎不可能，只能在性能上进行优化。我认为这是严重的资源浪费。
无奈的扩展
通常在被封装的组件内，会有大量的 if 语句，
因为需要根据不同的配置加载不同的内容。例如针对 table 组件,每个列显示字符、按钮、单选框、下拉框等需求，这些都需要配置不同的参数进行控制。
如果产品突然修改某个页面的需求，可能仅仅只是在这个页面需要文字有不同的颜色，你就需要重新添加一个控制参数进行控制。长此以往，table 代码被封装的越来越臃肿。
另外这些 if 语句，通常在前端进行计算，将会严重消耗客户端的性能。
对用户的影响
现在越来越多的JS框架提供的路由支持页面懒加载，以及现在互联网速度越来越快，我们并不需要过分考虑文件额外加载的时间开支。
相比较于将所有封装的 js 打包到一起并通过 if 去判断可能导致的页面的迟缓和操作的卡顿，用户更愿意去等待那么 几百 ms 的 loading 过程。