Vue组件库大对比--HeyUI, iView, Element

时间 2019-11-05

标签 vue 组件对比 heyui iview element 繁體版

原文原文链接

目前，市面上主流的Vue组件库大概就是iview, element。
固然，heyui不在范围内，38个star屈指可数，大部分仍是认识的同事。
更可恶的仍是骗不来后端同窗的star，心塞。javascript

求Star(小💕💕)：Github
css

官网： www.heyui.tophtml

关于对比

对比呢，我总共出了几个纬度：前端

入门方式
功能
组件调用
项目大小与依赖
使用率

入门方式

按需加载

element，iview都支持按需加载。
heyui不支持。
关于支不支持按需加载，思考了好久。
也许element, iview还能够，可是若是heyui拆分组件使用，总体优点不大，后面我再介绍。vue

样式自定义

其实，这里三个组件都是差很少的。 element使用scss，iview和heyui使用less，使用变量覆盖的方式就能够了。
element提供了一个主题生成的工具，对应iview也有一个，可是这是一开始的方式了，如今你们都是推荐变量覆盖的方式。
这里，我就要推荐咱们的脚手架hey-cli，我把这些变量不是采用覆盖的方式，而是使用全局化的方式。
这样，你的@primary-color同样能够在vue的<style lang="less"/>中使用。
参考：hey-cli-template中heyui的demo
或者能够看一下：前端开发大杀器hey-clijava

国际化

element，iview都支持国际化。
heyui不支持。
伤心。
嗯嗯，若是须要国际化支持的项目，请移步element，iview。
我想说，其实heyui国际化的机制都已经写好了，缺翻译人员support，有意愿的人能够找我哦。git

总结

其实按需加载与国际化都属于极少数的需求，按需加载，我应该不会作这一方面的支持的。
若是有一些不一样意见的人，欢迎讨论。
PS: 按需加载仍是须要加载全部的样式的。
至于国际化，若是有需求或者能够提供帮助的人，欢迎联系。github

功能

功能列表

主要的功能对比来了。npm

其实，element和iview的功能都比较相似，而heyui相对来讲，和他们的区别有一些大。
首先，基础的组件都是有的，那区别在哪里呢？
heyui独有的组件：

Extend 样式扩展：基础样式。
TagInput 标签输入框：其实其余两个组件有相似功能，可是其实不太同样。
DateFullRangePicker 超级日期：功能十分强大的日期范围选择器。
TreePicker 树选择：能够替代Transfer 穿梭框或者与Cascader 级联选择，功能更强大。
Category 分类选择：与Cascader 级联选择组件实际上是相似的功能，可是heyui支持单选，多选，key模式与对象模式。
DropdownCustom 下拉控件：自定义的下拉组件。
ScrollIntoView 滚动至视图内：相信不少地方你都会须要。
Search 搜索框：搜索框的样式与机制集成。

heyui没有的组件：后端

Transfer 穿梭框：有替代组件
Cascader 级联选择：有替代组件
Breadcrumb 面包屑：样式
Carousel 走马灯：我会选用Swiper。
Collapse 折叠面板：样式
Avatar 头像：样式
Alert 警告提示：样式
ColorPicker 颜色选择器：浏览器自带有这个组件，不过若是有更多的需求量，能够考虑增长。

其实，这个是三个组件库的比对。
若是单独从有没有某种组件来判断，其实element和iview的组件库是很是相似的。
而对于heyui，从个人开发初衷来看，我注重的主要是通用性，扩展性。
从上面的比对上来看，heyui没有不少的样式组件，其实一开始参考了iview与element，开发了tag与panel。
事实发现，不多用到。
由于每个系统的设计师都拥有不一样的想法。
相反，我开发了Extend 样式扩展，这个主要是从经验上总结出来的，适用性很广。
还开发了DropdownCustom 下拉控件，这些对于扩展性上面来讲更好。

组件调用

其实element与iview之间的组件调用，大体类似。
主要在一些细节功能上，有一些差异。

组件命名方式

element用的是短横线分隔式命名，例：h-table
iview和heyui用的是驼峰式命名，例：Table

这一点上面，iview与heyui比较有优点，代码可读性上面优点更大一些。

组件的功能性

element在组件的功能性上面总体占优点。
大多数组件提供的功能都比较多。
就以table组件来讲，参数是两页屏幕都看不完，iview比heyui更多。
可是像tree或者autocomplete，heyui的实现更底层，更易扩展，比element和iview复杂的多。

数据驱动

其实这个单独拿出来讲，我是有私心的，谁让我是heyui的做者。
接下来展现的是heyui的最大的一个特点。那就是全局配置，以及数据驱动。

