自我描述一下，我大学毕业后自学java参加工作，leader要求我学会Angular，然后开始了一年半的开发，前后端都有写过代码，前端居多，使用Angular8/9。现在离职，准备跳槽拿一份更高的薪水，最近在家自学Vue和React，它们的一些用法，或者语法，让我感觉有些不适。（希望不要用java程序员更喜欢Angular，或者Angular就是后端那一套这种答案来回答我，我认为不是这个原因，另外我只是个菜鸟，无法从底层深度去评价框架，只是觉得它们的语法/用法让我不适）

先从Vue说起，其实一开始学Vue还是觉得挺不错的，很多东西和Angular的用法很像，让我产生严重排斥感的是Vuex：

  1. 首先，所谓状态管理，也就是多组件共享变数，在Angular里直接创建一个service.ts文件就搞定，里面直接写你需要共享的变数和方法就可以，而Vue还需要安装Vuex，里面还分state，mutation
  2. 其次，Vuex的用法太奇怪了，取变数还好，但是当我要更新state里的变数，居然要用commit，如果有非同步更新还需要额外做一次action，还需要传递一个方法名字元串？这是什么诡异的用法？
  3. Vuex可以分模块，每个模块里有各自的state，mutations，actions，在组件里要调用模块里的state，就需要模块的名字，而调用mutation或者action又不需要名字，也就是说它们是全局的，那就意味著不能出现重名，模块的名字也不能和全局变数重名。我理解模块化的思想，但是无法理解它的用法。

Vuex只是Vue的一个缩影，这半个月学下来，我觉得Vue的框架感，或者说规矩感太过浓重了，它规定了你数据要放在data里，方法要放在methods里，更新state需要commit，commit需要传递方法名，如果非同步更新需要额外dispatch一个action，调用模块里的状态有的需要模块名，有的不需要，这些规矩，都需要人去遵守，去记忆。

React到现在我才学了两天，但是这个JSX语法让我甚至觉得比Vue还让人不适，Vue是规矩性太强，但是它至少做到了html js css的分离，从结构上还是清爽的（虽然没有做到文件上的分离），而JSX实在是让我无语，从最初学前端老师就说style和script的三种引入方法，外部引入是最好的，可以解耦，JSX是在颠覆这种说法吗？

最后说一下我觉得Angular对比它们的几个让人舒服的点：

  1. ts，css，html 彻彻底底的分离，Vue虽然也分离了，但还是放在了一个文件里的，而Angular中每一个component有它对应的html文件，ts文件，css文件，真的清爽
  2. 没有乱七八糟的规矩，要求我必须把数据写在哪个data里，方法写在methods里，更新属性还需要commit什么的，都没有。直接定义一个变数，直接用，直接修改，如果需要多个组件共享变数，就创建一个service.ts文件，把共享变数和方法放在service文件里就可以了
  3. 编辑器的支持很好，这一点真的是不对比不知道，用了vue和react，才发觉编辑器有多重要，webstorm或者idea对Angular的支持，甚至到了Java那种程度，就是你用了哪个变数或者方法，ctrl点击一下就可以直接跳过去了
  4. 文档，在我看来Angular&>Vue&>React

上面说了一大堆，我只是想问，你们用Vue和React的开发体验到底是怎么样的，你们不会觉得不适吗？Angular的开发体验那么好，为什么国内用的人很少，国外好像也不是特别多呢？

首先的首先，Angular也有类似技术：ngrx,这只是一种近期以来web前端很流行的一种设计模式，不过确实侵入性很强，初学者很难理解。关于angular不温不火的原因我觉得主要是因为Angular的受众比较的尴尬

我来尝试对前端开发归个类，欢迎对号入座

  1. 切图仔，切图仔其实并不会太会前端开发，只是会单纯的做一些静态网页，但是也常常被莫名归类到前端开发中
  2. 三大框架嗤之以鼻，Jquery才是王者的开发，因为一直维护老项目，没有兴趣也没有动力去研究三大框架

3. 没接触过老一代技术的三大框架初学者

4. 后端做前端的全栈

5. native做web的大前端开发者

