这是一个创建于 1685 天前的主题，其中的信息可能已经有所发展或是发生改变。
(写的太多，后面吹的我自己都乱了，见谅)
在回答这个问题之前，我们要明白一件事，什么需求选什么样的框架，所以我们先限定我们的范围，这个范围可以由下面四个问题回答：
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 开发者怎么评论呢。
 |
1
rain0002009 2020-05-12 20:58:18 +08:00
别的咱不说 nuxt 是真好用 想用 ssr 就 ssr，不用 ssr 还可以预渲染，预渲染也不用直接 spa 也可以
目录分的很明确 相比之下 next 就显得有点简陋了（太自由？） |
 |
2
rioshikelong121 2020-05-12 20:58:38 +08:00  1
我觉得其实 ng 是不是对于新手更友好一些 这就是 framework 对于 library 的优势 前期学习曲线比较陡峭 但是框架绑定的那一套对于大部分场景都是最佳实践。避免了自己面对一大堆第三方方案一脸懵逼的场景。
|
 |
3
LokiSharp 2020-05-12 21:05:01 +08:00 1
Vue 用起来太折腾 Angular 只要学本身就行 Vue 得学一堆乱七八糟的
|
 |
4
Justin13 2020-05-12 21:06:16 +08:00 via Android 3
我没用过 VUE，一直用的 React，入门后接触的第一个框架，慢慢的了解到背后的函数式，然后一发不可收拾，自学 haskell, 再读 SICP 。不客气的说，React 改变了我的编程生涯。
这一路前端写过来，看着 React 步步前行，从 fiber 到 hook，不变的是背后的函数式理念，这也是我最认同的。 至于前端三大框架，各有优劣短长，有适合的场景，也有短缺的能力，其实没必要硬拉着比个高低。 对于我个人来说，能让人写着代码，感到愉悦的，就是好框架。 |
 |
5
murmur OP @rioshikelong121 前期陡峭就是劝退啊，工期紧工作量大，根本不给别人学习的时间，vue 也是官方全家桶啊
@LokiSharp vue 哪里比 angular 折腾了，可以说出来讨论一下，angular 一样有模板吧，概念可是比 angular 多多了，不能说 angular 一个命令行生成 3 个文件自己帮你全局注册就叫不折腾 @Justin13 我们在学校学的 java 也好，c 也罢，都不是函数式的写法，所以不习惯函数式编程也很正常 |
|
6
LokiSharp 2020-05-12 21:18:47 +08:00
@murmur #5 vuejs 发请求不用另外学 axios 之类的库了么？你要说 vuejs 简单，嘛确实简单，本身就是渐进式（指没有实现完整的功能）框架（自称）。对了，Vue 的这些概念都是 鱿鱼须在 Google AngularJS 团队实习（毕业前实践）的时候抄过来的。
|
|
7
Justin13 2020-05-12 21:19:03 +08:00 via Android
@murmur 我也是先接触的 c++和 java，虽然只是选修。但是学了函数式以后，反而对面相对象有了更好的理解，两者都是对系统，问题的抽象，只不过是抽象的方式不一样罢了。同样在看设计模式，无非是对常见问题的抽象模板罢了，思想都是共通的。
并不是说学了函数式就必须抛弃面向对象，两者并不对立，至于真正工作中写代码的偏向，取决于实际项目和技术团队。 |
 |
8
zhuangzhuang1988 2020-05-12 21:26:05 +08:00
|
|
9
murmur OP @LokiSharp 抄还是借鉴，看关于开源互相借鉴的理解，这里不再赘述，google 有一个跳出来喷 Evan u 的好像已经被开除了
然后说没实现完整功能的，你说的好像是 react |
 |