咱们以最简单的Select组件为例子。

Element的调用方式

<template>
  <el-select v-model="value" placeholder="请选择">
    <el-option v-for="item in options" :key="item.value" :label="item.label" :value="item.value">
    </el-option>
  </el-select>
</template>

<script> export default { data() { return { options: [{ value: '选项1', label: '黄金糕' }, { value: '选项2', label: '双皮奶' }, { value: '选项3', label: '蚵仔煎' }, { value: '选项4', label: '龙须面' }, { value: '选项5', label: '北京烤鸭' }], value: '' } } } </script>
复制代码

iView的调用方式

<template>
  <el-select v-model="value" placeholder="请选择">
    <el-option v-for="item in options" :key="item.value" :label="item.label" :value="item.value">
    </el-option>
  </el-select>
</template>

<script> export default { data() { return { options: [{ value: '选项1', label: '黄金糕' }, { value: '选项2', label: '双皮奶' }, { value: '选项3', label: '蚵仔煎' }, { value: '选项4', label: '龙须面' }, { value: '选项5', label: '北京烤鸭' }], value: '' } } } </script>
复制代码

HeyUI的调用方式

<template>
  <div v-padding="40">
    <Radio v-model="value" :datas="options"></Radio>
    <div v-height="20"></div>
    <Select v-model="value" :datas="options" placeholder="请选择"></Select>
    <div v-height="20"></div>
    <Tabs v-model="value" :datas="options"></Tabs>
  </div>
</template>

<script> export default { data() { return { options: [ { key: "a", title: "黄金糕" }, { key: "b", title: "双皮奶" }, { key: "c", title: "蚵仔煎" }, { key: "d", title: "龙须面" }, { key: "e", title: "北京烤鸭" } ], value: "a" }; } }; </script>
复制代码

实际效果

代码连接： codesandbox.io/s/zxl0yzv6n…，点击demo1的按钮

这里就只是简单的说明，后期我会着重在这一个功能上面写一篇文章。

项目大小与依赖

这里，其实我仍是比较在乎的，毕竟项目的大小和依赖仍是比较重要的。

项目大小

哈哈，感受HeyUI有一点完胜的感受。

这里我也比较客观的说一下，Element的JS大小的确比较大，主要是由于发布的时间比较长，逐步增长的功能比较多，你去看看Table的组件就能够理解。

而后iView的CSS一开始是直接用的Ant Design的，其实Ant Design的设计相对来讲更华丽一些，因此CSS相对来讲比较大一些，不事后期iView作了大量的改版，已经和Ant Design区别很大了，就是CSS的大小依旧没有降下来。

而HeyUI的全部组件都是本身写的，相对DOM的结构都比较简洁一些。
而个人设计想法比较多的是交互机制，比较在乎一些核心的问题，相对来讲，功能我不会作的大而全，另外，使用的用户也能够更方便扩展。

项目依赖

其实项目依赖上面，heyui，能够说是没有。
hey-log: console.log -> log 一个本身家的小工具
hey-utils: 本身家的公用方法
manba: 本身写的日期工具

而element与iview，其实主要的是依赖async-validator与deepmerge，还有popper.js。
其实deepmerge我本身写的hey-utils里面也有啦。
async-validator，其实我本身写了hey-validator。

由于前期改动比较大，就没有单独出来，后面已经把代码独立出来了。
不过heyui仍是直接用的源码。

就像前面说的，我必定是得了只能用本身写的代码的病!!!(坚强)

使用率

提交次数

从时间的纬度上来讲，其实提交的频率Element相对来讲更多一些。
这也是由于Element团队人员人数较多的缘由。

star数

其实关于star数，我就不对比了，十万点伤害。
不少的star也意味着更多的使用者，更多的测试者，相对来讲，bug数量也少量多。

不过，heyui也在诸多线上的系统运行，也运行了快一年了，相对来讲，bug数量也屈指可数。

issues数

欢迎你们使用heyui(谄媚微笑)。

使用率总结

这里我就不放npm下载量的一些对比了。

其实Element不论是star数量或者是issues的数量都是嗷嗷领先，可是这并不表明Element更具有优点，其实我本身在写vue组件库，这两个组件库我仍是比较清楚的。

相对来讲，star数量对于我来讲就没有很大的参考量了，毕竟iView的推广也很是的好。
你们看看就好，我眼馋一下就好，主要仍是上面的一些对比。

最终总结

感受这一篇文章应该没有不少人看，大概是作给我本身看的。 heyui与element和iview相比，并无不好，有不少不少亮眼的功能，但愿你们给heyui多一些展现的机会，多一些尝试的机会。