日常开吹:竹板这么一打,今天夸一夸,为什么我喜欢 Vue

2020-05-12 20:30:46 +08:00
 murmur

(写的太多,后面吹的我自己都乱了,见谅)

在回答这个问题之前,我们要明白一件事,什么需求选什么样的框架,所以我们先限定我们的范围,这个范围可以由下面四个问题回答:

1 、我的开发人员是什么素质,是几十万一年的专业前端还是后端兼任?

2 、我有没有移动端开发的需求,是什么架构,小程序、Native 、还是 Rn/Flutter/Weex ?

3 、我在开发什么东西,是复杂的 SPA 、内容展示系统还是企业应用?

4 、这个项目有多大,是几个人的小团队还是持续数年、百人以上参与的大工程?

如果你的答案满足以下几点,我想你会爱上 Vue:

1 、我们的团队前端都是一般水平的或者应届生,甚至是后端拉来凑数的

2 、我们的移动端使用 HTML5/小程序,或者不需要移动端

3 、我们的项目和 SPA 基本不搭边

4 、我们的项目基本不考虑后续维护,或者后续不会有大改动

好的,在开吹之前,我们需要一个高度的概括,为什么吹 Vue,那么我总结了我认为确切的四个字:以人为本。你可能问,这是什么屁话,开发人员不是人么?是的,因为真的有这种语言,典型的就是林檎的 Obj-C,这是典型的为了编译器爽而不管开发人员死活的东西。更通俗的话说是,把开发者当做用户,考虑用户从上手到开发的每一步,而不是把开发者当做掌握了大量知识的 GEEK 。

开源的世界里,互相借鉴是很正常的事,如果开源世界还有技术壁垒,那大家都不要进步了,现在的大开源软件哪个不是依赖了一堆基础库。站在巨人的脚步上,模仿成熟产品,这是个好事,像一个东西,减少用户的学习成本,同时加上一些特定场景的优化,这是个好事,而不是张口闭口的抄袭。还有拿国内外数据做对比的,是不是国内的开发者就不配做人,给国内开发者提供点适合的框架不好么,还要因为和国外的技术栈不一致而自卑?有人说 vue 的 star 数不实,是因为爱国给他刷的,那我真没法了,我认为程序员还是很理性的,evan u 也没必要去淘宝买星,至少 vue 的 star 数要比各种 awesome 的更有含金量,不是吗?

怎么吹 vue ?其实就从一点开始,前端在干什么?为了避免撕逼,我们来讨论狭义的前端,只讨论浏览器和套壳浏览器那部分。我们不讨论你跟其他语言抢饭碗的东西,别人用 unity 和 unreal 你要用 cocos-js,别人用 java 、php 你用 node 这些撕来撕去没意义,专业的事情就应该交给专业的来做。总结一点,前端是要把东西展示给人看的,无论是页面还是 App,无论你选择什么开发,HTML+CSS+JS 的组合你跑不掉,当然我看帖子有人高傲到要做 JS 工程师,那就没办法了。

其实,很多你做的东西并没有那么高大上,页面复杂不代表逻辑复杂,页面多也不代表复杂,你看上去的很多页面实际上在多年前就可以通过 iframe 划分搞定,这些页面之间没有数据交互,单纯的填写和展示而已。在这种情况下,HTML 的占比就很大,这在企业开发更加明显,大量的表单、表格,配合流程控制以及校验。这种情况,vue 的模板就非常有优势,模板的语法跟 HTML 基本没差别,又提供 v-if 、v-show 、v-for 等指令帮助前端的显隐。这个时候,第一批吹的该来了,说 jsx 和 js 是一样的,模板需要额外学习。是的,模板需要额外学习,但是值得学习,而且自然到不学就会了。几乎所有语言都有 if 和 for,所以 vue 就有 v-if 和 v-for ; at 这个符号有在...的意思,所以 at 可以绑定事件,冒号可以绑定变量,这个需要记忆,但是太简单了不记就住了。而在 jsx 里,你要循环必须用 map,我在项目中看到多少兼职开发连 array.join 都不知道,还在手写函数拼接字符串,你怎么让他们知道 map,知道 className,知道用短路、三目表达式运算实现 if 、if-else 。你可能会说,这些不是前端必修的么?对啊,但是 vue 可以不修,vue 的门槛就这么低。我们来看看学习 vue 从 jquery 一知半解到开始干活需要多久:

