首先

这篇文章在这里。

推荐Vue.js的原因

在Rails框架上

学习Vue.js的初期成本相当高，但一旦克服了这一点，就能像坐上了轨道一样，显著地缩短开发时间的感觉。

我觉得这很高效。
（我感觉没有很多困难点。）

直觉的

我觉得Vue.js的设计包括API都是为了能够直观地操作。

只要掌握了理解Vue.js的关键要点，任何人都能在短时间内达到一定的掌握水平。

由于周边库的设计都非常直观易用，因此只要理解Vue.js的基本知识，就能轻松掌握并运用到一定程度。

设计师友好的

Vue.js 可以自然地（只要不进行奇怪的写作的话）将设计和逻辑分开。

HTML模板中（除了部分原因），不会包含JS，因此可以请设计师编辑。

对比React

反应：潜在的学习成本

如果只是使用React（包括React中包含的基本功能），学习成本和Vue.js相比是较低的。但是，仅仅使用基本功能是不足以创建单页面应用程序的，一旦开始涉及到Redux等内容，学习成本就会急剧增加，这时候Vue.js就会远远落后于React。

只需要一种选择，以下是对原文的汉语真实翻译：

在React中，组件是基于类组件和函数组件的，它们具有不同的生命周期方法。

在React中，对于函数组件的编写有两种方式，一种是使用React.FC，另一种是不使用。

在 React Hooks 出现之前，类组件是流行的，
在 React Hooks 出现之后，函数组件变为流行，
看起来是这样。

React Hooks是一组用于简化函数组件编写的功能，它使得之前只能在类组件中使用的功能也可以在函数组件中使用。

用于描述函数组件的API有Hooks…
如果命名为React Function API之类的，名字会更能代表其本质吧…

在React中，虽然推荐使用函数组件来编写公式，但选择使用函数组件或类组件取决于用户。

自从引入了React Hooks以来，学习成本似乎朝着改善的方向发展，但实际上并非如此。

使用React Hooks的函数组件的项目，使用类组件的项目，以及函数组件和类组件混合存在的项目。因此，需要学习函数组件和类组件两者。在项目中，基本上要么统一使用其中一种，但如果使用了外部的组件集合，可能有一些情况外部组件集合与项目方针不一致（也考虑到从其他项目中复用的组件）。

回应：周边库的增强和缺乏事实

React和其周边库的功能非常丰富，这是很好的一件事情。
然而，很多时候也存在很多重复发明轮子的情况，即使是用于同一目的的多个库同时存在。
而且，还涉及到函数组件或者类组件等不同的组件类型，导致整体感觉非常混乱。

只需用基于React的框架，有Next.js、Remix等…

Next.js和Remix都是基于React的框架，但写作方式有相当大的差异。
（Next.js支持CSR/SSR/SSG/ISR，而Remix仅支持SSR，
设计思想本身也存在差异。它们给人一种相似但又不完全相同的感觉。）

在看了Next.js和Remix的简洁性后，我们在版本13中引入了App Directory（应用程序目录）并将其设为默认，以便将舵转向默认的服务器端渲染（SSR）方向。

在状态管理库中，有一些选项可供选择，如独创的Redux/Zustand、基于React Hooks的Jotai/Recoil等。

在某些时期，我认为Meta的工程师开发的Recoil可能成为React的状态管理库的事实标准。但是，由于Recoil仍然在作为实验性库进行开发，并且尚未达到1.0版本，因此它并没有成为事实标准。根据每个React应用的开发团队的喜好，他们可能选择Redux/Zustand/Jotai/Recoil等的其中一种。目前的情况是Recoil并没有成为事实标准，这可能是因为它的主要开发者已成为Meta的裁员对象，导致开发停滞不前。

使用框架和相关库（例如状态管理库等）的组合，学习成本会有所变动，并且还会产生额外的学习成本。

反应：总学习成本

我认为相比于之后提到的Angular(1.x)，在构建Web应用程序方面，React的学习成本更高。