6. 熟悉三大框架之一+原生js的开发者，熟手

7. 精通三大框架之一+原生js的开发者，经常给社区造轮子

8. 经历过老技术，过渡技术以及现在最新技术的大佬，架构过不少项目

对于1-3的开发者而言，angular学习成本太高了，而且不太容易能理解

4-6的开发者而言，angular爽歪歪，特别是那些后端搞Java/C#的全栈，什么IoC，service简直就不用学，一看就懂，不过RxJS/ngrx也有很陡峭的学习曲线

对于7-8的开发而言，Angular侵入性太重了，不如自己控制灵活，但是做到最后和angular的功能最少也有60%的重复吧

最后的最后7-8一般负责选型，1-3干啥都行，反正也不会，也懒得管，4-6只能发表意见没有啥话语权，所以。。。

占坑，上班了就来写回答。

---华丽的分割线

作为一个资深三系框架搬砖码农，我觉的这个问题我还是可以分享下个人看法，不喜勿喷。

首先，技术喜好是十分主观的东西，你喜欢 NG，他喜欢 React 或者 Vue，当讨论到 xx 框架为何比 xx 框架优秀这种月经问题的时候，很容易就会陷入到一种无休止的争执中，但大部分观点，无非是拿一个框架的优点，去比另外一个框架的缺点，大概就是这个样子。其实你仔细想的话，你一直说一个框架多好多好，但另外一个人压根就没用过它，自然不会体会到你说的那些优点？换言之，你问题描述中所说的 NG 的优点，对于使用过人来说，懂的自然懂，对于没用过的人来说，他们就不会懂。所以先回答楼主的第一个问题，用 React 和 Vue 的公司很多，不是你的问题，也不是其他公司的问题，而是很多其他客观原因造成的：

  • Ng 2 正式发布的时间点落后于 React 和 Vue，同时学习门槛对于没怎么接触过 OOP 的前端开发者来说，门槛较高，这还没涉及 rxjs 之类的响应式编程的东西，所以国内用的人少是很正常的现象
  • Ng 2 和 Ng 1 在概念上，完全是两个次元的框架，造成迁移成本较高，所以很多用 Ng 1 的公司可能至今还在用 1.5 或者 1.6 的版本，其实在之前，Ng 1 在国内是非常流行的，我接触过的很多项目，都是用它来做的
  • 由于第一点的原因，国内的培训机构，以及技术博主，肯定更倾向于投入时间和资源到 Vue 和 React 上面，毕竟用 Ng 2 的公司少，学的人自然也就少，我曾经在 SegmentFault 专栏写过关于 Ng 的一些列文章，基本就没什么人看，但后来转移到 React 和 Vue 上之后，浏览数相比较之前最少翻几倍，一叶知秋，当时我就知道大概是个什么情况了
  • 最后一点再说下题主个人的原因，你已经说了你有自学 java 的背景，同时题目描述也包含「希望不要用java程序员更喜欢Angular，或者Angular就是后端那一套这种答案来回答我」 这样的描述，这足以证明，Ng 必然更受有服务端编程经验的后端程序员的偏爱，因为它更加 OOP，虽然也不是太严格的 OOP，但相比较 Vue 和 React 足够了，反过来说，没有 OOP 概念的前端程序员必然更加排斥它

所以你能发现，Ng 在现在不那么流行的原因，只是滚雪球没滚过其他两个框架罢了，虽然它足够优秀和好用，我读过小部分的源码，能够感受到 Ng 本身的架构和设计，都是非常先进和优秀的，只要你能够熟练掌握 Ng，再回头学习其他 mvvm 框架，你真的感觉和玩一样。

然后我再来说几点关于其他两个框架的看法，算是帮助题主客观认识另外两个框架，而非有这么多的偏见，就依次按你的描述来说就好。

