内容简介：vueconf杂谈
一句话概括vue的发展就是：革命形势一片大好。
不过尤雨溪解释了一个重要的概念： 渐进式框架 。
其实渐进式可以理解为扩展迭代式，看看vue的发展过程就很好理解了：
Declarative Rendering 这里应该是指的借鉴的angular数据绑定特性 => Component System 和react同时期提出组件化的概念 => Client-Side Routing 最初的vue只关注视图层，可是构建webapp路由是必不可少的，所以vue官方吸收了第三方的vue-router => Large Scale State Management 组件过多，层级过多，这时候组件之间的通信就成了问题，所以在大型项目中使用的状态管理方案vuex也被吸收了 => Build System 脚手架工具vue-cli快速搭建vue项目 => Client-Server Data Persistence 应该指的服务端渲染做性能优化吧
不断地吸收优秀的第三方插件，由前端代码本身扩展到构建 工具 和后端。
小结：vue的发展方式其实也是我觉得对于前端开发者来说比较好的成长方式：以html、js、css为基础，不断学习和吸收优秀的第三方框架，然后利用构建工具提升开发效率，前端开发效率达到一定程度后通过nodejs向后端延伸。
vue的方向
- 优化服务端渲染，利用浏览器link标签的rel=”preload/prefetch”特性做异步加载
- 对异步组件的改进，感觉有点像 big pipe data，组件的逐步渲染？
- 函数式组件改进，编写组件代码更简洁
- 整合typescript，加强VSCode支持
- vue-cli的优化，包括可配置化、可组合以及PWA支持
小结：从前看到后，vue的发展路线相当“猥琐”，和其它热门的框架相比，总是能做到一种“你有什么我都有（weex,virtual dom,data binding,cli…），而且还比你简洁。好吧，这也是我比较看好vue的一个原因。
vue与后端
vue的服务端渲染离不开node.js服务器，一提到node.js服务器可聊的就比较多了。
结合i5ting和阴明的分享来看，vue的SSR技术在实现上是有一定工作量的，访问量较大的情况下还需要对服务端利用缓存进行性能优化。而其中提到的利用node.js服务器做API Proxy没有详细说具体实现，只是阐明其价值和作用。
这一块之前恰好有所了解，目前比较成熟的支持mock功能的API服务器有国外的swagger和国内的RAP。
swagger虽然界面美观，但使用yaml格式文件配置API，不是太友好。搭建起来也不算简单，测试的话生成对应的后端代码去执行（像单元测试一样）。
RAP支持mock和随机数据，但是没有测试功能。
所以我当时编写的开源项目( api-document api-mock )就是想解决易用性、mock数据支持、可测试性的问题。
小结：其实我比较关注的是技术的细节和成本，因为SSR、前后端同构这些技术虽然新潮也能提升前端性能，可是考虑到搭建到维护所消耗的人力成本，很可能大多数中小型前端团队都不适合。这就好比开惯了捷达的人想要速度更快，给他换辆保时捷当然可以提速，但是把购买成本、使用成本和工资收入对比，这种方法肯定不现实。所以我希望看到的是布道者们能告诉我们如何降低这些技术的学习成本、使用成本、维护成本。就像vue把vue-cli吸收进官方，能让大家更快速地搭建vue项目那样。
vue与前端
vue的纵向扩展可以延伸到node服务端，而横向扩展则可至android和ios，利用weex。
其实还可以扩展到微信小程序，用 wepy 。
当然这种扩展是有损的，不能做到三端完全一致和功能完全支持，毕竟底层的东西还是有区别。
小结：就像react native想一统前端一样，weex也在做差不多的事情，一处编写，各端运行。可这种实现方式无论从开发发布还是性能效果上，都不如内嵌webview的混合应用或者webapp来得简单直接，所以无爱~
总结
曾经有同学问我怎么看vue和angular，我当时的评价是“青出于蓝而胜于蓝”。
一个没有背靠大公司的开源框架能发展如今之势确实是很了不起的~赞一个
感谢vueconf大会上各位分享者为前端技术做出的贡献~
作者：亚里士朱德 博客： http://yalishizhude.github.io
以上所述就是小编给大家介绍的《vueconf杂谈》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