在世界上，有些人喜欢选择学习成本高的东西来学习，他们认为能够理解复杂的×××的人很厉害。然而，选择学习成本高的东西却没有必要是浪费时间的。

React开发团队似乎不太适合将方向朝着用户易于理解和使用的方向发展，无论是查看文档还是浏览网站，都有这种感觉（有一些过于复杂的写作）。

比较

由于Vue.js的状态由VM(View Model)管理，所以并不一定需要使用状态管理库。如果需要使用，可以选择Pinia（或Vue.js 2.x的Vuex）或useState（如果使用Nuxt3，则与React的useState不同）。

Vue.js 只有函数组件一种类型。

在Vue.js的函数组件中，有两种描述方式：Options API的描述和Composition API的描述。

为了推动向3.x版本的迁移，Composition API在3.0.0中被引入，并且自3.0.0以后被推荐使用。它也已经被移植到2.7.x版本中。

从3.0.0版本开始，Options API似乎被保留了下来，以确保向后兼容。

在2.x.x版本中，尽管官方提供了对类组件的支持，但是需要额外使用Vue.js提供的库（Vue Class Component (+ Vue Property Decorator)）来实现。

伴随着3.0.0版本的推出，引入了与之前的Options API不同的新API，即Composition API。因此，从3.0.0版本开始，官方不再支持类组件。

2023年3月23日，Vue Class Component 的废止正式宣布。
https://github.com/vuejs/vue-class-component

我认为Vue Class Component在Options API的基础上，无法与被建议使用的Composition API实现兼容性（开发停滞→）也是其被废止的原因。

在3.0.0版本的开发过程中，Vue.js主体中的类组件内置功能被考虑，但随着React Hooks的出现，引入了Composition API的提案。结果，类组件内置功能被放弃，Composition API被正式采用。

基于Vue.js的全栈框架只有Nuxt一种选择。

由于Vue.js3和Composition API的全面改进，Nuxt3在2022年11月16日的发布中，在功能和性能方面已经与基于React的框架相当。

Nuxt3进行了根本性的架构审查（重新设计），并且与此同时，还进行了相关库的开发，这就导致了发布3.0.0版本花费了一些时间。从3.0.0版本开始，它转向了增量开发。

除了组件库之外，周边库很少进行轮子的重新发明，并且与采用它们之一相关的学习成本也微不足道。

反應：復雜性的漸增

我觉得React和Angular（JS）一样，将服务器端的设计思想引入到了客户端。

React在JS中心且建立在WEB标准之上，给人一种React独特的世界（React World）的感觉。

我认为在React中没有像Vuejs的2.x→3.x版本中引入Composition API那样的重大变化，而是持续进行渐进的变化。然而，由于这种渐进性，逐渐感觉到复杂性正在增加，尤其是考虑到周边库的情况。

本来优点是简洁性的，但在web应用程序开发中，为了逐渐满足各种需求，外表看起来简单，但内部却相对复杂，需要用户一定程度的了解才能避免意外陷入困境。

尽管已经过去了将近一年半，但仍然没有在研究水平上提供优化编译器React Forget、Meta的实现。该编译器目前正在部分领域进行试验性引入(测试)，如果一切顺利，可能在一年内提供，并对解决React的复杂性起到一定作用。

React: RSC（React 服务器组件）、服务器操作

React的RSC和Server Actions的出现也增加了React（包括周边库）复杂性的上升。

目前现有的React状态管理库是用来管理客户端状态的，没有管理服务器端状态的功能。(是否还会被扩展以管理RSC的状态？)新的库，如nrstate/nrstate-client等，正在出现，可以管理RSC的状态。

我认为在包括RSC在内的状态管理方面，还没有明确的标准，这种混乱的状态可能会持续一段时间。

尽管RSC和React的官方都标记为不稳定（α版本），但采用RSC的Next.js的App Directory（App路由器）却变得稳定了，这真是太混乱了。