1 、掌握基本的 html 和 css 知识,这里需要多少取决于你要对现有框架做多大改动,很多企业开发是搭积木,他对 html 和 css 只掌握到“大概知道啥是啥”就可以,不要求能从 0 开始写一个组件或者一套布局,react 、angular 也需要这一步

2 、掌握基本的 js 语法,包括赋值、变量、变量、条件、循环,这里我没要求闭包和 this,因为我见过那些在每个函数之前都写上 var self=this,然后所有的 this 都用 self 代替的,这是个好主意,虽然很蠢但是在没有智能 IDE 的情况下对新手是个不错的东西。

3 、掌握 export 和 import 关键字的用法,即便是 es5 语法开发,这两个东西是避不掉的。

4 、掌握 v-if 、v-for 、v-show 、at 、冒号的使用,v-key 不是必须,在 vue 中基础 html 标签循环是不强制要 key 的。

5 、掌握 data 、computed 的用法,知道 data 中的变量和模板的绑定关系,其实 computed 都可以不用先学,但是不学这个模板里的行内表达式太丑,所以还是要懂一点。component 可以通过全局定义组件规避,mixin 是写在标准页面里的,粘过来就行。

好了,你会说,react 把 v-if 换成短路运算,v-for 换成 map 的不是一样么?这就要说 vue 第二个优势,本身就很精炼,api 长度的精炼,初高中级词汇,react 那是完美继承了 cocoa 又长又臭的命名策略,别人管咋的有 IDE 可以补全你 js 做不到完美啊。vue 的 api 在单词上都要比 react 简单,最基本开发时,基本的三段式任何组件都不能少,当然不改样式 style 段可以不要,template 段就是 html,代码部分直接 export 出一个 data 就可以了,是不是很简单,hooks 好但是不是刚需,前端这种 left-padding 、right-padding 都要用一个库的,现在想起一个组件一个文件麻烦,我信你个大头鬼哦。而且,template 部分堆多的时候,vue 因为循环和判断是直接写在指令里,不会破坏代码的美感,而 react 此时排版都成了问题,必须将大量代码剥离成函数才能保证可读性。最最重要的是,v-if 和 v-for 不需要学习,是可以轻松理解的,只要看到 if 和 for 两个单词,任何一个程序员都知道这是什么。

接下来我们来说 SPA 的事情,什么 SPA 适合 react 开发,我总结了一点,就是设计类软件,无论墨刀、PS 、office (字有位置有大小有颜色,也算半设计),这些软件界面层逻辑非常复杂,需要极致的优化,vue 因为帮你做了太多,没有暴露什么和渲染相关的钩子,所以是不适合的。但是,这并不能说明 vue 性能差,因为想保证良好性能第一点就是不要堆太多 dom 元素,也不要频繁重绘,这对任何框架都是一样的,而提升性能的最大地方,不是你用了什么框架,而是你说服用户从 IE 升级到 chrome,而这一步 360 却做出了很大的贡献,你要知道和别人说 chrome 别人直接蒙了,你让他装个 360 急速浏览器他一看“国产”欣然就给推下去了。我见过一个例子,说是开发了一个货船配重桌面 App,这正好是 vue 的例子,大量的表单填写、数据图表显示不代表复杂,恰恰需要模板的强大,就算放在对话框里他还是填写和展示,底层的逻辑是纯 js 的计算,不涉及什么状态。

然后我们说状态管理的事,vue 提供了一个官方的 vuex,你拿他做全局变量都可以,用起来太简单,甚至不用这个,你用事件一把梭都可以搞定。有人会说了,事件这么乱怎么维护,我们 jquery 过来的会怕这些么,更何况,有些事件就在父子组件之间传递,跨的层级多而已,没必要强求上一个 state,这个东西总结起来,就是用你喜欢、熟悉的,不必为了状态而状态。这里还要提一下 vue 的的响应机制,他通过 getter/setter 以及 array 、object 的函数劫持,不要求你强上不可变对象,这实际上也是减少了学习成本,我大概写了 2 年的 vue,因为不可变对象进坑就一次,那是因为我改了 state 里的东西,state 的监测看起来没有 data 里那么完善,也不像 data 我一次改很多,diff 下来没监测到改动的概率也不大。

