看了9个开源的Vue3组件库，发现这些前端流行趋势

指的是以下组件库，因为有些设计有多个版本和框架，这里只讨论Vue3版本。element-plus[3]-经典中的经典，全面支持Vue3tdesign-vue-next[4]-鹅厂优质UI组件，配套工具齐全，设计工整，文档清晰arco-design-vue[5]-字节跳动UI组件库开源，大厂逻辑，完善的设计文档ant-design-vue[6]-Ant前端UI库，面向企业级中后台naive-ui[7]-TreasureVueUI库，VueUI之星，从Vue3开始vant[8]-有赞团队开源移动端UI组件库，全面支持Vue3nutui[9]-京东出品，移动友好，面向电商业务场景vuetify[10]-oldVueUI，基于Google的MaterialDesignStyle开发varlet[11]-Varlet是基于Vue3开发的Material风格的移动端组件库，全面拥抱Vue3生态，由谷歌成立的组件库团队维护社区。名称TypeScriptMonorepo程序包管理器esbuildSVGIconCSS变量element-plustruturepnpmtrutruetruescsstdesign-vue-nexttruesubmodule无锁定文件，npmtruetruesvg&iconfonttruelessarco-design-vuetrutrueyarnvitedefaulttruetruesvg&iconfonttruelessant-design-vuetruuefalse无锁定文件，npmtrueconfonttrueifsevtrue无锁定文件，nevstrue一个全新的模式vanttrutruepnpmtruefalseiconfonttruelessnutuittruefalse没有锁文件，npmvite默认为truefalseiconfontfalsescssvuetifytruetrueyarnfalsefalseiconfonttruevarlettrutruepnpmvite默认为truefalseiconfonttrueTypeScript流行度：100%这种流行趋势现在与TS越来越相关。rollbar是一个异常监控平台。Rollbar统计了2018年前端项目中排名前10的错误类型[12]：这里的很多错误都是空的或未定义的。如果使用TypeScript，可以轻松避免这些错误。使用TypeScript可以避免80%的相关错误，当然anyScript做不到。.此外，TypeScript的优势还不仅限于此，比如IDE的智能提示，项目维护更方便等等。如果您还没有使用过TS，现在是试用的好时机。Monorepo受欢迎程度：55%越来越多的项目包括vue、Reac、Babel等开始使用MonorepoMonorepo是指将所有代码放在一个代码仓库中的项目管理策略。Monorepos依赖管理的优点：共享依赖，所有代码都在一个仓库里。版本管理非常方便。代码复用：所有代码都在一个仓库，很容易将各个项目共享的业务组件或工具提取出来，通过TypeScript在代码中引用。一致性：所有代码都在一个仓库中，代码质量标准和统一风格会更容易。透明度：所有人都可以看到所有代码，从而更轻松地跨团队协作和做出贡献。Monorepos性能的劣势：随着代码越来越多，Git、IDE等工具会越来越卡。权限：管理文件权限将更具挑战性。Git目录没有内置的权限管理系统。整个项目无法区分哪些项目对某些部门开放，哪些项目对某些部门关闭。学习成本：对于新人来说，项目越大，学习成本越高。Monorepo绝对不是灵丹妙药，Monorepo策略并不完美，但在某些方面确实解决了一些项目的维护和开发体验。如果你的项目有多个关联仓库，或者还在使用子模块管理多个仓库，可以试试Monorepo。55%的包管理器使用非npm，剩下的45%不知道使用什么包管理工具。最重要的是没有锁文件。？第一代npmv1-v2会造成重复安装依赖。比如A依赖C，B也依赖C，这样的话C就会安装两次。（是安装了两次，不是下载了两次，会下载到本地缓存。）因为是树状结构，所以node_modules的嵌套层级太深（会造成文件路径太长的问题）module无法共享实例。例如，React有一些内部变量。React在两个不同的包中引入的不是同一个模块实例，所以内部变量无法共享，导致一些不可预知的bug。npmv3/yarn，从npm3和yarn开始，都是通过扁平化依赖来解决上面的问题。所有的依赖都被扁平化到node_modules目录下，不再有深层的嵌套关系。这样，在安装新包时，根据noderequire机制，会一直寻找上层的node_modules。如果找到相同版本的包，则不会重新安装，解决了重复安装大量包的问题，??依赖级别也不一样。太深了。但同时这也带来了一个新的ghostdependencies问题——项目中可以使用没有写在package.json中的包。C1.0.02.0.0package.jsonC1.0.02.0.0tilingreducedinstallation没有节省时间，因为算法，时间反而增加了。npmv5/yarn这个版本引入了一个锁文件来解决node_modules安装中的不确定性。这使您无论安装多少次都具有相同的node_modules结构。但是，分片算法的复杂性、幽灵依赖等问题仍未解决。yarnv2PnP重点在yarn2.x版本中推出即插即用（PnP）零安装模式，摒弃node_modules，保证依赖的可靠性，大大提升构建速度。yarn2.x摆脱了node_modules，安装和模块加载速度快；所有npm模块都将存储在全局缓存目录中，以避免多重依赖；严格模式下不会改进子依赖，也避免了幽灵依赖。但是自建的解析器处理了Node的require方法，脱离了现有的Node生态，兼容性不是很好。pnpmpnpm具有安装速度快、节省磁盘空间、安全性好的优点。它的出现也是为了解决npm和yarn存在的问题。1.pnpm通过结合硬链接和符号链接解决了yarn和npm的问题。硬链接：硬链接可以理解为源文件的一份副本，pnpm会将项目node_modules文件的硬链接存放在全局store中。硬链接可以让不同的项目从全局存储中找到相同的依赖，大大节省磁盘空间。软链接：软链接可以理解为快捷方式。pnpm在引用依赖时，会使用符号链接在对应的磁盘目录（.pnpm）下查找依赖地址。比如A依赖B，A下没有node_modules，而是一个软链接。实际的真实文件位于.pnpm中相应的A@1.0.0/node_modules/A目录中，并硬链接到全局存储。而B的依赖存在于.pnpm/B@1.0.0/node_modules/B。而A所依赖的B使用软链接链接到上述地址，即B\-->../../B@1.0.0/node_modules/Bnode_modules├──A-->。pnpm/A@1.0.0/node_modules/A└──.pnpm├──B@1.0.0│└──node_modules│└──B==>/B└──A@1.0.0└──node_modules├──B-->../../B@1.0.0/node_modules/B└──A==>/Acopycode-->代表软链接，==》代表hardlink，这种嵌套的node_modules结构的好处是只能访问实际在dependencies中的package，很好的解决了ghostdependencies的问题。另外，由于依赖始终是store目录下的硬链接，同一个依赖只会安装一次，多个依赖的问题也得到了解决。当然，pnpm也有一些局限性。pnpm-lock.yaml和package-lock.json不一致且不兼容。有些场景是不兼容的，比如Electron。不同应用的依赖硬链接到同一个文件，所以不能直接修改依赖文件，否则会影响其他项目。并且由于安装结构不同，原来的patch-package等工具已经不能用了。虽然还存在各种问题，但总的来说，瑕不掩瑜。其他ni可以理解为包管理器的manager，ni假设你使用了一个锁文件（你应该），在它运行之前，它会检测你的yarn.lock/pnpm-lock.yaml/package-lock.json来知道你当前包管理器，并运行相应的命令。cnpmcnpm与npm和yarn最大的区别在于生成的node_modules目录结构不同，在某些场景下可能会出现一些问题。另外，不会生成锁文件。但是cnpm保持了node_modules的目录结构清晰，可以说是在嵌套模式和扁平化模式之间找到了一个平衡点。很多面试会问pnpm为什么快，除了上面store保证全局只安装一次，还有软链接保证不会重复安装。还有一点，当安装同一个依赖的不同版本时，只会重新保存不同的部分。建议无论使用什么包管理工具，在版本更新时都必须添加锁文件来升级依赖。为了更好的安全性。esbuild流行度：89%esbuild是用go语言编写的javascript和typescript打包工具，比webpack快100多倍。虽然使用的打包工具不同，有vite、webpack、Rollup，但最终都是用esbuild打包。只有一个vuetify没用，但是vuetify还没正式发布，以后可能会改。未来ESM标准会越来越流行，相应的工具链也会越来越流行。严格来说vite并不是一个打包工具，而是一个前端构建工具。Vite其实是用Rollup和esbuild来打包的。SVGIcon流行度：55%关于IconFont的缺陷，你可以阅读这篇InlineSVGvsIconFonts[13]文章。主要有以下几个方面：浏览器将其视为文本进行抗锯齿优化，有时得到的效果并没有想象的那么锐利。特别是，不同系统下抗锯齿文本的不同算法可能导致显示效果不同。IconFontIconfont-sizeline-heightword-spacingIconCSSIconIconFontIconFontIconFontFontTTFWOFFEOT网络延迟会导致Icon先加载一个字符串。SVGIcon的优点是完全可以根据组件文档的描述离线使用，不需要从CDN下载字体文件，不会因为网络问题出现图标出现方形，不需要本地部署字体文件。SVG在低端设备上具有更好的清晰度。支持多色图标。对于内置图标的替换，可以提供更多的API，无需样式覆盖。SVGIcon的缺点，比如兼容性。（IE：What？）当然，一般来说，IconFont对性能的影响并不是那么大。也许这就是它不那么受欢迎的原因？CSS变量流行度：88%虽然还是用预处理语言来写，但最后都想办法转成CSSvar。性能方面，肯定是浏览器支持的W3C规范更好。但是，目前很多预处理语言的函数等功能并没有得到很好的原生支持。所以仍然需要预处理语言。好了，这就是本文的全部内容，感谢大家的观看。我是一个正在努力成长的前端菜鸟。