日常开吹:竹板这么一打,今天夸一夸,为什么我喜欢 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 开发者怎么评论呢。

11552 次点击
所在节点    程序员
139 条回复
murmur
2020-05-13 09:47:48 +08:00
@guolaopi 这本身就是 https://v2ex.com/t/670771 的联动,没必要搞的那么严谨跟写论文一样

为什么我在 i2ex 这么 WTF,因为果粉跟你讨论的时候带了太多假设

1 、我不差钱
2 、软件不花钱,能网盘的都网盘,能拼车的绝不自己买正版
3 、生产力不谈性价比

你都钱不当钱了,我还怎么跟你理性讨论,是不是
guolaopi
2020-05-13 09:52:58 +08:00
@murmur
那你要非这么说的话我想起原来一句话,
“你打不赢傻逼,因为他们会把你拉到跟他们同一层次,然后用他们的经验打败你”
真喷起来你不一定喷得过人家,经验在那摆着,干嘛拉低自己。
祝好
speculatorA
2020-05-13 09:58:39 +08:00
@guolaopi 评论大概过了一遍,说不上撕逼吧?算环境较好的辩论贴了。
speculatorA
2020-05-13 09:59:18 +08:00
@guolaopi 到时你一进来就开始阴阳怪气了,帖子就是这样烂的。
murmur
2020-05-13 10:03:29 +08:00
@guolaopi 哈哈,我知道,但是撕逼本身就是消遣的一部分,跟刷快手和抖音一样的,现在很少有国内纯讨论技术的东西,搜索引擎太牛逼了,能搜的都搜到搜不到的问也问不到,所以才给我们这些无聊的人提供了写长文开撕的地方。