很多人会提生态,没错,react 的核心竞争力就是 rn,但是这里的问题在于,rn 有多大竞争力,先不说 rn 里的 native 才是核心,就算 rn 也要踩 native 的坑,还要加上 rn 单独的坑,rn 是移动端代码,各大厂为了引流都在抛弃 wap,桌面和移动端因为操作方式和 UI 逻辑差距巨大,能复用的有限。更不要说,小程序占据了大量轻量级 app 的市场,flutter 还在打着性能和“未来”的旗号想占据 rn 的位置,我知道 rn 胜在入场早,成熟,很多 app 也没那么多苛刻要求,rn 的坑熟悉了就是 feature,但是的却众多因素影响下,rn 的竞争力也有限。而对于 UI 框架,无论 vue 和 react 都有成熟的框架可以用,真正的重头戏,包括企业级 datagrid 、企业级图表、对标 word 的富文本编辑器,都是和框架无关的纯 js 组件,更不要说美观的页面都是设计师做出来的,需要自己定制很多东西。

写到这里,我发现吹的太多,需要总结了。react 在给 vue 传教的时候,犯的一个最大错误就是总以为每个人都在开发高大上的东西,我们就是 HTML BOY,写的就是 CURD 的东西,企业开发和一些普通网站就是翻来覆去这些东西,es6 是你面试必学,但是对于一些场景真不是那么必要,尤其是对于后端来说,别人熟悉模板,模板是好东西不是负担,技术栈比你广多了,没必要要求别人学 es6,就包括说 TS 。是的,TS 作为强类型,可以提供工程化的很多特性,但是企业开发有他自己的开发方式,那就是照着模板页面抄,不去管为什么,因为跟别人像就可以过代码审查,大家就算 low 也是这个公司的编码风格,以后有个高人只要全文搜索就可以把这些地方改了。更何况,很多互联网项目,半年项目甚至公司都没了,你去谈维护、重构,是不是有点想太多。你可能会说,胆小鬼,不思进取,新特性不香么?我知道香,但是负责的说,任何的重构都是有代价需要背锅的,线上系统维护不变但是跑起来没问题,久经考验也是过来的,你去优化去重构,谁给你测试,出了问题你来负责么。有人说 vue 用户在管中窥豹,对不起啊,我的需求就是养猫而已,真没有那么高大上。vue 的下载量和 star 数也证明了这一点,小程序的很多框架也是 vue 语法,说明 vue 在国内的适用性没那么糟糕么。

你问我为啥不说 ng,我用的 ng 还是最早 1,开发 app 选型时是 ng2,tree-shaking 都是测试特性,直接配环境给我配吐了。水平有限不评论了,但是 ng 也是有模板的,而且是*ng-for,还比 vue 长一个字母,不知道 react 开发者怎么评论呢。

