首页 文章 精选 留言 我的

精选列表

搜索[主数据管理],共10006篇文章
优秀的个人博客,低调大师

主打一个“小巧灵动”:Vite + Svelte

作者:来自 vivo 互联网大前端团队- Wei Xing 在研发小型项目时,传统的 Vue、React 显得太“笨重”。本文主要针对开发小型项目的场景,谈谈 Vite+Svelte 是如何让项目变得“小巧灵动”,并横向对比 Svelte 和 Vue 的性能表现,对二者的加载流程做详细分析。 一、背景 为了统一技术标准、提升协作效率,通常在前端团队内部只会保留一套通用的研发框架。尤其是在团队初创时期,团队成员会考虑易用性、社区活跃程度、学习成本等因素,选择一个合适的研发框架并一直推行和使用下去。 国内的前端团队比较青睐 Vue和 React,我们团队内部的主要研发框架也是 Vue,包括组件库、工具库、脚手架等等,都是围绕 Vue 展开来做研发。 坚持使用一个技术栈虽然让团队协作变得高效,也不用重复“造轮子”,同时提升了人员“流通性”,有它不可忽略的优势。但没有任何一款框架是“银弹”,例如 Vue,它的通用性很好,但在某些特殊场景下,我们会有更好的选择。 例如,当我们在开发一些小型项目时,会发现至少有两个明显的问题: 框架太“重”了:通常一个小型项目只由少数几个简单页面构成,如果使用 Vue 或者 React 这些框架来研发的话,有点“大材小用”了。构建的产物中包含了不少框架运行时代码(虚拟 DOM、响应式、状态管理等),这些代码对于小型项目而言是冗余的,它们影响了包体大小,进而影响页面的启动速度和执行性能。 打包太慢了:以 Vue CLI 为例,它的底层基于 Webpack,虽然 Webpack 具备更强大的功能和灵活性,但相比于 Vite、Esbuild 这些以速度为标杆的构建工具来说,它的速度确实慢了一些,影响了研发效率。 面对这两个问题,我们似乎有更好的技术方案可选:使用更轻量的 Vite + Svelte。本文就是针对开发小型项目的场景,谈谈 Vite+Svelte 是如何让项目变得“小巧灵动”。 注意:本篇所有针对 Svelte 的性能观点,都是基于小型项目这个前提下提出。事实上,随着项目规模的增长, Svelte 的性能、包体大小优势会逐渐减小,甚至不如 Vue 或 React,详情可参考尤雨溪尤大本人针对 Svelte 和 Vue3的包体大小问题的分析。 理论上在普通 CSR 项目中,组件数量超过19个时, Svelte 就失去了它的包体大小优势。 二、Vite 和 Svelte 简介 先了解下 Vite 和 Svelte。 2.1 Vite Vite 是尤雨溪尤大写的一款高效的前端构建工具,相比于 Webpack,它最大的优势就是“快”。 在开发环境下,Vite 使用高性能的 Esbuild 来进行预构建,并利用现代浏览器对 ESM 的支持,直接将预构建好的ES模块丢给浏览器进行解析执行,无需在每次变更代码时都重新编译代码,具有更快的冷启动速度和热更新效率。 在生产环境下,Vite 基于 Rollup 进行打包,Rollup 同样支持 ESM 语法,并且具有更快速高效的 Treeshaking,一般情况下,Rollup 具有更小的包体大小和更快的构建速度。 参考 github 上的构建工具横向对比 benchmark。 (图片来源:https://github.com) 可以看到无论是冷启动、热更新还是生产环境打包,Vite 都是优于 Webpack 的。尤其是在开发过程中的热更新很快,大大优化了开发体验。 彩蛋提醒 我们为大家准备了抽奖福利,请继续阅读下去。 2.2 Svelte Svelte 是由 Rollup 的作者 Rich Harris(前端轮子哥) 写的一款前端框架。在语法上,Svelte 和 Vue 类似。它和传统框架(如 Vue、React)的最大差异就在于:在构建阶段,Svelte 就将代码编译为“纯粹”的 JavaScript 代码,几乎没有运行时。 这意味着在小型项目中,它打出来的包更小,在运行时,它也不需要复杂的状态管理和虚拟 DOM,在性能上的表现也更好。 在前端大佬 Jacek Schae 的前端框架横向测评中(测评简述:使用各个前端框架来编写同一个标准 App - RealWorld,并横向对比它们的表现),可以看到,Svelte 无论是在首屏渲染速度、包体大小还是代码行数上都展现了较大的优势,全部跻身前三。 首屏渲染速度: (图片来源:https://medium.com) 包体大小: (图片来源:https://medium.com) 代码行数: (图片来源:https://medium.com) 三、搭建 Vite+Svelte 项目 在基本了解了 Vite 和 Svelte 之后,来看看如何着手去搭建一个 Vite+Svelte 的项目。 3.1全局安装 Vite 通过 npm 全局安装 Vite: npm install vite -g 2.2 创建 Svelte 项目 Vite 原生支持直接通过脚手架创建 Svelte 项目,执行以下命令: npm create vite@latest 命令行中会出现引导,按照提示输入项目的名称并直接选择 Svelte 框架即可。 ✔ Project name: vite-svelte-demo? Select a framework: › - Use arrow-keys. Return to submit. Vanilla Vue React Preact Lit❯ Svelte Solid Qwik Others? Select a variant: › - Use arrow-keys. Return to submit. TypeScript❯ JavaScript SvelteKit ↗ 左右滑动查看完整代码 3.3运行项目 通过以下命令运行项目: cd vite-svelte-demonpm installnpm run dev 这样一来,整个 Vite + Svelte 的项目结构就搭建好了,开箱即用。整个项目的目录结构如下: |-node_modules -- 项目依赖|-public -- 公共文件 |--vite.svg |-src -- 源文件 |-assets |-lib |--App.svelte -- 项目根组件 |--app.css -- 项目根样式 |--main.js -- 项目入口文件|--.gitignore |-- index.html -- 首页index.html|-- package-lock.json |-- package.json |-- tsconfig.json |-- svelte.config.js -- svelte配置文件|-- vite.config.js -- vite配置文件 左右滑动查看完整代码 可以看到,整个项目结构基本和 Vue 类似,只是组件的后缀名改为了.svelte,新增了 vite.config.js 和 svelte.config.js 两个配置文件。 3.4 配置 Vite+Svelte 支持开箱即用,项目的初始配置也很简单,没有任何额外配置。 vite.config.js:用于配置 Vite 构建工具的行为,例如入口文件、输出目录、插件、devServer 等。 // vite.config.jsimport { defineConfig } from 'vite'import { svelte } from '@sveltejs/vite-plugin-svelte'export default defineConfig({ plugins: [svelte()],}) 左右滑动查看完整代码 svelte.config.js:用于配置 Svelte 项目的各种选项,例如别名、预处理器、插件等。 // svelte.config.jsimport { vitePreprocess } from '@sveltejs/vite-plugin-svelte'export default { preprocess: vitePreprocess(),} 左右滑动查看完整代码 在工程配置这里,唯一需要注意的是,Vite 默认情况打出的包体仅支持现代浏览器(支持 ESM ),如果要兼容低版本浏览器,可以使用官方提供的 @vitejs/plugin-legacy插件: // vite.config.jsimport { defineConfig } from "vite";import { svelte } from "@sveltejs/vite-plugin-svelte";import legacy from "@vitejs/plugin-legacy";export default defineConfig({ plugins: [ svelte(), legacy({ // 设置需要兼容的目标浏览器版本 targets: [ "Android >= 4.4", "iOS >= 9", "ie >= 11", "not Android < 4.4", "not iOS < 9", "not ie < 11", ], additionalLegacyPolyfills: ["regenerator-runtime/runtime"], renderLegacyChunks: true, }),}); 左右滑动查看完整代码 更多配置项可参考官网的 Vite 配置文档和 Svelte 配置文档。 四、开发体验优化 项目搭建完成后,后续就是根据业务需求来开发 Svelte 组件和完善业务逻辑。整个开发过程中,体验感还是不错的。 详细的开发流程不再赘述,想要了解更多关于 Vite 和 Svelte 内容,可以参考 Vite 官方文档和 Svelte 官方文档。这里我们主要来看看 Vite 和 Svelte 分别在开发体验上带来的一些优化。 4.1Vite 的开发体验太棒了 首先,Vite 的开发体验太棒了。它的构建速度极快,对开发效率有很明显的提升。 在开发环境下,Webpack 每次都需要对改动的部分进行重新编译打包,耗时几秒钟,而 Vite 则不需要重新打包,只需要把更新后的 ESM 代码交付给浏览器就ok,几乎是即时更新。 同时在构建生产环境包时,也明显比原先的 Vue 项目要快了近50%。别小看这一点速度的提升,让整个开发体验好了不少。 4.2Svelte 的语法更优雅? 如果你跟随上面步骤搭建了项目,那你可以打开项目中的 Counter.svelte 文件看看,会发现 Svelte 组件的基本结构和 Vue 几乎一致,也是由 script、template 和 style 三部分组成,唯一的差异在于 Svelte 中不需要像 Vue 一样额外使用来作为 DOM 结构的根标签。 <script> let count = 0 const increment = () => { count += 1 }</script><button on:click={increment}> count is {count}</button><style> ...</style> 左右滑动查看完整代码 在语法上,Svelte 和 Vue 也非常相似,但个人更喜欢 Svelte 的一些简洁的语法设计,举一些例子: 插值表达式:Svelte 的插值表达式只需要单个{},而 Vue 则需要两层{{}},并且 Svelte 还有一些简写语法,例如 src={src} 可以简写为 {src}。 // Svelte的插值表达式<div {src}> count is {count}</<div>// Vue的插值表达式<template> <div :src="src"> count is {{ count }} </div></template> 响应式:Svelte 声明的变量直接支持响应式,而在 Vue 中则需要使用 ref 来声明。 // Sveltelet message = 'Svelte';// Vueimport { ref } from 'vue';const message = ref('Vue'); computed 计算属性 / watch 监听:Svelte 的$: 代码块类似于 Vue 的 computed 计算属性和 watch 状态监听的结合体。 // Svelte的计算属性$: info = name + age// Svelte的监听let val$: { console.log(`你输入的内容是: ${val}`);}// Vue的计算属性import { computed } from 'vue';const info = computed(() => { return name + age});// Vue的监听import { watch } from 'vue';let val = ref(''); watch(val, (newValue, oldValue) => { console.log(`你输入的内容是: ${val}`);}); 左右滑动查看完整代码 虽然差异没有很大,但这些简洁的语法,至少让我个人感觉写项目时更流畅,体验感很不错。 这些就是 Vite 和 Svelte 带来的开发体验上的一些优化。 五、Svelte 和 Vue 性能对比 上面我们了解了如何搭建 Vite+Svelte 项目,并感受到 Vite 和 Svelte 带来的开发体验优化。那接下来看看这套方案在实际项目中的性能表现。 为了对比 Svelte 和 Vue 之间的性能差异,我特地找了一个小型项目进行改造,用 Svelte 对它重写,并通过 ABTest 进行线上的性能数据对比。 5.1 首先,来看打包之后的 bundle 大小对比 Vue 的包体: Svelte 的包体: 是否压缩 Vue Svelte 差值 gzip 前 360K 207K 降低 42.5% gzip 后 124K 77K 降低 38% 可以看到 Svelte 相比于 Vue,在包体大小上确实优化了不少,基本在40%左右,效果很明显。 5.2其次,看看本地的启动速度(FCP)对比 在本地进行10次平均性能测试,发现 Svelte 的 FCP 指标比 Vue 要快了约46%,说明 Svelte 的首屏渲染速度比 Vue 快了不少,提升很明显。 _ Vue Svelte FCP(ms) 1128 738 FCP(ms) 1897 545 FCP(ms) 990 701 FCP(ms) 1016 608 FCP(ms) 1002 620 FCP(ms) 1391 587 FCP(ms) 1294 662 FCP(ms) 983 803 FCP(ms) 1231 618 FCP(ms) 1279 757 FCP 均值(ms) 1234.7 663.9 优化程度(%) - 46.2% ↑ 下面这个录屏是对比两个页面首次打开时的效果,左侧为 Svelte,右侧为 Vue。 5.3最后,看看线上的启动速度数据对比 我们通过 ABTest 进行线上的启动速度数据对比,在投放了1周后,数据结论如下: _ 平均启动速度 vue 2493 ms svelte 2132 ms 差值 361 ms 优化程度 14.5% ↑ 以看到 Svelte 在线上的启动速度表现也比 Vue 要快一些,优化程度约为14.5%。 注意:这里的平均启动速度指标是我们团队内部定义的页面启动速度指标,计算方式:业务启动速度 = 页面加载完成时间 - 页面入口点击时间。由于我们是在客户端 App 中进行测试,因此该时间包含了客户端 webview 的启动时间。所以实际上 Svelte 对前端部分的启动速度优化程度可能会更高,参考前面的 FCP 指标的本地测试结果。 总之,对于小型项目,Svelte 在包体大小和启动速度上还是有不少提升的,如果你的项目对启动速度有强要求,也可以尝试使用 Svelte 来开发或改造,应该会有不错的效果。 六、Svelte 比 Vue 快在哪? 通过上面的数据分析,虽然我们了解到 Svelte 在构建小型项目时确实有更快的页面启动速度,但具体快在哪,还需要进一步深入分析。 我们可以通过 Chrome 的 devtool 来观察 Svelte 和 Vue 两者打包后的页面在加载流程上的差异。 Vue 页面加载流程: Svelte 页面加载流程: 对比二者的加载流程,可以看到耗时上有两个主要的差异点: 耗时差异 Vue Svelte JS Bundle 加载时间 627 ms 274 ms Html/JS 解析耗时 292 + 148 + 85 = 525ms 290 ms 因此,在小型项目中,Svelte 相比于 Vue,有两个明显的优势: 资源加载更快:由于包体较小,所以加载首屏 JS Bundle 时网络耗时更短。 Html/JS解析执行更快:由于 Svelte 几乎无运行时,因此在执行相同业务逻辑时,解析执行耗时更短。并且在解析执行过程中,没有二次加载更多的首屏 JS、CSS 资源,因此整体的解析执行速度更快。 七、总结 总之,对于小型项目而言,Vite + Svelte 这对组合还是很不错的,既提升了开发效率,又优化了页面性能,更加“小巧灵动”。而且这两者的学习曲线都比较缓和,基本在2-3天内就可以完成学习加一个简单项目的改造。 一点题外话,很多时候大家会低估“技术尝新”的重要性,我们被困在团队圈定的“技术穹顶”中,永远用一个“套路”去实现所有业务,这会让我们感到疲乏、缺乏价值感和动力,甚至影响工作的投入程度,久而久之,整个团队也会在技术上变得迟滞。 所以在有机会时,要尽量合理地发掘和尝试新的技术方案,一方面是让自己保持技术活力,另一方面也是在加强团队的技术沉淀。 END 粉丝福利 vivo互联网技术为开发者朋友们提供了 iQOO & NBA 联名款周边(各1个),快来领取吧! ✦ ✦ ✦ iQOO x NBA 联名洗漱包 x1 iQOO x NBA 联名运动水杯 x1 参与方法: 转发本篇内容到朋友圈,截图保存界面,再到vivo互联网技术微信后台发送“v爱技术”参与抽奖,上传截图即可。(请保留朋友圈分享链接至开奖当天) 开奖时间:2024年12月27日 20:00 奖品将通过邮寄发放,中奖者需在5天内提供收货信息。(联系本号后台) 注意: 1.我们将会通过人工审核截图进行校对。未及时提供收货信息或未完成所有步骤的参与者将视为自动放弃。 2. 活动解释权归vivo互联网技术所有。 猜你喜欢 1.一次基于AST的大规模代码迁移实践 2.前端生成海报图技术选型与问题解决 3.基于 Three.js 的 3D 模型加载优化 本文分享自微信公众号 - vivo互联网技术(vivoVMIC)。 如有侵权,请联系 support@oschina.cn 删除。 本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

优秀的个人博客,低调大师

【争做优秀博主】大话MySQL之爱恨情仇

在数据库的发展过程中,安全-->稳定-->高效-->低成本四个有序的要点一直如影随形,后者离开前者就是空谈。10月19日晚上MySQL发布了8.0.22版本,其中一个新功能(Automatic connection failover for Async Replication Channels)引起我的注意,也很感兴趣,作为一个DBA老兵,百感交集,在过去的20多年,故障切换功能一直是三方后娘工具在主导,是几代DBA的痛,互联网最流行的数据库,在这块一直为人诟病。此功能还没有测试,不管如何,至少在这块官方终于开始出手解决了。夜深人静,整理了一下思路,对于MySQL产品截至目前的发展情况,做了一下总结,基本走以下几个方向发展:1、主从同步方向:异步同步到半同步,在到增强半同步,再到组复制;走同步的安全策略,到提升同步的效率,走单线程复制到并行复制,致力于降低主从延迟问题,但相对的同步绝对的延迟伴随其发展全过程至今。2、性能优化方向:多线程,线程池(原版MySQL的企业版支持,社区版不支持);各种日志各种独立,截止8.0.22版本,保证安全与问题记录的日志基本全部独立了,可以动态调整参数单独控制关闭和打开;重构核心引擎Innodb,优化各种锁,独立锁,优化事务操作等。各种的一顿骚操作优化,使得最新版的MySQL性能也达到了前所未有的高度。3、多模数据库方向:关系型数据、JSON半结构化数据、对象数据、内存型以及全文检索引擎等等多个数据引擎,走支持OLTP业务开始拓展至OLAP业务(Oracle云上支持的Analytics Service),虽然只有它自己的云上支持。4、借鉴其他数据库方向:最大的借鉴为ORACLE数据库,现在的各种语法和一些用法越来越ORACLE了;借鉴了MongoDB的一些功能,如MIC中的相关设置、自动搭建从节点的克隆功能等,不过在使用中确实有点复杂。5、智能化运维方向:支持各类在线DDL,对业务几乎无感知,这个为以后智能自助动态优化索引打下坚实的基础;重点的性能参数差不多都支持在线修改;支持持久化动态调整参数,保证重启后参数与重启前一致;关闭MySQL时可以把内存的热数据持久化到硬盘,启动时重新由硬盘加载到内存,减少了数据库预热,使数据库重启后快速进入之前的战时状态;SQL语句的重写功能,不变更业务代码情况下重写SQL;可以支持根据硬件配置,启动时自动调整部分参数配置,虽然可自动调整的参数有限,结合前几项,为未来MySQL在智能参数调优与自我优化方面、自治数据库的发展奠定了基础。6、提升安全性方向:健全的日志,保证在各种异常状态下不丢失数据,这也是数据库最基本的要求,MySQL也一直在努力增强再增强,努力打造金融级数据库;增强的用户验证方式caching_sha2_password,强化认证模式,增加用户认证串被暴力破解的难度。但最大的安全功能failove却一直没有。7、降低成本方向:这个路线进度有点慢,目前在innodb的压缩上有所发力,压缩比有所改进;在增强用户使用体验,简化使用操作等人力成本上一直在努力,不过有些操作比较畸形,操作配置使用复杂,比如MySQL innodb cluster的配置。固然MySQL深受广大人民喜爱,装机量也很大,其本身也特别优秀,但爱之深恨之切,依然有许多不足:1、自动创建从节点:组复制刚自动增加新节点竟然必须要有数据库初始化开始全部的Binlog日志才行(感觉设计这个方案的产品脑仁有点小),否则就需要使用mysqldump手动搞定,至今增加新节点的操作依然很骚,依然不方便,操作依然复杂,反观MongoDB就简单多了,不管是操作还是运维成本都很低。2、故障切换:MySQL经过20多年的发展,至今故障切换依然依赖三方工具,故障自愈方面好好改进一下,不过至今为止,不是很理想。其实在MySQL的JDBC中很早就类似MongoDB支持链接多数据库多节点配置,但是自身没有故障自动检测和切换功能,这个功能一直是个摆设。MySQL8.0.22版本终于支持故障启动切换,走配置参数来看,节操碎一地,估计差MongoDB的这个功能不是一星半点。期待官方在这块投入更多的人力物力,使MySQL结束这种原始操作状态,提升一下运维人员SLA和业务的不可用时间。3、drop table/database删除操作的优化:目前删除大表和库的时候对数据库性能影响巨大,甚至能把数据库给干挂了。4、假删除或延时删除库表,做数据库的删除回收站,给数据库定制后悔药。5、MySQL的MySQL Innodb Cluster目前是个鸡肋,估计也没啥人用,router和shell组件完全可以集成进MySQL中,组件越多运维等成本越高,这种管理模式用中间件不也挺好,还能私人订制(毕竟修改中间件的成本没有MySQL源码的高),配置管理复杂,向MongoDB复制集看齐不香嘛?6、不务正业:每个产品都有其核心竞争力,MySQL现在的产品有忘记初心(安全、稳定、高效、低成本)的嫌疑,花活太多,想做的东西太多,想要参考其他数据库功能也很多,all database in MySQL行的通嘛?真的能一统数据库江湖唯吾独尊嘛?传说中的MySQL存储与计算分离官方是否会支持?数据库的存储与计算分离架构这两年很火,这也是数据库发展的一个方向,一方面硬件技术的进步,支持弹性伸缩,合理利用资源,降低成本,二来高并发大数据量的业务需求,特别是万物皆为云的当下,这种架构的出现确实应时应景。MySQL如果支持这种架构,必然要对MySQL-Innodb的存储引擎做大量的修改,而且还要有自己对应的分布式文件系统,当前的MySQL架构可能要做大量的调整。MySQL官方为了进一步降低主从同步延迟,可能会支持物理复制来优化延迟问题。至于存储与计算分离个人感觉官方不会支持,至少在在短时间内不会支持,也许在MySQL13中会支持,因为我河南老乡王守义说过十三香^-^集多种数据库优点之大成,不忘初心,海乃百川,有容乃大,感觉MySQL还是不够包容和开放。很多现成的成功案例和方案思路,借鉴过来即可,何况官方的研发人员也是全球顶级的,咋就学不会呢?很多事情咱也看不懂,咱也不知道,咱也不敢问,谁知道哪,说不定明天一觉醒来MySQL来个华丽转身,穿个新娘妆跑步进入智能化、自治化数据库时代呢?

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册