DCloud助力,Vue官网有免费中文视频教程了!

Vue官网,是广大前端开发者学习Vue.js最重要的阵地。官网上有详细的文档、及部分视频教程。但之前这些视频都是英文的,对国内开发者的入门学习不太友好。

为了让更多开发者低门槛进入vue生态,DCloud与Vue官方合作,全新录制Vue中文视频教程,现已正式上线并更新到Vue官网,供大家免费观看学习。

更细致的是,在很多API文档旁,都提供了这个API对应视频讲解的链接。

该系列视频免费、且没有广告

除了观看视频讲解外,学习者还可点击右上角按钮,使用HBuilderX打开课程源码亲自动手编码,更深入的掌握Vue.js的具体用法。

在HBuilderX中可以方便的对Vue的语法进行代码提示转到定义,能在代码助手右侧看到API的详细文档链接。


通过HBuilderX右上角的预览,开发者可以实时了解自己代码的运行情况,还可以查看logdebug打断点。


Vue.js是我们中国人创造的世界级前端框架,在国内,它已经远远超过reactangular。下图为今年的百度指数对比:

欢迎广大开发者积极拥抱Vue,共同促进生态的繁荣发展!

​

uni-app 2.2发布,大幅优化H5端性能体验

背景

uni-app发布以来,已经服务了几十万开发者。让我们意外,或者说惊喜的是,有大量开发者用uni-app只编写H5版,并没有多端发布(可参考案例)。

这其实也符合uni-app的初衷,uni-app的定位并不是需要多端发布时才用uni-appuni-app是一个使用vue.js开发所有前端应用的统一框架。对于一个前端工程师来说,使用uni-app做多端效率更高,做单一端也没问题,并在各端有不少出彩的地方。