11119 次点击
所在节点    程序员
139 条回复
rain0002009
2020-05-12 20:58:18 +08:00
别的咱不说 nuxt 是真好用 想用 ssr 就 ssr,不用 ssr 还可以预渲染,预渲染也不用直接 spa 也可以
目录分的很明确
相比之下 next 就显得有点简陋了(太自由?)
rioshikelong121
2020-05-12 20:58:38 +08:00
我觉得其实 ng 是不是对于新手更友好一些 这就是 framework 对于 library 的优势 前期学习曲线比较陡峭 但是框架绑定的那一套对于大部分场景都是最佳实践。避免了自己面对一大堆第三方方案一脸懵逼的场景。
LokiSharp
2020-05-12 21:05:01 +08:00
Vue 用起来太折腾 Angular 只要学本身就行 Vue 得学一堆乱七八糟的
Justin13
2020-05-12 21:06:16 +08:00
我没用过 VUE,一直用的 React,入门后接触的第一个框架,慢慢的了解到背后的函数式,然后一发不可收拾,自学 haskell, 再读 SICP 。不客气的说,React 改变了我的编程生涯。
这一路前端写过来,看着 React 步步前行,从 fiber 到 hook,不变的是背后的函数式理念,这也是我最认同的。
至于前端三大框架,各有优劣短长,有适合的场景,也有短缺的能力,其实没必要硬拉着比个高低。
对于我个人来说,能让人写着代码,感到愉悦的,就是好框架。
murmur
2020-05-12 21:10:32 +08:00
@rioshikelong121 前期陡峭就是劝退啊,工期紧工作量大,根本不给别人学习的时间,vue 也是官方全家桶啊
@LokiSharp vue 哪里比 angular 折腾了,可以说出来讨论一下,angular 一样有模板吧,概念可是比 angular 多多了,不能说 angular 一个命令行生成 3 个文件自己帮你全局注册就叫不折腾
@Justin13 我们在学校学的 java 也好,c 也罢,都不是函数式的写法,所以不习惯函数式编程也很正常
LokiSharp
2020-05-12 21:18:47 +08:00
@murmur #5 vuejs 发请求不用另外学 axios 之类的库了么?你要说 vuejs 简单,嘛确实简单,本身就是渐进式(指没有实现完整的功能)框架(自称)。对了,Vue 的这些概念都是 鱿鱼须在 Google AngularJS 团队实习(毕业前实践)的时候抄过来的。
Justin13
2020-05-12 21:19:03 +08:00
@murmur 我也是先接触的 c++和 java,虽然只是选修。但是学了函数式以后,反而对面相对象有了更好的理解,两者都是对系统,问题的抽象,只不过是抽象的方式不一样罢了。同样在看设计模式,无非是对常见问题的抽象模板罢了,思想都是共通的。
并不是说学了函数式就必须抛弃面向对象,两者并不对立,至于真正工作中写代码的偏向,取决于实际项目和技术团队。
zhuangzhuang1988
2020-05-12 21:26:05 +08:00
@Justin13
啥事函数式?
"背后的函数式理念" ??
啥理念?
murmur
2020-05-12 21:27:35 +08:00
@LokiSharp 抄还是借鉴,看关于开源互相借鉴的理解,这里不再赘述,google 有一个跳出来喷 Evan u 的好像已经被开除了
然后说没实现完整功能的,你说的好像是 react
AdamChrist
2020-05-12 21:32:55 +08:00
使用 VUE 中有两个疑惑,希望楼主解答一下.
1.CRUD 的界面,有个几个 modal,是用 this.$refs.model.show()的方式,还是使用传 props 的形式控制?
ref 的形式简单好用,但是感觉不符合规范,props 的形式麻烦,但是感觉是对的方式。
2.vuex 的中获取到了表单数据,一般直接绑定到 form 上面,但是这样双向绑定,违背了数据流的思想。好处是简单,实际使用起来也没遇到什么坑。所以一直没有什么其他方法改正这个问题。
murmur
2020-05-12 21:45:35 +08:00
@AdamChrist

都可以,规范也好思想也罢都是人定的,何必盲目照搬所谓先进理念,在 jquery 年代啥理念都没有一样可以开发大项目,现在有了框架还能让理念憋死不?
第二点你可以跳过 vuex,直接在方法里获取数据然后对 data 赋值,data 绑定了表单,这就是最 vue 的写法,vuex 这部分本身就是可选,你看这样不就不纠结了,不涉及全局共享的东西非得抽到 vuex 里总感觉有点多余,本身就没几行代码
LokiSharp
2020-05-12 21:54:07 +08:00
@murmur #9 我没用过 React 我只知道宣传上 React 是 Library 而 Vue 是 Framework (自称)
gz911122
2020-05-12 21:58:46 +08:00
后端程序员觉得楼主说的挺对的....
AdamChrist
2020-05-12 22:19:56 +08:00
@murmur #11 我现在的做法跟你说的一样。只是这个疑问一直困扰着我,没有找到好的答案。
longjiahui
2020-05-12 22:42:14 +08:00
@AdamChrist 双向绑定是指 v-model 吗? v-model 是个语法糖?其实也是单项数据流吧。就是响应了 @input 事件而已啊?
LokiSharp
2020-05-12 22:42:16 +08:00
@murmur #9 说个我之前项目尝试用 Vue 用到的问题吧,这个问题每次碰到 Vue 粉我都会问一次来确定现在 Vue 是否可用。