我在这和果粉对喷,别人在知乎编故事,他在微博制造谣言,大家都有充实的生活
jinzhongyuan
2020-05-13 10:04:11 +08:00
求求你做个人吧
guolaopi
2020-05-13 10:09:06 +08:00
@speculatorA
#63 那可能你对“撕逼”定义的门槛比较高。
#64 楼主都没看出来阴阳怪气你从哪看出来的阴阳怪气,可能你对“阴阳怪气”定义的门槛又比较低吧。
guolaopi
2020-05-13 10:10:04 +08:00
@murmur
倒也是,不然摸鱼往哪摸,难道要我去刷抖音吗(滑稽
marcong95
2020-05-13 10:19:47 +08:00
@LokiSharp #21 看到你说传统软件的 i18n 是提取程序内的文本交给翻译翻译的,就不奇怪 B 站某知名 up 主玩的迫击炮是怎么来的了。一个海外游戏公司,旗下游戏大量出现研钵( mortar )这个道具,中文翻译迫击炮,反正已经成梗了。虽然这个并不完全是 i18n 流程的锅。只是很奇怪,软件、游戏这种可能大量出现单独一个单词或者词组,文本上不能体现上下文的,真的适合把文本提取出来翻译吗?

虽然没正是用过,vue-i18n 的逻辑应该是前端开发的时候就已经把占位符写到代码里,而不是把原文本 hard code,然后再替换占位符。这种形式好像 android 开发也是这样要求的?
LokiSharp
2020-05-13 10:35:14 +08:00
@marcong95 #69
qt 之类的成熟的框架用 gettext 之类提取的文本注释带有源码位置信息的,可以是体现上下文的。
Artifex Mundi 翻译质量问题不是流程的锅,他们的作品本来就是小品级的节约成本不花钱做校对很正常。
wensonsmith
2020-05-13 10:41:07 +08:00
吹得好!

React 大道至简,但是保持简约就不一定简单了,要实现高级功能就必须什么高阶组件、三目运算、Hooks 等等

还是不习惯 html 混合着 js 写,有种被当年 jquery 去拼接 html 的支配的恐惧。。
longjiahui
2020-05-13 10:44:25 +08:00
@AdamChrist 假如写成组件,除了事件以外,props 要写在 data 里的 难道不就只有一个 visible 吗 ? 剩下的就是动态的 内容,这些本来也存在 data 里了。不会臃肿啊。
zicla
2020-05-13 10:47:39 +08:00
君子和而不同,自己用得爽就行了!
AdamChrist
2020-05-13 10:52:53 +08:00
@longjiahui #72 一个业务模块,可能有几个弹窗(dialog),那么就要写多个 visible,这看起来已经很不好.而且如果里面的内容需要初始化,或者再次获取,还需要给 ID 或者 formData 之类的.当然弹窗肯定不是指简简单单的提示,而是包含的一些用户操作在里面.没有办法做成通用的.
lancelock
2020-05-13 11:22:19 +08:00
我开始接触这两个框架的时候,也是觉得 vue 简单直白,react 有点反直觉,主要之前用过 ng1,模板的那套做法比较熟悉

后来写 react 的时候发现,我可以完全不需要了解很多 api,用 js 自由发挥,只要 js 的语法没问题,结果就能给你正确的渲染出来
总之,js 的表达能力有多强 react 的表达能力就有多强,所以越写越顺手了

当然 vue 我不是很熟悉,就不多发表意见了。反正我也不做后端了,自己业余写前端项目还是喜欢 react + hooks

总之你的观点我倒是赞同,对于后端来说写前端 vue 接受起来比较容易。不过如果是专职前端的话,总得深入研究下 js 、es6 吧,毕竟以后一直要吃这碗饭的。
calanlot
2020-05-13 11:25:45 +08:00
三个框架都用过,ng 的路由和表单的封装开箱即用非常强大,相对坑的是懒加载(目前 Ivy 正在解决的),和 ng template 的类型丢失。能用 ng 我肯定是不会用 vue 了
zthxxx
2020-05-13 11:33:10 +08:00
@murmur #37 不是在表达我的观点,只是在试图总结楼主发的内容

第 4 点这里说的不是代码的「抽象程度」而是在总结你表达的 「对整个工具链路的工程化、自动化没有任何追求」甚至觉得多余


「真的只是把编程当成混口饭吃的技能而已,对编程,对计算机毫无兴趣的」

通篇适用对象就很像隔壁帖子 t/670747 中如上描述的情况
murmur
2020-05-13 11:39:37 +08:00
@zthxxx vue 除了因为没官方支持 ts,因为 es 特性不支持强类型,其余的不影响你自动化,vue 有 cli,可以用 webpack 打包,可以懒加载、分模块打包,想和 jenkins 自动化构建也是可以的

至于你说什么测试,能把自己写的代码按后端标准覆盖一遍的有多少,前端的单元测试基本没用,界面级的测试多难做大家心里都清楚

所以什么叫混口饭,你说说 react 哪里在工程化上高人一等?
ChanKc
2020-05-13 11:43:26 +08:00
@LokiSharp 我也是非常不喜欢 vue-i18n 。除了你说的原因,还有一点就是 vue-i18n 似乎是把组件当成上下文来用。比如 A.vue 的 i18n 中的 key 可以和 B.vue 的 i18n 中的 key 完全一样,区别仅仅是分属于不同组件。这样对于翻译者来说需要理解 Vue 当中的组件的含义,我觉得对非技术人员来说不太友好。

另外我猜测,如果不使用 vue-i18n 的 v-t directive 用法,用到 i18n 信息的地方都是 reactive 的,也就是在 dom diffing 的时候会被纳入计算,可能会对渲染性能有影响。

我个人觉得目前 i18n 做得比较好的 Vue 项目是 Gitlab,https://gitlab.com/gitlab-org/gitlab-foss 。它们就是用了 gettext 风格的翻译,可以自动提取信息到翻译平台上翻译。翻译完了信息可以回写到翻译文件上。另一个我比较喜欢的 i18n 方案是 https://github.com/Demivan/fluent-vue

另外现在的前端 i18n 方案大都是:浏览器加载了各种基础的 js 文件,js 说我要用某种语言,此时再 lazy load 我要的语言文件然后进行翻译的渲染。我在访问一些国外的网站时就出现过语言文件加载不出来,然后页面上完全无法正确显示的情况。比如我本来预期看到的是“用户名”和“密码”,结果出现的是“{username}”,“{password}”这样的你所说的占位符。所以我在尝试另一种思路:在 Vue“编译”.vue 文件之前对.vue 文件“预处理”,将所有的“占位符“替换成翻译好的信息,再交由 vue-loader 处理,最后出来的组件和页面就是已经经过“本地化”的了。这个做法更接近于 l10n 而不是 i18
n 。如果用户不经常切换语言,我想这样做会体验更好,但是代码编写的灵活性会下降,打包时间也会变长。https://github.com/tychenjiajun/jeanrry-loader 就是这样的一个尝试。
zthxxx
2020-05-13 11:46:39 +08:00
@murmur #37 基于这些总结,我并不否认面向楼主你说的这些人群 vue 确实是适用

楼主面向的这类群体或情况都是确实存在的,不同的情况需要不同的解决方案是个很自然的论点,

我也很佩服楼主的表达能力,能很清楚的都说出来 (相信要不是知乎控评,你肯定会去知乎对线了


大部分人在「争吵」的根本矛盾都在于 想把自己喜欢的一种框架 / 一种方案安利给所有人,而缺少考虑是否符合目标受众

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

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

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

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

© 2021 V2EX