服务器的操作也可以使用React的官方版本是不稳定的（α版），而在Next.js 14中则是稳定的。

RSC的规范是由Next.js的开发公司Vercel参与制定的，而Remix开发团队并没有参与其中。因此，Remix开发团队的成员试用后发现，RSC比Remix的当前实现要慢，因此在RSC稳定（实现/规范更加成熟）之前，不会采用Remix。

以下是大约1.5年前由Remix开发团队成员撰写的有关RSC的评价文章。
https://remix.run/blog/react-server-components

RSC、即React的服务器端/客户端端，能同时在两边运行的组件，
为了让这些服务器端运行的组件在React的组件树上都能处理，
Remix作为一个SSR框架，可能没有采用它的优点。

目前，只有Next.js这个著名的React框架实现了RSC，并且其实现方式（App Router等）被视为稳定，但仍存在性能问题，无法称之为十分成熟的状态。因此，在考虑引入RSC到正式环境之前，最好进行性能等方面的测量以作判断。

近日，有关Remix的RSC支持的最新消息在v2版本的发布公告（官方博客）中提到。看起来，他们已经开始开发v3版本以支持RSC。Remix开发团队表示将与他们合作，以稳定RSC。据悉，Remix的加载器/操作功能在v3版本的RSC支持下会有一些外观上的变化。

 

这个RSC看起来像是一个正在发展中的规范/实现。

在基于Vue.js 3的Nuxt3中，需要考虑编写代码时是作为客户端（仅在客户端上运行）组件、服务端（仅在服务器端上运行）组件还是同时在客户端和服务器端上运行的组件，但不同于React的RSC周围的复杂性和混乱。

回应：CSS的处理

在采用React的项目中，使用了各种不同的样式化方法。

CSS、CSS模块、CSS在JavaScript中、CSS框架（如Tailwind等）是指的。

在“CSS in JS”中，通过JavaScript来编写CSS的属性。

在CSS in JS中，有两种类型：在运行时生成CSS的运行时CSS in JS（如Emotion、Styled Components等），以及在构建时生成CSS的零运行时CSS in JS（如Linaria、vanilla-extract等）。

在RSC项目中，由于许多运行时CSS in JS无法正常运行，因此选择了RSC的项目，在选择了运行时CSS in JS的情况下，需要转向零运行时CSS in JS或其他样式技术。

在中文中，没有固定的样式化方法，所采用的样式化方法取决于开发团队每个核心成员的个人喜好。

如果参与使用没有经验的造型技术的项目，
那么就会产生相应的额外学习成本。

在Vue.js中，CSS和JS被明确地分离。

在中文中进行重述的选项：
不会采用CSS in JS，而是通常会将CSS写在CSS文件或style标签中，当然也会使用CSS框架（Tailwind等）。

如果参与的项目使用了没有经验的CSS框架，则会产生额外的学习成本。

只要了解CSS，学习CSS框架的成本应该就不会太高。

反应：Meta駆动？

React 很像正后面提到的 Google 驱动的 Angular(JS)，它们都充满了元驱动和思维驱动。

由于Meta团队中涉及React的工程师也是裁员的对象，因此React可能不再是Meta战略上重要的产品。

由于Meta的React工程师在Next.js开发者Vercel公司内离职了很多，所以可能在不久的将来，React将会被Vercel驱动。

由于Meta（Facebook）对于PHP的性能等方面不满意，他们开发并采用了类似于PHP的另一种语言Hack，因为他们非常注重性能。因此，他们在性能上的优势开始下降，而对React在公司内部的承诺和尊重也可能下降。

由于React在外部广泛使用，内部使用React对其他公司在性能等方面没有优势，并且没有从React中获得任何收益，因此对于Meta来说，继续投资于性能下降的React没有什么好处。（Meta的React开发团队成员也成为了Meta裁员的对象。）

如果像Meta这样的公司正在开发开源软件，由于管理层的决策，有可能导致内部开发团队被缩减或废止，因此需要注意。