过去的版本迭代中,uni-app已经成为了更好的小程序开发框架,比使用原生微信开发更有优势。(见评测

uni-app2.2的新版中,我们大幅优化了H5版的性能,让使用uni-app开发的H5,性能体验和直接使用vue.js开发H5拉齐。

可能不少开发者有某种误解:多端框架要适配多端,所以性能肯定不如原生。我们想纠正一下:
1. 切忌想当然,多看数据评测。还不信就自己动手实验
2. 请问使用vue.js开发的web性能好,还是使用原生js开发web性能好?答案是:使用vue.js框架。为什么?因为它在底层会自动优化数据同步、虚拟dom,比大多数开发手动写的代码要更高效。同样的,使用uni-app也如此,框架底层的优化处理比大多数开发者手动写setdata或dom操作更高效。
3. 多端适配很多是在编译时做的,并不影响运行时的性能

优化难点

想优化H5端的性能,并不是一件容易的事。

“功能全面”和“小巧极速”,这是一对最难调和的冤家。

为了保障多端的一致性,uni-app实现了一套小程序的H5版Runtime,支持各种小程序的组件、API、配置。所以uni-app的H5版拥有比其他框架更好的跨端一致性。

但这也造成了老版的uni-app,输出H5端时,包体积过大(框架未压缩前有500k,部署gzip后162k)。

这确实是一个非常大的runtime,包含了几十个内置组件,数百个API。而且这些API仍然在快速增加中。

不能像其他框架一样因为功能少,所以体积小。我们不会用功能换性能,我们需要更好的方案。

优化方法

uni-app包含几十个内置组件、数百个API,是个“大而全”的框架;但开发者在开发具体应用时,未必能使用到所有的组件及API。若能根据项目具体情况,删掉没用到的组件及API,保留对项目有用的组件及API,便可精简框架、减少体积,这即是“摇树优化”的思路。

摇树优化(Tree-Shaking),顾名思义,摇晃树干,将枯死无用的枝条摇掉,仅保留有用的树枝。对应到框架层面理解,就是一个框架的众多组件和API,可以按需使用,把未引用的框架部分裁剪掉。Tree-Shaking 最早由 Rollup 提出,属于死码删除的一种形式。

常见的前端框架摇树,一般是基于明确的import引用关系。比如引用某UI库时,在A页面使用该UI库的search组件,此时需要写js代码import这个search组件,那么摇树分析就很容易。

uni-app和小程序一样,内置组件和API是不需要import的,这提升了开发的易用性,但此时却加大了摇树的难度,依靠简单的import分析无法实现摇树了。

幸好对DCloud团队而言,AST语法分析是看家本事,多年来HBuilder以js和vue语法提示著称。通过AST分析,uni-app新版可以精准判定这个项目使用了哪些组件和API。

不过这还不够,分析工程源码使用了什么组件和API之后,还得考虑框架各组件和API之间可能存在依赖和耦合关系,这需要进一步的计算和关系梳理,具体而言:

  • 组件:通过vue-template-compiler分析出来的AST,映射生成项目中使用到的组件清单,然后再基于Webpack插件将使用到的组件打包构建
  • API:编译器维护一个 api 依赖关系的 json 文件,该 json 文件描述每个 api 可能依赖的文件,然后 babel 查找到对应的 api 后,根据api 的依赖关系自动导入,重新编译

在工程师持续的加班奋战后,uni-app终于推出了全新的2.2版本,解决了这些难题,大幅降低了发行包体积,gzip后的框架体积,从162k降低到92k,仅相当于你在工程中引用了vue.jsvue-router、以及部分es6 polyfill库。(后续有详细比较)

除了大幅降低发行包体积,新版还调整了预载策略,可以进一步加快页面的渲染速度。

优化结果

搭建环境

我们使用vue-cli创建uni-app默认模板

vue create -p dcloudio/uni-preset-vue my-project

项目创建后,编译生成H5端的发行目录

npm run build:h5

然后配置nginx服务器,指定root目录并启用gzip压缩,示例如下:

server {
    ...
    gzip on;
    gzip_min_length 1k;
    gzip_buffers 4 16k;
    gzip_comp_level 4;
    gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;
    ...
}

runtime 动态裁剪

然后通过 Chrome DevTools 的 Network 面板,查看优化前的首页网络请求包大小,结果如下:

然后启用H5平台的优化开关,重新查看首页的网络请求包大小,结果如下:

可以看到框架主库(chunk-vendors.js)从162k变为92.8k,体积压缩43%!

实际上,框架主库主要分为三个部分:

  • vue/vue-router基础库
  • es6 polyfill库
  • uni-app runtime(组件&API实现)

如果对这三个部分再拆开对比,我们会看到uni-app组件库优化比例更高:

vue/vue-router es6 polyfill库 uni-app runtime 累计
优化前 38k 43k 81k 162k
优化后 38k 26k 28.8k 92.8k

Tips:

  • uni-app runtime从81k瘦身为28.8k,裁剪比例达到64%
  • 新编译器对es6的使用也做了动态扫描,项目中用到的es6语法(包括uni-app runtime用到的es6语法),才会打包对应的polyfill实现,故es6 polyfill库从43k瘦身为26k

脚本执行时间

然后,我们再通过Chrome DevTools 的 Performance 面板,查看优化前后的性能数据,对比结果如下:

可以看出,最耗时的脚本执行时间,从227ms提升为154ms,时间提升达到32%。

如何使用

虽然内部实现比较复杂,但uni-app对外暴漏了简单的配置,开发者只需在配置文件中打开一个开关即可。具体在 manifest.json 中h5节点配置如下选项:

"h5" : {
    "optimization":{
        "treeShaking":{
            "enable":true //启用摇树优化
        }
    }
}

2.2版的其他优化

uni-app2.2版中,还开放了package.jsonvue-config.js的自定义,开发者可以自由的配置编译策略。

现在可以自定义支持所有小程序平台,包括钉钉小程序、高德小程序、抖音小程序…等。这样除了标准的8大平台(iOS、Android、H5、微信小程序、支付宝小程序、百度小程序、头条小程序、QQ小程序),这些生态的子生态也可以分版本条件编译。

同样,也支持对H5端进行多子端编译,比如微信里的内嵌的H5、App里内嵌的H5…都可以分开条件编译。

如此灵活的条件编译,对于一套工程的多端发布、共享复用、同步升级,有莫大的好处。即便是仅开发H5版,uni-app的多端条件编译也提供了更灵活和强大的工程化能力。

2.2版本还可以设置各种静态资源、js、小程序自定义组件的编译和拷贝策略。如果你之前的h5项目或小程序项目想转换至uni-app下,又不想挪动某些目录结构,那么在vue-config.js里配置策略即可。

使用uni-app开发H5和直接开发H5相比的优势

在与直接开发h5拉齐性能的基础之上,uni-app给开发者提供了更多优势:

  1. 开发效率
    uni-app提供了大量适合手机页面的基础组件(其实就是小程序组件)。还提供了扩展组件uni ui。插件市场更有600多款插件。

无论开发者想找一个电商的模板,还是找一个图表组件,都可以手到擒来。开发效率更胜以往。

  1. 多端编译
    我们开发H5时,经常需要给浏览器输出一份、给微信等超级App输出一份、给自家的App输出一份。甚至不同地域、不同用户画像,都会输出不同版本。以前,开发者只能对js部分进行条件编译,甚至不得不建多个仓库进行多版维护。

uni-app解决了这些烦恼,它的条件编译非常灵活强大:
– 不管是组件、js还是css,都可以按平台编译输出
– 还可以多个平台进行“与和或”的运算编译
– 除了文件中的代码,整个文件、甚至整个目录,都可以条件编译

例如微信、QQ等在支持x5内核的内置浏览器中,使用x5的视频同层渲染;或者在微信服务号中调用微信卡劵,这段代码只有build到 dist/h5-weixin 这个目录下的版本才会被编译进去,其他平台不会有这段代码

// #ifdef H5-WEIXIN
wx.openCard({
    cardList: [{
        cardId: '',
        code: ''
    }]// 需要打开的卡券列表
});
// #endif

后续计划

接下来,uni-app在H5端将提供服务端渲染机制(SSR)和PC宽屏界面适配优化,在追求性能极致和大一统的道路上继续前进!

相关代码全部托管在 github,欢迎大家 star 或提交 pr!

Vue 和 React 的优点分别是什么? – 尤雨溪的回答

作者:尤雨溪
链接:https://www.zhihu.com/question/301860721/answer/545031906

这个问题下面的很多回答太偏激了,其实我淡出知乎就是因为这类破事… 但是作为作者还是认真地说一说吧,希望能以后别再有这种问题了。

这里我可以大方地承认,如果多年以后要论历史地位,React 肯定是高于 Vue 的。事实上,我作为一个开发者,也是由衷地佩服 Jordan Walke, Sebastian Markbage 这样的,能从开发模式层面上提出突破性的新方向的人。

React 从一开始的定位就是提出 UI 开发的新思路。当年 Pete Hunt 最开始推广 React 的时候的一句口号就叫 “Rethinking Best Practices”,这样的定位使得 React 打开了一些全新的思路,吸引了一群喜欢折腾的早期核心用户,并在这个基础上通过社区迭代孵化出了许多今天被 React 开发者当作常识的 pattern。这是 React 伟大的地方,Vue 里面也有很多地方是直接受到了 React 的启发。React 敢做这样的尝试,是因为它是 Facebook。这样的体量的公司,在 infrastructure 层面获得质的提升,收益是巨大的,而且 Facebook 的工程师们足够聪明又要靠工资吃饭,改变他/她们的习惯并不是什么问题。而对外推广,则是一种大公司才有的 “改变业界” 的底气。

Vue 从一开始的定位就是尽可能的降低前端开发的门槛,让更多的人能够更快地上手开发。我以前也说过,开发 Vue 的初衷不是为了搞个大新闻,只是做了个我自己用得舒服的框架。我虽然也在 Google 这样的大公司呆过,但骨子里是一个喜欢自由的人,也一直觉得独立开发者很酷(这也是为什么最终自己也成了一个独立开发者)。很多时候我更希望自己做的东西能帮到那些中小型企业和个人开发者。举个例子来说,美国传统行业里有很多 small business,它们不像大公司那样有专门的 IT 团队来信息化整个流程,很多只能雇一个普通的 contractor 程序员,有些甚至是老板自己兼职研究代码。我收到过好几封这样的感谢信,说因为 Vue 让它们多快好省地做了个内部应用,解决了实际问题,这样的故事是让我觉得特别爽的。

做 React 这样的不迎合用户,而是试图改变用户的设计需要有足够的本钱:你得有足够的资源和背景去强行越过初始推广的那个陡坡。事实上,如果没有 Facebook 作为 React 的推广者,React 很可能最终是一个有着忠实用户群体的小众框架(比如 Elm)。作为一个个人项目的 Vue 没有这样的宣传资源,也并不是为了改变用户。所以从设计的角度上来说,Vue 首先考虑的是假设用户只掌握了 web 基础知识 (HTML, CSS, JS) 的情况下,如何能够最快理解和上手,实现一个看得见摸得着的应用。

一个 API 看得顺不顺眼,用得舒不舒服,很大程度上取决于你跟一个技术的核心用户群体的重合程度。编程语言之间喷来喷去还少么?大家都是图灵完备,然而此之蜜糖,彼之砒霜。Vue 的 API 设计固然有可以商榷的地方,但 React 也不是完美无瑕,不然也不会从 mixins 到 HOC 到 render props 一次次地折腾,更没有 hooks 什么事了。直到 Suspense 出现前,也不存在什么只有 React 才能做到的事情(顺带一提,有意思的是 hooks 基本上废掉了过去大部分基于组件的逻辑抽象模式,抹掉了 JSX vs. 模版的一个优势,也完全可以用在其他框架里,连 Angular 都已经有对应的原型实现…)然而 “不完美” 并没有妨碍在过去的几年内大量的用户用各自选择的技术做出实际的产品 —— 从 State of JS 近两年的数据来看,两者的满意率是差不多的,都在 90% 出头,说明两者在 “满足目标用户的需求” 这个衡量标准下,表现是差不多的。可维护性、可读性、优雅程度、生态这些东西嘴上怎么辩都可以,还是数据比较实在。

再说说具体技术层面:从加载速度、运行时性能来说,两者目前综合各种场景应该说是没有什么质的差别。硬要说的话,Vue 在 update 性能优化方面需要的心智负担可能少那么一点 —— React 如果不注意,容易导致过多的组件无用 diff,但是实际上真正会遇到性能瓶颈的应用也是少数… Vue 3 会比 Vue 2 快不少,加上模版编译还有一些可进一步发掘的优化空间,所以性能上会比现在的 React 有一定优势,但 React 那边也在研究基于 prepack 的编译时优化,这个也是挺值得期待的。Vue 3 对于 TS 的支持会有很大改善(包括 TSX),我们也在计划对模版做更好的 IDE 支持(比如补全、类型检查),现在没有不代表以后不能有,有批评我们改进就是了。其实过去大半年 Vue 本身没有什么大更新是因为精力都放在工具链上了,接下来又要回到核心上了。React 那边 time slicing / Concurrent mode 要明年 Q2 才稳定,那个时候应该 Vue 3 的 time slicing 应该也稳定了(原型已实现)。Suspense 在 data-fetching 稳定之前并没什么大用(要 2019 年中),这期间我们也会研究解决同类问题的方案。所以从纯技术层面来说,React 现在比 Vue 牛逼么?不好说。以后一定比 Vue 牛逼么?也不好说。

使用数量方面,有很多文章拿各种数据来比较,有的是 GitHub stars,有的是 npm 下载量,有的是 Google trends,有的是 StackOverflow 的问题数量… 其实这些数据都有很明显的问题,那就是它们跟实际使用者的数量并不一定是正比,会受到其它因素的影响,比如 GitHub stars 跟实际使用没有直接关联;使用者中使用 CI 的比例会影响 npm 的下载量;Google trends 很难完美过滤掉 React 这样的常见词汇的 false positive;文档和本身的上手难易程度会影响 StackOverflow 的问题数量,等等… 所以我自己一直是以 Chrome 开发者插件的使用者数量作为一个比较可靠的数据,因为它的关联度是最直接的,潜在的干扰因素也是最少的。目前 Vue 的开发者插件用户数量约为 70.4 万,而 React 是 136.3 万,大致可以作为参考。React 的使用量还是有明显优势,不过这个数字比起两年前已经很不一样了 —— 那时候大约是 1:7 的比例。从增速来看,Vue 是要快一些的。

说了这么多,无非是希望大家能停下来想想所谓的 ”A 技术比 B 技术牛逼“ 背后到底是在争些什么,我们使用这些技术的初衷又是什么。很多时候你说这方面,他说那方面,鸡同鸭讲,即使说到一起去,也往往缺乏对等的信息量或者基础共识,只是各自表达主观看法,最后变成两个阵营各自抱团取暖… 说到底,就算你证明了 A 比 B 牛逼,也不意味着你或者你的项目就牛逼了… 比起争这个,不如多想想怎么让自己变得更牛逼吧。