先说 Vue：

  • 首先你排斥 vuex 的观点是说状态共享拿 service.ts 就能实现，但你有没有仔细想过，vue 中也可以拿类似的方式实现，无非在于你需要手动把 service 导入到 SFC 文件中罢了，但这样造成的问题是，service 和 SFC 文件耦合在了一起，而 Ng 中没有这种强耦合性是因为它有 DI 机制，而 vue 是没有的（其实也是有的，但没有 Ng 那么强大），所以为了更优雅地解决这个问题，才需要 vuex 来解决状态管理的问题
  • 另一个方面，状态管理这个诉求，是一个抽象的概念，其实现方式是不固定的，这意味著，你可能会写一个 serviceA.ts，他可能写一个 serviceB.ts，然后你俩做的事情实际上是类似的，这一定程度上造成了迁移成本，但如果开发者都共通遵守同一套开发模式，比如 vuex 提倡的这套，action/mutation/commit 等等，那么迁移成本就小了很多，同理，对于各种命名规范，其所想达到的目的，也是这个，就是为了让大家能够更加顺畅的合作，使项目的可维护性和迁移性更强。
  • 最后说下「我觉得Vue的框架感，或者说规矩感太过浓重了」，感觉这个有点没说到点上，在我看来，Ng 可能才是框架感或者规矩感比较浓重的那个，你之所以觉的 Vue 或者 React 过于框架或者规矩，是因为 Ng 这种约定大于配置的理念，让你置身于约束又不自知，如果连数据写在 data 里，方法写在 methods 这种语法层面的东西也算的约束的话，我觉的这有点抬杠了。

再说 React（感觉题主没怎么用过 React，就简单说两点吧）：

  • 首先，React 提倡的是 all-in-js 的开发理念，所以你能够发现，它的模板是 jsx，它的 css 是各种 css-in-js 的实现方案，它们最终都要被编译器转化为 js 代码，这在架构思想上，和 Ng 就不一样，关于 template 和 jsx 孰优孰劣的问题，现在其实争论也不少，我的观点就是，萝卜青菜各有所爱吧
  • 实际上 React 中关于 style 的使用方式，完全可以使用传统的外部引入 css 文件的方式来搞，很多流行的组件库都是这么搞的，并没有使用 css-in-js 的方案

说了这么多，大概就是这么两个建议：

  • Ng 很优秀，你有学习它和使用它的经验，这不是你的问题，反而是优势
  • React 和 Vue 本身也很优秀，你需要客观地、不带偏见地学习和认识它们，而不是排斥

我个人而言，比较看好 Vue，虽然我之前是一个 Ng 铁粉，但经过几次发布后，Vue 框架真的是越来越优秀了，足够简单，足够好用，足够强大，所以非让我给个我心目中三大框架的排名，大概这个样子：

  • Vue &>= Angular &> React

可是说这些有什么用呢，发工资给我的还不是用 React 全家桶，算了，搬砖去了。（手动狗头

首先，Angular是框架，而Vue和React是实现组件化的库。从功能完备的角度框架和库并不具备可比性。

所以从功能上对比Angular Component是与React和Vue解决相同问题的。

三大技术栈都从数据驱动的方式替代了上个时代以操作dom为核心的开发方式，只不过各个技术栈对数据的处理各不相同

  • Angular延续了Angular1的脏检查机制，拦截了浏览器非同步api，在任务队列的结尾检查数据的变化以更新dom
  • Vue则通过定义对象的get，set方法监听数据的变化，然后根据需要更新dom
  • React则更贴近函数式的方式，通过新的状态生成新的dom

在Angular的架构中Service更适合编写一些数据操作的逻辑，通过将这些逻辑脱离于Component实现，可以让Component更专注于展示数据和响应用户的交互行为，提高了组件的复用性，同时不同的Service处理不同的业务也让Service之前也保持足够的边界。确实借助Angular对DI的实现，Service可以以单例的方式缓存一些数据，但从设计上Service并不是做这件事的，所以可以发现在Angular官方的例子中使用了angular-in-memory-web-api作为数据缓存的方案。

在React和Vue中并没有Service的概念，许多对数据的操作逻辑要么写在Component中，要么写在全局的状态管理Vuex中，写在组件中会降低组件的复用性，都写在全局状态中又让全局状态十分臃肿和繁琐，该写在哪从两个库的角度并没有做限制和指导。相反的，从React的容器组件到Web hook，Vue的composition api都致力于将数据状态剥离于组件，显然二者更加关注组件本身。