只因大企业在开发/支持这一点，并不意味着一切都很稳固，
我们需要意识到可能会突然失去支持的风险。

尽管React的特点一度是简单性，但综合来看，React周围的现状已经变得不再简单。

如果选择在WEB应用中采用非简化的方式，开发成本也会增加。开发成本已经增加了，同时性能上的优势也降低了，因此，对于React开发来说，Meta继续投资和承诺将变得困难。

根据Mata公开的开源项目包括Go语言开发的OR包，可以看出Meta在服务器端也采用了Go，并且全面推崇React的RSC，在JS（TS）中搭建服务器端（全部）似乎并不是他们的意图。

根据Shopify收购了Remix并投资于Rails（Ruby）的改进作为后端框架，可以看出他们在全公司范围内推行Remix，不太可能用React + JS（TS）来构建全部的服务器端。

无论是Meta还是Shopify，从前端(+ BFF) + 后端(WEB API)的架构来看，它们都不适合以JS(TS)构建整个服务器端。

和 Angular(JS) 相比

1.x的设计已经过时。

Angular（JS）给人一种感觉，就好像将服务器端的设计直接搬到客户端。

我认为将数据以全局变量的方式处理的作用域（$scope）是其中之一的证据。

在客户端（UI应用程序）中，Vue.js的模型驱动比AngularJS（1.x）的控制器驱动更合理。

我认为AngularJS（1.x）不适合中大型开发。
虽然它针对大规模开发，但并不适合中大型开发。

AngularJS(1.x)是在2009年推出的框架，根据当时的设计，在2012年发布了1.0.0版本。2009年当时，W3C开始制定WebComponents规范，但正如我们所了解的，全球网页开发的潮流正在发生变化。AngularJS(1.x)的设计已经与当前需求背离了。

对于能否被类比为Rails的事物的疑问

我不认同将AngularJS与Rails进行比较的说法。

相似之处在于它们都是全栈框架，都需要花费很多时间学习。

在学习Rails初期，其学习成本相对较高，但一旦掌握并适应了它，将能大大缩短开发时间。

然而，AngularJS却不然，尽管它的学习成本较高，但由于没有规定好的框架，因此无法实现显著的开发时间缩短。

在2.x版本之前，Rails就像AngularJS一样，由开发团队从头到尾负责开发和组织各种模块，并与其密切关联。但在3.0版本中，由于DHH的明智决策，将被认为是轻量级的Merb与Rails进行了整合，尽管它仍然是一个全栈框架，但它变得可插拔。这样一来，可以灵活地组合和选择外部开发的模块，3.0版本之后，越来越多的外部开发库也被纳入到Rails中。

然而，AngularJS是一个完整的整体，不打算与其他框架和库灵活地组合使用。

Vue.js并不是一个完整的堆栈，它将自己的范围限定为一个框架，专注于视图相关的功能，而不包括视图以外的功能。它的前提是与适用于特定目的的专用库结合使用，并且可以灵活地选择组合的库。

谷歌是个以品牌为核心且由社群推动的虚拟存在。

我不禁觉得Google的信徒们把神、佛、Google放在一起，更看重的是品牌而不是品味。

Angular(JS) 是一个 Google 开发的框架，除了调试之外，从1到10都是由一个小团队的 Google 工程师负责维护和开发。这个框架的组件基本上也是由Google工程师进行设计和开发，可以说是Google制造的框架。

换句话说，Angular(JS) 是由 Google 驱动而不是社区驱动的。

从个人角度来看，我认为Angular(JS)可能是Google在GWT（Java→JS）之后的继任者。

从2014年的Google IO大会主题演讲来看，我认为在Google内部，Polymer（Lit Element的前身？）似乎是作为GWT的继任者位置，但实际上并非如此。

只有 Angualr(JS)2.0 的设计资料提到了1.x的问题并提供了2.0的设计指南，但并未感觉到其积极与开发社区开展规范讨论的氛围。

即使在2.x版本上，它看起来也是一样的。