10
AdamChrist 2020-05-12 21:32:55 +08:00
使用 VUE 中有两个疑惑，希望楼主解答一下.
1.CRUD 的界面，有个几个 modal，是用 this.$refs.model.show()的方式，还是使用传 props 的形式控制？ ref 的形式简单好用，但是感觉不符合规范，props 的形式麻烦，但是感觉是对的方式。 2.vuex 的中获取到了表单数据，一般直接绑定到 form 上面，但是这样双向绑定，违背了数据流的思想。好处是简单，实际使用起来也没遇到什么坑。所以一直没有什么其他方法改正这个问题。 |
|
11
murmur OP @AdamChrist
都可以，规范也好思想也罢都是人定的，何必盲目照搬所谓先进理念，在 jquery 年代啥理念都没有一样可以开发大项目，现在有了框架还能让理念憋死不？ 第二点你可以跳过 vuex，直接在方法里获取数据然后对 data 赋值，data 绑定了表单，这就是最 vue 的写法，vuex 这部分本身就是可选，你看这样不就不纠结了，不涉及全局共享的东西非得抽到 vuex 里总感觉有点多余，本身就没几行代码 |
|
12
LokiSharp 2020-05-12 21:54:07 +08:00
@murmur #9 我没用过 React 我只知道宣传上 React 是 Library 而 Vue 是 Framework （自称）
|
 |
13
gz911122 2020-05-12 21:58:46 +08:00
后端程序员觉得楼主说的挺对的....
|
|
14
AdamChrist 2020-05-12 22:19:56 +08:00
|
 |
15
longjiahui 2020-05-12 22:42:14 +08:00
@AdamChrist 双向绑定是指 v-model 吗？ v-model 是个语法糖？其实也是单项数据流吧。就是响应了 @input 事件而已啊？
|
|
16
LokiSharp 2020-05-12 22:42:16 +08:00 3
@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 不知道有没有考虑到这些？ |
|
17
longjiahui 2020-05-12 22:44:42 +08:00
@AdamChrist 第一个问题 假如有共性，可以将 modal 抽出来做成公共的插件 js 调用也挺好的。像 elementui 里的那样，挂到 vue.prototype 里去。如果是特殊的 modal 就做 props 也不麻烦吧。
|
|
18
murmur OP @LokiSharp
这就是最简单的 i18n 啊，真正的 i18n 因为 politics 、文化的差异，都要重新做的，内容都不一样，简单的 i18n 就是给个英文根据查表换成不同的语言 i18n 做复杂没用，又不是自动翻译系统，真的开发也是先打表后开发的，你能指望程序员第一次写的时候不出错么，肯定是做原型的时候就设计好各种语言，语言不同文字也不同长度换行都有考究，怎么可能代码都做完了才考虑这些 |
|
19
murmur OP 按照惯例应该导出翻译源文件丢给外包，根据项目代码抽取字符串表，我当然知道，这还是以前 vc6 年代做汉化的玩法，不管三七二十一对着字符串表就一顿改，但是 js 这么灵活的语言，你怎么知道你写的东西是代码的一部分还是界面上的字符串
|
 |
20
eaglewudi 2020-05-12 23:07:01 +08:00 via iPhone 2
整天瞎几把搞，我对前端的认知还停留在 jQuery
/狗头 |
|
21
LokiSharp 2020-05-12 23:09:04 +08:00
@murmur #18 你用过 wordpress 或者写过 Qt C# 之类功能完备框架的 i18n 么？通常情况都是代码里标一个占位符，框架本身提供一个分析提取源码占位符生成 po 、xml 、csv 之类的翻译源文件方便提供给翻译的。翻译文件与源码分离，改变语言只需要添加对应的翻译文件，修改语言参数。嘛，确实是查表替换，而 vue-i18n 呢，硬编码一个包含翻译信息的对象进去？！
https://developer.wordpress.org/themes/functionality/internationalization/ https://doc.qt.io/qt-5/internationalization.html https://docs.microsoft.com/zh-cn/aspnet/core/fundamentals/localization?view=aspnetcore-3.1 |
|
22
murmur OP @LokiSharp 顺便说一下一个 i18n 库自己不做 i18n 的原因
1 、按很多人的说法，英语是必修的，vue 中文文档做的好点都成了可以狂吹的优点（我把他给漏了），更何况用的比中文少的 2 、日文属于放弃治疗的那种，他的造词法和习惯已经无法承载爆炸的科技词汇了，大量的科技词汇都是假名直写，写英文可能还好懂点 3 、韩语属于用的少人还矫情的那种，中文虽然游戏审查司马，但是大众没那么矫情，我偶然间看了 mybatis 还是啥的文档，按照韩语的要求，mybatis 必须用韩文注音写成卖八踢撕，不能写英文 |
|
23
LokiSharp 2020-05-12 23:17:02 +08:00
@murmur #19
vc6 时代的汉化玩法？？？请你告诉我这个时代该怎么玩，硬编码到代码上每个语言编译一份二进制文件？ 字符串该不该翻译和语言有什么关系需要翻译的字符串都是有专门的占位符标注的。 你这两句话暴露了可能是一小部分 Vue 用户普遍的情况，只参与过前端项目开发。 |
|
24
murmur OP @LokiSharp
你要说硬编码也没办法，不过所谓的硬编码可以单独抽出一个 module 导入，这不就 i18n 和代码分开了么 延迟加载翻译 这一节介绍了怎么像传统应用那种创建一个 lang 目录，然后里面写一堆语言文件的 最重要的一点，前端因为构建工具的存在，项目目录和实际运行目录是不一样的，你写了一堆 i18n 文件，别人一下就给你全打到 app.[hash].js 里了，再加上 cdn 的存在，你的文件存在哪个服务器上都不好说哦，没有什么 i18n 可以做到尽善尽美 |
 |
25
labulaka521 2020-05-12 23:19:31 +08:00 1
Apple 节点再开一贴:
日常开吹：竹板这么一打，今天夸一夸，为什么我喜欢安卓 |
|
26
murmur OP @labulaka521 这个其实不用吹的，安卓的市占比三倍于苹果，市场证明一切，vue 现在和 react angular 三分天下，没有谁说有绝对优势，所以得拿出来单独吹
|
 |
27
chendy 2020-05-12 23:27:10 +08:00
等一个 Apple 节点的
《日常开黑：竹板这么一打，今天黑一黑，为什么我讨厌》 |
|
29
LokiSharp 2020-05-12 23:39:37 +08:00
@murmur #24 我觉得吧，主要问题还是 Vue 的用户使用场景单一导致工程化的缺失。
刚刚我看了看这个作者的 Github https://github.com/kazupon/vue-i18n-locale-message 去年年底已经开始写新的工具了，文档上粗看应该是分析 vue 文件并提取待翻译的字符串，用 json 保存。 说明 Vue 团队还是有人思考这些实际问题的，而不像某些进取的用户。 |
 |
30
binbinyouliiii 2020-05-12 23:44:14 +08:00
vue 容易上手，但是我干后端上手 Angular 轻轻松松，还是喜欢工程化的东西
|
|
31
LokiSharp 2020-05-13 00:18:08 +08:00 5
不要吹那些有的没的的类似语法糖的特性，到头来都是一场空。Vue 所谓的学习曲线平缓只是因为他本体是渐进式（指没有实现完整的功能）框架（自称）而已，功能少的东西自然学起来简单。
想要达到满足工程化的功能的话。 发送请求你得学个 axios 吧？ 路由管理的 Vue Router 总得学吧 状态管理得学个 Vuex 或者 RxJS 吧? 单元测试 Jest 和 Mocha 选一个？ 是用官方文档放在首位的 script 引入还是官方 Vue CLI 或者手动配 webpack ？ 为了深入理解最新的 Vue 3 尤雨溪最近真香了的 TS 是不是也得学一下呢？ 你正文里的四个问题让我感觉你是在黑 Vue，非专业前端、开发小程序、非 SPA 、不需要维护满足这 4 点要求的简单页面，按照你说的啥都别学的场景直接用 JQ 和原生 JS 不就好了，Vue 有啥优势？ |
 |
32
zzzzzzggggggg 2020-05-13 00:24:58 +08:00 via iPhone
先评论后看
|
 |
33
anguiao 2020-05-13 00:26:39 +08:00 via Android 3
等一篇“为什么喜欢 Windows”
|
 |
34
zthxxx 2020-05-13 02:18:36 +08:00 via iPad 8
通篇细读三遍来总结下楼主说的适用情况：
- 小厂、外包、传统企业内部平台 分别对应 不用考虑团队合作、不考虑产出质量、不考虑后续维护 - 没有前端知识的后端开发者 - 只有基础英语单词阅读能力的国内开发者 - 不考虑工程化 不考虑自我学习能力提升的开发者 |
 |
35
TypeError 2020-05-13 03:19:00 +08:00 via Android 4
@LokiSharp 这个 i18n 也太野路子了，后端客户端一般都类似或者直接调用 GNU gettext，放个资源文件就行
|
|
36
LokiSharp 2020-05-13 07:35:58 +08:00 via iPhone 1
@TypeError 是的，当时看到这作者还是 Vue Core Team 的人，我就开始怀疑 Vue 的水平了。
|
|
37
murmur OP @zthxxx
1 、团队合作是有限的团队合作，如果强类型可以搞定一切的话，java 和 c#的项目将是世界上最优雅、最容易维护的，但是不是，所以说一个模块怎么拆分，拆分到多少人去做，是有门道的。后续维护？不好意思，这个世界上能谈得上后续维护的项目没多少，尤其是互联网公司，倒的一茬一茬跟割韭菜一样。即便是淘宝、京东，你看他的页面是不是很有年代感，尤其是后台，也是能用就行干嘛重构翻新。 2 、vue 门槛低不代表前端开发者不能用，如果你的项目就那么简单没必要上 angular 这种大框架，因为项目有简单有难所以这 3 个框架哪个也没做到绝对优势 3 、这也是对 vue 门槛低的曲解，英语可以在 api 的命名和变量命名上得到体现，没必要非要给一个官方 api 起几十个字母，其实 jquery 的 api 也很精炼 4 、vue 本身就是 web component 的一种实现，怎么能说不考虑工程化？如果说强类型才是工程化，php 和 python 是不是哭瞎？ |
|
38
murmur OP @LokiSharp
vue 真的可以简单到只当作高级 template 来用，还真以为前端开发每个人都高大上 还有别黑 jq，jq 还没死呢，活的好好的，而且将成为前端史上重要的里程碑，值得每个产品经理学习 |
|
40
LokiSharp 2020-05-13 08:00:32 +08:00 via iPhone
@murmur 就用个模版，还没有专门的前端，也不需要 SPA 级别的复杂交互。还跟风前后端分离用 Vue 干啥，按传统后端的直接渲染 HTML 不就好了？别和我说你还是 Serverless(笑
|
|
41
LokiSharp 2020-05-13 08:08:48 +08:00 via iPhone
@slyang5 抱歉了这个我不太清楚，我 C 的时候好像还没有 LeetCode，现在的工作也不需要我折腾算法，我也没求职需求
|
 |
42
Mutoo 2020-05-13 08:27:41 +08:00
"react 的核心竞争力就是 rn" 来源请求？
|
|
43
AdamChrist 2020-05-13 08:27:45 +08:00
@longjiahui #16 #17
1.业务模块一般有各种需要 Modal 的功能,并不是公用的.如果使用 props 的形式,要在父组件定义一堆子组件的属性,如果这个业务模块比较复杂,那么可想而知,父组件会很臃肿.如果用 refs 的方式,那就简单很多了.Modal 的属性可以通过 this.$refs.xxx.show({xxx})的方式传入进去. 2.直接绑定到 form 上面之后,如果你改变了表单,那么 vuex 的 store 里面的数据也会被更改的.这不符合 vuex 定义的思想. |
|
44
murmur OP @Mutoo 这是我的看法，因为这三个框架都是在一定范围内有优势，要问什么是另外两个框架没有的，那就是 rn，rn 是真的有生态，这和 weex 不一样
@longjiahui dialog 的写法一般是 <your-dialog ref="yourDialog" :show="xxxx"> <div slot="title">一个炫酷的标题，想怎么折腾就怎么折腾</div> <div slot="buttons">按钮随心所欲，想怎么放就怎么放</div> <div slot="content">这里才是主体部分</div> </your-dialog> 唯一的区别是用 ref 还是在 your-dialog 上加 prop，至于你说父组件比较臃肿，我也可以认为如果把 dialog 的个性化部分写道 prop 里，我就可以在 template 部分直观看出所有特性，而不需要 template 和 js 来回切，可以看到，大部分的定义都是 slot 留给用户自行发挥，真正必须写成 prop 的属性并不多，剩下的就只有尺寸、钩子函数这些 |
 |
45
TsubasaHanekaw 2020-05-13 08:39:25 +08:00
i18n 看下来就少了个能够自动提取所有要翻译文本的工具?
一般使用不都是 const i18n = new VueI18n({ locale: 'CN', // 语言标识 messages: { 'CN': require('./assets/common/lang/cn'), // 中文语言包 'EN': require('./assets/common/lang/en') // 英文语言包 }, }) 这样来么 |
 |
46
AngryMagikarp 2020-05-13 08:42:12 +08:00
你这是夸还是黑
|
|
47
Mutoo 2020-05-13 08:43:17 +08:00
@murmur rn 是竞争力，但并不是什么核心竞争力。非要说核心竞争力的话，应该是 functional programming style 和 react-fibre
|
 |
48
devwolf 2020-05-13 08:44:15 +08:00
正常这种话题不都应该左转"水深火热"吗
|
 |
49
agdhole 2020-05-13 08:44:16 +08:00 via iPhone
@LokiSharp 我给 vuetify 做翻译的时候，他们用的 crowdin 这个程序，挺好用，还支持可视化翻译
|
|
50
murmur OP @Mutoo 函数式编程与命令式编程都是不同的风格，这两个风格本身就没有高下之分，尤其是排行榜绝对领先的 java 和 c 都是命令式编程，所以你不能说函数式编程就是竞争力
react-fiber 是对算法的优化，而且再优化也不能堆砌元素，在批量插入的时候，因为 mvvm 框架的限制，会被 template 直接插入 html 碾压，换句话说，我选择了 mvvm 框架就已经牺牲了部分性能 |
|
51
LokiSharp 2020-05-13 09:04:42 +08:00
@TsubasaHanekaw #45 是的，主要是少了这样一个工具。当然这个自己写一个也不难，但是我用“框架”不就是为了避免多写业务以外的东西么
@agdhole #49 Crowdin 是翻译平台，源文件要自己处理的。刚才看文档发现现在居然支持直接上传 js 文件了，我去看看怎么用= = |
 |
52
Twinkle 2020-05-13 09:11:44 +08:00 via Android
我喜欢 Vue 把 HTML / CSS / JavaScript 全部塞进一个 .vue 文件，相比 React 需要自己选择 import 还是 styled-component 或者别的什么，每次都很头疼。
但是用两者开发了很多项目来看，还是更喜欢 React 哈哈😄 |
 |
53
jinsongzhao 2020-05-13 09:12:40 +08:00 via Android
Vue 是专门对 HTML 方向优化的，比其他的效率高，适合新手和老手。React 则是面向现有开发者友好的，所以使用 React 的开发者非常多。老手不需要 React 的代入感，要的就是针对性强的高效
|
 |
54
siteshen 2020-05-13 09:26:40 +08:00
没人关心这贴子和「竹板」有什么关系吗？
|
 |
55
zhwithsweet 2020-05-13 09:36:38 +08:00
聪明的前端开发者早就不拘泥所谓的前端框架，已经开始刷 LeetCode 了，向微软前进！！！
|
 |
56
guolaopi 2020-05-13 09:38:13 +08:00
开始了开始了，
PHP：go 抢了我的工作之后，前端又要跟我比如何让人撕逼了？ 理性说一句， LZ 知道的不少，但是多数情况下发言的观点都较为主观（可能有的观点是客观事实，但是听起来还是很主观）， 所以每次 murmur 出现必有撕逼，包括但不限于 React<> Vue , Windows<>Mac , IOS<>Android 。 |
 |
57
sunzongzheng 2020-05-13 09:41:09 +08:00
又来骗币了
 |
|
58
murmur OP @guolaopi 喜欢不喜欢，本身就是个很主观的东西，这三个框架都很优秀，想客观也不可能是吧，想在三个一样好的东西里说哪个更好，一定很多人为加的限定因素。
至于 windows 对 mac，android 和 ios，都是市场份额的绝对优势，不如说 mac 和 ios 粉才是主观感受 |
 |
60
sagaxu 2020-05-13 09:46:23 +08:00 via Android
作为后端，用了几年 vue 撸管理后台，被 antd 的勤快打动，今年转 react 了，反正对后端来说，一样的依葫芦画瓢，差别不大。整体上体验差不多，react 的 IDE 支持比 vue 好那么一点点，vue 的 form 语法糖比 react 香甜。
|
|
61
murmur OP @guolaopi 这本身就是 https://v2ex.com/t/670771 的联动，没必要搞的那么严谨跟写论文一样
为什么我在 i2ex 这么 WTF，因为果粉跟你讨论的时候带了太多假设 1 、我不差钱 2 、软件不花钱，能网盘的都网盘，能拼车的绝不自己买正版 3 、生产力不谈性价比 你都钱不当钱了，我还怎么跟你理性讨论，是不是 |
|
62
guolaopi 2020-05-13 09:52:58 +08:00
|
 |
63
speculatorA 2020-05-13 09:58:39 +08:00 1
@guolaopi 评论大概过了一遍，说不上撕逼吧？算环境较好的辩论贴了。
|
|
64
speculatorA 2020-05-13 09:59:18 +08:00
@guolaopi 到时你一进来就开始阴阳怪气了，帖子就是这样烂的。
|
|
65
murmur OP 2
@guolaopi 哈哈，我知道，但是撕逼本身就是消遣的一部分，跟刷快手和抖音一样的，现在很少有国内纯讨论技术的东西，搜索引擎太牛逼了，能搜的都搜到搜不到的问也问不到，所以才给我们这些无聊的人提供了写长文开撕的地方。
我在这和果粉对喷，别人在知乎编故事，他在微博制造谣言，大家都有充实的生活 |
 |
66
jinzhongyuan 2020-05-13 10:04:11 +08:00
求求你做个人吧
|
|
67
guolaopi 2020-05-13 10:09:06 +08:00
|
 |
69
marcong95 2020-05-13 10:19:47 +08:00
@LokiSharp #21 看到你说传统软件的 i18n 是提取程序内的文本交给翻译翻译的，就不奇怪 B 站某知名 up 主玩的迫击炮是怎么来的了。一个海外游戏公司，旗下游戏大量出现研钵（ mortar ）这个道具，中文翻译迫击炮，反正已经成梗了。虽然这个并不完全是 i18n 流程的锅。只是很奇怪，软件、游戏这种可能大量出现单独一个单词或者词组，文本上不能体现上下文的，真的适合把文本提取出来翻译吗？
虽然没正是用过，vue-i18n 的逻辑应该是前端开发的时候就已经把占位符写到代码里，而不是把原文本 hard code，然后再替换占位符。这种形式好像 android 开发也是这样要求的？ |
|
70
LokiSharp 2020-05-13 10:35:14 +08:00
@marcong95 #69
qt 之类的成熟的框架用 gettext 之类提取的文本注释带有源码位置信息的，可以是体现上下文的。 Artifex Mundi 翻译质量问题不是流程的锅，他们的作品本来就是小品级的节约成本不花钱做校对很正常。 |
 |
71
wensonsmith 2020-05-13 10:41:07 +08:00
吹得好！
React 大道至简，但是保持简约就不一定简单了，要实现高级功能就必须什么高阶组件、三目运算、Hooks 等等 还是不习惯 html 混合着 js 写，有种被当年 jquery 去拼接 html 的支配的恐惧。。 |
|
72
longjiahui 2020-05-13 10:44:25 +08:00
@AdamChrist 假如写成组件，除了事件以外，props 要写在 data 里的 难道不就只有一个 visible 吗 ？ 剩下的就是动态的 内容，这些本来也存在 data 里了。不会臃肿啊。
|
 |
73
zicla 2020-05-13 10:47:39 +08:00 1
君子和而不同，自己用得爽就行了！
|
|
74
AdamChrist 2020-05-13 10:52:53 +08:00
@longjiahui #72 一个业务模块,可能有几个弹窗(dialog),那么就要写多个 visible,这看起来已经很不好.而且如果里面的内容需要初始化,或者再次获取,还需要给 ID 或者 formData 之类的.当然弹窗肯定不是指简简单单的提示,而是包含的一些用户操作在里面.没有办法做成通用的.
|
 |
75
lancelock 2020-05-13 11:22:19 +08:00
我开始接触这两个框架的时候，也是觉得 vue 简单直白，react 有点反直觉，主要之前用过 ng1，模板的那套做法比较熟悉
后来写 react 的时候发现，我可以完全不需要了解很多 api，用 js 自由发挥，只要 js 的语法没问题，结果就能给你正确的渲染出来 总之，js 的表达能力有多强 react 的表达能力就有多强，所以越写越顺手了 当然 vue 我不是很熟悉，就不多发表意见了。反正我也不做后端了，自己业余写前端项目还是喜欢 react + hooks 总之你的观点我倒是赞同，对于后端来说写前端 vue 接受起来比较容易。不过如果是专职前端的话，总得深入研究下 js 、es6 吧，毕竟以后一直要吃这碗饭的。 |
 |
76
calanlot 2020-05-13 11:25:45 +08:00 via Android
三个框架都用过，ng 的路由和表单的封装开箱即用非常强大，相对坑的是懒加载(目前 Ivy 正在解决的)，和 ng template 的类型丢失。能用 ng 我肯定是不会用 vue 了
|
|
77
zthxxx 2020-05-13 11:33:10 +08:00
@murmur #37 不是在表达我的观点，只是在试图总结楼主发的内容
第 4 点这里说的不是代码的「抽象程度」而是在总结你表达的 「对整个工具链路的工程化、自动化没有任何追求」甚至觉得多余 「真的只是把编程当成混口饭吃的技能而已，对编程，对计算机毫无兴趣的」 通篇适用对象就很像隔壁帖子 t/670747 中如上描述的情况 |
|
78
murmur OP @zthxxx vue 除了因为没官方支持 ts，因为 es 特性不支持强类型，其余的不影响你自动化，vue 有 cli，可以用 webpack 打包，可以懒加载、分模块打包，想和 jenkins 自动化构建也是可以的
至于你说什么测试，能把自己写的代码按后端标准覆盖一遍的有多少，前端的单元测试基本没用，界面级的测试多难做大家心里都清楚 所以什么叫混口饭，你说说 react 哪里在工程化上高人一等? |
 |
79
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 就是这样的一个尝试。 |
|
80
zthxxx 2020-05-13 11:46:39 +08:00
@murmur #37 基于这些总结，我并不否认面向楼主你说的这些人群 vue 确实是适用
楼主面向的这类群体或情况都是确实存在的，不同的情况需要不同的解决方案是个很自然的论点， 我也很佩服楼主的表达能力，能很清楚的都说出来 （相信要不是知乎控评，你肯定会去知乎对线了 大部分人在「争吵」的根本矛盾都在于 想把自己喜欢的一种框架 / 一种方案安利给所有人，而缺少考虑是否符合目标受众 |
|
81
longjiahui 2020-05-13 11:52:57 +08:00
@AdamChrist 这就是个人喜好而已了，你只是觉得 visible 比 refs 引用难看
|
 |
82
wangyzj 2020-05-13 11:59:00 +08:00
我选择 vue 就俩原因
1：我是后端 2：我贼不喜欢把 html，js 啥的乱糟糟的写一起 |
|
83
LokiSharp 2020-05-13 12:12:37 +08:00
@ChanKc #79 我觉得 这个 i18n 这么干是可能因为部分 vue 用户（大多为新手）都不用 vue-cli 建工程化的项目,而是用官方文档首选的 <script src="..."></script>
我碰到过很多用 vue 的人，他们就和楼主一样认为就用个模板功能就足够，对他们来说 Vue 比起 React 、Angular 最大的优势就是直接 script 引入到 HTML 就行。 不过我看了这个作者最新的 repo https:// github.com/kazupon/vue-i18n-locale-message 他去年开始在做这个提取文本为 json 的工具，可能会好一点。 我现在不喜欢 Vue 的一点就是 Vue 的各种轮子太多了，也没人总结个最佳实践。除了 Vue 核心之外其余组件的文档大部分也写得不怎么样，拿到手什么东西东西得自己考虑，考虑到最后结果会发现用他们现成的还不如自己造个轮子。你说的 GitLab FOSS 这种应该就是这个情况。 |
 |
84
shiwoya 2020-05-13 12:59:09 +08:00
对于我一个基本无基础得来说确实爽 vue （写过点 c++）
刚入门得数据双向绑定真的很友好啊 |
 |
85
faceRollingKB 2020-05-13 13:04:33 +08:00
@LokiSharp 我最好奇的是 vue3 出来以后，这帮人到底要不要跟进，目前了解到身边用 vue 的人都明确表示不会学 ts
|
 |
86
yaphets666 2020-05-13 13:05:19 +08:00
@faceRollingKB vue3 是用 ts 写的 但是使用 vue3 并不需要 ts
|
 |
87
L1shen 2020-05-13 13:07:15 +08:00
@faceRollingKB vue3 不限定用户用什么的, 只是 vue3 本身用 ts 写的
|
|
88
LokiSharp 2020-05-13 13:11:47 +08:00
@faceRollingKB #85 跟进了不是打自己脸么，当年 Vue 社区说 Angular 2 学习曲线陡峭最主要的一点就是 Angular 2 是 ts 写的，现在的情况一模一样。
|
 |
90
jiaweixianxian 2020-05-13 13:22:14 +08:00
即使你从未写过前端，从未学习过 JS 和 HTML，也可以用 Vue 做出来看上去还可以的东西。
认识一个女生朋友基本 JS 什么都不懂，就做过 Vue 。去面试前端，还嫌人家工资给的低，嫌人家面试问的详细，后了解，人家只是问了个 Promise 而已。 |
|
91
LokiSharp 2020-05-13 13:22:17 +08:00
@LokiSharp #88 现在文档里还没改掉，期待 v3 文档里面怎么说
https://cn.vuejs.org/v2/guide/comparison.html#TypeScript Angular 事实上必须用 TypeScript 来开发，因为它的文档和学习资源几乎全部是面向 TS 的。TS 有很多好处——静态类型检查在大规模的应用中非常有用，同时对于 Java 和 C# 背景的开发者也是非常提升开发效率的。 然而，并不是所有人都想用 TS——在中小型规模的项目中，引入 TS 可能并不会带来太多明显的优势。在这些情况下，用 Vue 会是更好的选择，因为在不用 TS 的情况下使用 Angular 会很有挑战性。 最后，虽然 Vue 和 TS 的整合可能不如 Angular 那么深入，我们也提供了官方的类型声明和组件装饰器，并且知道有大量用户在生产环境中使用 Vue + TS 的组合。我们也和微软的 TS / VSCode 团队进行着积极的合作，目标是为 Vue + TS 用户提供更好的类型检查和 IDE 开发体验。 |
 |
94
mandex 2020-05-13 13:36:50 +08:00 3
简而言之就是：我觉得我的员工都很菜，他们不会 React 。
坦率的讲，我觉得你在吹 React 。 |
 |
95
MikeFeng 2020-05-13 14:02:43 +08:00 via Android
人生得 vue 须尽欢，多用 template 早下班。互联网唯‘快’不破，专治一切花里胡哨
|
 |
96
dodo2012 2020-05-13 14:11:02 +08:00
我是都用过，哪个方便用哪个，现在自己前后都做就 stimulus，要前后分离就 vue，移动 app 就 rn, 有啥争的。
|
 |
97
gaigechunfeng 2020-05-13 14:23:05 +08:00
我仅代表个人看法支持楼主。说下自己的经历。
我作为 android 底层开发，一周学会 vue，一个月开发（复制粘贴）了小程序，加上用 element 开发（复制粘贴）了 dms 管理后台，赚了一点外快。 现在在开发另一个小程序，集成提炼了一些自己的 UI 库，自己的 component，开发更顺手了。 我觉得 react 和 ag 应该也不难学，谁比谁坏不好说，但现在用 vue 做项目，都完全没有问题，直接就能一把梭。 语言就是工具，你用铲子，我用锄头，能把活干完收钱就行。 如果有钱有闲我可能会试试你的铲子，等着干活赶工期，我就老老实实用锄头得了。 当然楼主竹板敲烂，改喷 vue 的还是喷。 |
 |
98
tremblingblue 2020-05-13 14:25:24 +08:00
核心路由状态等基本全是官方的.
vue 的项目差不多都长那样.让个不会的瞎搞也不会乱到哪里去,个别情况除外. 从长期来考虑这些的确省了不少心智维护代价. |
 |
99
xcstream 2020-05-13 14:28:26 +08:00
先入为主吧，用了一种语言就不想换了
|
Select Language