Vue和React都很好解决了组件实现的问题，但没有解决设计的问题，虽然Vue和React更易上手但如果没有良好的架构设计，后面的维护工作将面临更多挑战。

随著项目代码越来越多，我们可以清晰的发现使用Angular开发应用更便于维护，这不仅仅是TypeScript的功劳，也因为Angular作为一个框架，其Component，Module，Service等功能架构设计意图是完备的，在面对变化时更容易找到内置的方案，避免在项目膨胀的过程中对整个工程的架构设计的冲击。

因为Angular的架构清晰，像对熟悉类似spring这样同样架构清晰的Java工程师来说自然更觉得亲切。

技术没有好坏之分，只有适合与否。短平快的项目，Vue、React更合适；长期的项目缺乏设计能力就使用Angular。

是你的问题。

我经常说一句话：程序开发首先是思想，然后才是敲键盘。

不同语言，不同框架，里面蕴含的是不同思想。特别是当一个技术点处于爆发期，各种语言和框架层出不穷短兵相接的时候，百家争鸣，百花齐放，思想的碰撞尤为强烈。最后思想会相互吸收、融合、沉淀，形成稳定的两三家。

为什么要有jQuery，因为jQuery的那个时代，他的思想能够解决问题。

为什么jQuery逐渐被淘汰了，然后出现了Angularjs、backbone、Ember？因为新的思想产生了。jQuery在新一批框架所秉承的共同思想下没有他发挥的空间。

为什么Google要壮志断腕放弃自己的Angularjs，开始打造全新的Angular？而Facebook却要开发React。另外有一个叫尤雨溪得人不认同Angular的发展方向，自己一个人出来干出个Vue？就是因为思想的上的冲突。道不同不相为谋，一个框架容不下不同思想，不同的道分别产生了自己的框架。

很多开源框架都是这样，但凡思想上认同，只是觉得还不够完美，就不会另起炉灶，而是会在原有框架上去贡献。只有觉得起根想法上就不一样，根本不能把自己的新想法贡献在老框架上，才会有新框架出来。

什么是「削足适履」？为了适应一双不合脚的鞋，自己把脚削去一些。多难受，多痛苦...

你觉得Vue和React相比Angular用起来不那么舒服，是因为你在削思想，为了去适应另外一拨思想不同的人写出来的框架。

不仅仅是当前这个问题反应的前端框架，几乎编程上的所有领域都是这样。你要学会一项技术，必须首先认同这个技术背后所蕴含的思想，说白了就是发明这个技术的那波人到底是咋想的。

不同框架创始团队的技术出身、工作经历都会导致他们在新框架上所表达出来的不同思路。就好像你刚开始不认同一个人的观点，硬著头皮去理解也觉得这个人很怪。当你和他熟悉了之后，你了解了他是哪里人，从小的家庭环境、生活环境是怎样的，上学和工作的十几年中遇到过什么坎坷，你也许就能接受他现在的观点，也能理解他现在为人处世的原则。

见过很多很多这样的程序员。让他们用一个新框架，他们一脸不情愿，然后抱怨：这个框架不成熟！这个框架太烂！这个框架不适合我们的业务！

其实他就是抱著老框架的思想去用新框架，幻想著所谓的新框架和老框架一个套路，只是性能优化了一些，或者其他改变都发生在自己看不到体验不到的地方。

林子大了什么鸟都有，人多了什么想法的都有，所以框架多了什么套路的都有。你只用自己已经接受了思想的某一个框架去套用别的框架，就是削足适履。

所以，我说是你的问题。因为你用Angular的脚去适Vue和React的鞋。但好在思想不用削，思想是可以改变的。

终于找到了一个和我相同感受的，哈哈

写了几年AngularJs，和Angular后我同样抗拒写Vue，同样抗拒使用Vuex。何况我所看到的Vue项目都是那么杂乱无章，还美其名曰函数式编程；滥用Vuex，什么东西都往里面塞，把它当成万能神器；缺少业务模块划分，缺少NgModule这一层设计

先占坑后面补充。

推荐阅读：
相关文章