我之前有个项目的需求是要做 5 种语言的 i18n,翻译是外包的。一般他们是用 SDL 之类的专业软件,我们只要提供支持的文件就行了。
这个项目复杂度不高,当时初步技术选型是打算尝试用 Vue,Vue 本身并未提供任何 i18n 功能,只能选 vue-i18n 。做出一个 DEMO 准备开始着手 i18n 的时候,按照惯例应该导出翻译源文件丢给外包。问题来了,vue-i18n 就没提供任何导出工具。文档也是里的用法是十分诡异的建立一个包含多种语言的 VueI18n 对象(见下方代码)。当时我就惊了,这个作者真的参与过真正的 i18n 项目开发么?常规的 i18n 都是类似于 Qt 这样提供一个工具能从源码中分析生成一个带有源码位置以及上下文信息的 po 或者其他格式的翻译源文件文件,想要添加另一种语言只需要翻译完编译成对应的翻译文件就行了,不需要动源码。而 Vue-i18n 从文档来看,是写死在源码里的,得修改每个文件的源码。

https://kazupon.github.io/vue-i18n/zh/guide/formatting.html#%E8%87%AA%E5%AE%9A%E4%B9%89%E6%A0%BC%E5%BC%8F

`
const i18n = new VueI18n({
locale: 'en-US',
formatter: new CustomFormatter(/* 这里是构造函数选项 */),
messages: {
'en-US': {
// ...
},
// ...
}
})
`
之后我考虑了几种方案:
1. 自己实现一个 i18n 插件(想想就不现实)
2. 实现一个自动从源码提取并生成 VueI18n 对象的工具(想想就不靠谱)
3. 用 Angular 重写

当然 Vue 也有可能有其他更好的 i18n 插件,可 vue-i18n 这个名字一眼看上去像是官方项目而且作者是 vuejs core team 成员。

不过这件事让我开始怀疑 Vue 所谓生态系统的可靠性。如果你看 Awesome Vue, 没问题,有很多开源项目用 Vue 也有很多库。但是仔细想想这些东西有几个能上生产环境用的?一个 i18n 库看起来像是没参与过软件 i18n 工作的人,甚至他的主页也只支持 3 种语言(英语、简体中文、俄语)。我不禁怀疑起来,其他所谓的开源库又是什么人写得呢?

嘛,当然最后我从我认识的用 Vue 的朋友那边了解到。。。他们只是用 Vue 而已 Vue 那些生态还不如自己写得好。。。临时写个 DEMO 还行真要用一堆坑。

而 Angular 提供了基本可用的工程化的 i18n 功能,不用纠结,看着文档做就是了 https://angular.io/guide/i18n

当然这是几年前的情况现在最新的 VueTS 3 不知道有没有考虑到这些?
longjiahui
2020-05-12 22:44:42 +08:00
@AdamChrist 第一个问题 假如有共性,可以将 modal 抽出来做成公共的插件 js 调用也挺好的。像 elementui 里的那样,挂到 vue.prototype 里去。如果是特殊的 modal 就做 props 也不麻烦吧。
murmur
2020-05-12 22:58:56 +08:00
@LokiSharp

这就是最简单的 i18n 啊,真正的 i18n 因为 politics 、文化的差异,都要重新做的,内容都不一样,简单的 i18n 就是给个英文根据查表换成不同的语言
i18n 做复杂没用,又不是自动翻译系统,真的开发也是先打表后开发的,你能指望程序员第一次写的时候不出错么,肯定是做原型的时候就设计好各种语言,语言不同文字也不同长度换行都有考究,怎么可能代码都做完了才考虑这些
murmur
2020-05-12 23:00:47 +08:00
按照惯例应该导出翻译源文件丢给外包,根据项目代码抽取字符串表,我当然知道,这还是以前 vc6 年代做汉化的玩法,不管三七二十一对着字符串表就一顿改,但是 js 这么灵活的语言,你怎么知道你写的东西是代码的一部分还是界面上的字符串
eaglewudi
2020-05-12 23:07:01 +08:00
整天瞎几把搞,我对前端的认知还停留在 jQuery
/狗头

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/671052

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX