如果摆上一桌好菜，我立马就会思考我先吃哪个菜，哪个菜我喜欢吃多吃点，哪个菜没吃过我要尝尝，哪个菜不喜欢吃看都不会看一眼；如果出去旅游，我也会想我去过哪里，没去过那里，我最想去哪里；如果让我技术选型，不好意思我只是个切图仔我不会，领导觉得该选什么技术栈我就用什么技术栈。
由于自己没有充分地思考，一直依赖于领导，引发了各种惨案。
背景
时间：大约2017年前后
地点：某互联网公司
任务：选择前端 UI 组件库
技术栈：Vue
2017 年那个时候的 Vue 的 Star 还没有那么的多，但是特别受到国内中小公司的青睐，文档是中文的，特别容易读懂，Vue 的生态基本都是由自家维护，比如 Vue Router、Vuex 都是原班人马去维护，这一点减少了前端们对于各种技术选型的困惑；然而与之相反，Vue UI 轮子则需要进行对比挑选了，当时就有两大 UI 库： IView（2016.11）、Element（2016.12） ，当时 ant-design-vue（2018.4） 还没有出现，更别提 acro design（2021.11） 。IView 和 Element 都很好，但是当时的选择在现在看来是否正确呢？肯定很多人选错了，最后在一条错误的道路上越陷越深，留下了深深的技术债。
领导毫不犹豫地选择了 IView，现在看来都有很多人诟病的 UI 库，为什么会选择它？因为当时只有两个选择， 非 Element 即 IView ，留给大家思考横向对比的机会不多。就像现在行情不好，僧多粥少，这样往往就能够选择到水平更好的人才，而当时的情况就是选择很少，横向对比也不充分，很容易选错，而且一旦选错后面连改过的机会都没有，一旦选择了某个 UI 库那么就不可能重头再来了，这也是选择的代价，目前也没有哪一种办法能够平滑在不同 UI 库之间来回切换，所以说现在把技术选型搞透也还有几分用武之地，如果一旦前端大一统比如说浏览器层面啥都给实现了的话，那个时候就真的不需要什么选型了。
劫难
时间：2023 年
地点：某互联网公司
主人公：我
任务：入职开始做需求
来这里之前我从来没有用过 IView，我当然不知道它好不好用，但是当我看到字里行间的 render 函数时我就觉得这是 UI 库层面出了问题吧。首先不说大家的水平如何，一个新的 UI 库，我当然是先看它的官方文档，照着官方文档去写，那准没有错吧？
学过 Vue 的朋友们都知道，render 函数就是底层创建 VNode 的函数，是一个非常底层的方法，既然 UI 库是对基础组件的封装，它应该只暴露给我们上层的接口，应该将底层的一些方法封装起来，更方便给开发者使用，当你发现 data 中有 100 行甚至更多的 render 函数时，内心是多么的崩溃啊！
其次就是官方文档，以前我都是用Mac开发，没有感觉，但是当我切换到Windows开发之后，我发现IView 的文档真的没法用；IView 文档大部分为左右布局，右边是示例代码，但是有时候示例代码超过一屏，这样的话在Windows上就要先滚动到底部去寻找滚动条，滚动之后再划到上面看代码，并且滚动条滚动的地方还有bug，非常不好用。
所以我便诞生了一个想法：能不能穿越回去帮领导做一下技术选型呢？
组件库技术选型
时间：2024 年某个深夜
地点：家里
任务：我要穿越回 2017 年（当时还是 Vue2，Vue2 是 2016 年发版的），改变当时的 UI 库，但是在此之前我必须学会技术选型啊
选择一个库，技术团队和官网是门面，也是第一印象 。虽然不能把这个作为决定性因素，但也很重要。
Element：饿了么团队，应该是属于是名牌团队了，IView：基本上属于个人开发者； Element 官网做了响应式设计，IView也做了响应式，但是不支持移动端。不是说 IView 的作者不牛，而是 Element 背后的团队太强大，所以这一波 Element 略胜一筹。
其次就是使用成本，学习成本要尽可能小，照顾到大部分团队同学 ，不能把人人都当做技术大佬，这样的库当然是不成熟的，我们看使用成本就是看一些中后台高频的组件的使用方式，接入方式是否便捷。那么中后台有哪些高频组件呢？
首当其冲的一定是 Table 组件 ：对于 Table 组件如何渲染，iView 和 Element 采用的是两种思路，iView 采用的是类 React 语法，而 Element 才是采用的 Vue 的语法，为什么这么说，我们来看一看：
iView早期版本直接使用 render 函数渲染，这样做有什么好处呢？就是 能够结合 babel 使用 jsx 语法；但是显然这一步学习成本较高，大部分同学就直接按照官网的 render 函数去写了，产生了很多难以维护的代码 ，这里就不列举了，一旦表格项操作较多，render 函数能够上百甚至几百行。而 Element 使用 el-table-column 组件来表达列，这样做好处多多，首先 既能够支持在模版上直接写，也能够通过数组进行遍历，灵活度较高。
另外 scoped-slots 本来就是 Vue 这个 DSL 的一个特性，这属于充分利用语言特性的操作了。 对于 Table 组件而言，我个人更偏向于 Element 。
再看 Form 组件： ：就Form组件而言，Element 与 Iview 差不多，而且都缺少一个功能就是校验出错之后跳转到第一个出错的表单组件上，这个需要进一步封装。
最后再看看 DatePicker 组件： ：DatePicker 组件最头疼的一个问题就是返回的是 Date 对象而且输入也必须是 Date 对象，隔壁的 Antd 就完美地解决了这个问题，其实这个问题也比较好解决，自己可以定义一个计算属性，然后对 YYYY-MM-DD 类型的日期进行一个转化，但是如果组件层面就解决了那是不是更加完美呢？还是因为团队同学大家水平参差不齐的缘故，有大部分同学不会考虑这样转化，每次都是直接定义一个 Date 对象，然后提交之前转化为字符串，回显的时候又从字符串转化为 Date 对象，增加了很多不必要的代码。
有了这一个前提，再来看看 IView 和 Element，只有 Element 提供了这个功能，甚至还支持时间戳：
总而言之， Element 在细节的完善方面还是略胜一筹的 ，而 IView 则需要自己的进一步封装。 看一个组件库的使用成本，首先需要看自己使用的场景是 b 端还是 c 端，比方说文中是对 b 端进行组件库选型，那么可以先调研一些使用频率高的组件例如 Table、Form、DatePicker、日期区间组件、Select、级联组件、Upload、弹窗组件等等
可能还有的同学想要去比较一下组件库的大小、主题定制、Star 数量、社区活跃度方面，但是依我看来这些对于是否选择这个组件库只能起辅助作用，真正起决定性作用的还是其使用成本的大小，也就是其组件本身提供的能力是否强大
穿越
回顾一下，组件库选型的几个方面：组件库压缩后体积、主题定制、Star 数量、社区活跃度，这几个方面都不重要；重要的是另外几个方面： 背后的技术团队和官网的体验、组件的使用成本 。带着这些理由就可以穿越回去说服老板选择 Element 了......
补充一点：可能本文有点事后诸葛亮了，因为页面 UI 看起来还是 viewUI 更胜一筹，Element 界面实在是有苦难言，而 viewUI 开发体验差这都比不上第一印象分。
作者：蚂小蚁
链接：https://juejin.cn/post/7360143810599223350