对于Angular(JS)的未来，有一个担忧。

看起来，Google正在降低Angular（JS）在其内部的地位。

从目前来看，Angular（JS）在谷歌公司看来并不再是战略上重要的产品。

我认为谷歌不太可能在Angular(JS)的开发上投入比以往更多的开发资源了。

Angular（JS）似乎仍然是由Google驱动的。

考虑到推送功能，如果Angular（JS）在2.x版本之后不能实现与Web Components规范的高度兼容性，Google可能会放弃使用Angular（JS）。

因为是由Google开发，所以称之为Google驱动，并非其他原因。
这是一个由Google资助的开源社区分离开发的项目，可能出于战略意图。
直到产品进入β测试阶段之前，不会对外公开，所以才称之为Google驱动。

Google驱动的开源软件产品通常不会在进入基本的β测试阶段之前进行公开。在这个阶段，产品设计已经基本确定，开源社区无法对设计进行干预。

我认为对于谷歌而言，开源社区只是测试员和调试器，不仅如此。

尽管谷歌似乎对开源软件非常了解，但与其他将产品作为开源软件公开的公司没有任何不同。

以下是原始文本的同義詞中文翻譯：

對比

尽管 Evan You 是 Vue.js 的开发者并且曾是谷歌员工，
但 Vue.js 的开发最初其实是他个人的项目。
(目前已转变为团队开发模式。)

(Lit Element(Polymer的后继)并没有标有”Powered by Google”的字样，但这是根据Google I/O上的宣传内容，它是由Google推出的战略产品，由Google驱动的。)

由于Google对于保密性要求很高，因此在Google驱动下，一般情况下在Google I/O等活动上宣布之前，几乎不会有信息外泄到外部。

考虑到Angular（JS）和LitElement的功能和用途重叠，再加上Evan You离开了Google（是否可能回归未知），因此我认为Vue.js不会成为Google推动的项目。

有人以Vue.js是个人项目为借口，写出类似表达对其未来感到担忧的文章，不过我觉得他们可能不知道Linux最初也是个人项目。即便是Evan You先生有什么变故，我相信会有其他个人或者企业接手开发。

有些人可能认为，由企业主导的开源软件是可靠的。但是，由于企业的盈利目标，即使它们在起初是主导者，但由于经营决策的原因，经常会撤出。而一旦被撤出的开源软件将没有开发和维护人才存在，最终会衰退或消亡。

2.0版本的开发迷失不前

根据2.0发布时的设计资料可以看出，Angular(JS)在2.0版本中经历了很多改动，与1.x相比有很大的变化，这一点是确定的。

已经是一个巨大的全栈框架，2.0版本的发展不确定，过于重视向下兼容而不是创新，导致开发可能陷入停滞状态。

由于Angular2.0开发的目标是还没有完全实现的JS规范，即ES6+ES7的一部分加上一些新特性，可能考虑到这个挑战对Angular (JS) 开发者来说是有趣的，不过也存在发布需要很长时间的担忧。

在实施ES6的运行环境时，人们对于在实施的过程中可能需要进行大规模的回退也感到担忧。

尽管有ES6到ES5的Traceur编译器，但由于缺乏ES6的可执行环境，它尚未达到实用级别，直到主要的浏览器完全实现了ES6，才有可能发布正式版。

尽管ES6的规范本身被冻结，但为了反映规范发布时的审查和实施反馈意见，该规范在2015年6月被延期。一些功能，例如Object.observe，原本计划在ES6中引入，但被延迟到ES7或之后被实现的可能性非常低。随后，Object.observe从规范中被移除。

ECMAScript 6 实现情况
http://kangax.github.io/es5-compat-table/es6/
traceur-compiler 入门

尽管只有少数工程师参与开发，但他们却能实现全栈开发，这也让我感到项目的开发可能会变得很长。

Web Components规范的支持和独立的UI组件在2.0中能够创建，这在谷歌品牌中将是不可或缺的，同时也预示着开发周期的延长。

鉴于在发布时还未确定发行时间，几乎可以肯定的是，与1.x相比，Angular(JS) 2.0的更改不会很大，也考虑了早期发布的实现。

如果那样的话，Angular(JS)2.0将被淘汰并消失，
无法适应变化的框架无法幸存。

2015年3月，Angular 2.0的开发中进行了大规模的变更。

当初计划使用Traceur编译器将ES6转换为ES5进行开发，但由于Traceur的转换能力没有达到预期，因此决定开发一个名为AtScript的AltJS，将ES6的部分功能嵌入到基于ES5的版本中。此外，由于自行开发会耗费时间，并且要达到稳定可用的水平也需要时间，所以决定将AtScript的开发合并到由微软主导开发的TypeScript中。

跟踪编译器（Google）→ AtScript（Google）⇨ TypeScript（微软）。。。

在Angular2.0开发中最令人担忧的问题是ES5和ES6的兼容性，现在该问题已经得到了解决。

根据这项开发方针的变更，Angular2.0的发布时间也在2015/03时点宣布为明年。

Google宣布Angular2将由微软的TypeScript进行开发。
http://www.publickey1.jp/blog/15/googleangular_2typescripttypescript_15ecmascript_6.html

考虑到Google在Angular上投入了大量的人力资源，虽然还存在其他的顾虑因素，但我认为选择Angular是一个合理的决定。Angular 2.0之前过于复杂，从人力资源的角度来看，开发周期不可避免地会延长。

我认为在这个发布时点，Angular 2.0可能还处于设计阶段或初期原型阶段，因此在这个发布之后也难以预测。

如果像AngularJS(1.x)那样，采用纷繁复杂且临时性的设计，与所带来的好处相比，学习成本会变得非常高。

之前有提到的顾虑，但在2016/09/14，Angular2.0已发布。

2.0版本的规格提案？这个预计的vDOM支持因为要早期发布而被搁置了。

在 Angular 当前的路线图中，并没有明确提及对 vDOM 的支持。

是2.0版本的发展迷失了方向，导致Angular在2.0版本之后似乎没有增加革新性功能。

学习成本的效益与成本比率

Angular（JS）的一个缺点是学习成本很高。

由于Angular(JS)是一种深度绑定的框架，所以即使投入大量学习成本，如果离开Angular(JS)，所学的知识几乎没有什么用处。

自从Angular 2.0起，Angular和AngularJS（1.x）是两个不同的东西，因此1.x的知识和技巧几乎没有什么用处，导致迁移成本非常高。

如果你已经在使用Angular(JS)做工作，或者已经决定要做Angular(JS)的工作了，那么现在学习Angular(JS)就是浪费时间。

如果你是为了将来工作而学习的话，不应该去学Angular(JS)，而是应该去学习其他更有意义的事情。

Angular(JS)的学习成本如此之高，以至于它已不再具有吸引力。

在这个世界上，有些人会特意选择学习成本高的东西来学习，他们认为能理解复杂的×××的人很厉害吧？然而选择学习成本高的东西却没有必要，只是浪费时间而已。

因此，选择使用Vue.js

目前，在受欢迎程度方面，Vue.js 已经超过了 Angular(JS)。

目前来看，Angular（JS）比Vue更先进且具备完整的技术栈。
虽然Vue仍然很受欢迎，但由于Angular（JS）是一种封闭式的技术，因此开发2.0版本花费了一些时间，现在它正在迎头赶上，这是我之前提到过的。

我之前写过，由于Angular2.0及以上版本的学习成本更高，因此Vue.js通过插件补充并不断进化，弥补了与Angular(JS)相比缺失的功能，我觉得它有可能超越Angular在全球范围内的受欢迎程度。

因此，我們可以使用 Vue.js。

我喜欢作为一个库的设计，它类似于AngularJS，相比AngularJS，开发者感觉更加友好，而不像React.js，Vue.js更加友好于设计师，我支持它。