深以为然！

为什么我建议前端框架优先选 Vue 而不是 React

https://acejoy.com/2022/03/10/675/

我两者都用过比较长的时间。网上各种“为什么我选React放弃了Vue”或者“为什么我选Vue放弃了React”之类的文章很多，实际都没什么用，必须要真正上手做项目才会感受到它们的使用体验差别。因为有些文章本身就是带有倾向性的 – 听说过“布道师”这个职位名称么？

从我个人的使用体验看，选用Vue更省力省时间，用React明显麻烦的多。有人可能会争辩：React使用熟练一样很快！是，可是要注意，我这里说的不是绝对的开发速度，而是说同样的功能，使用Vue对比采用React，是指相对而言，哪个省事儿。用React，你得有足够的时间，足够的人力，足够的技能和耐心。用Vue开发成本低的多。

多方面粗略比较下，想起来了后面再补充：

使用难度

Vue框架是可以渐进使用的，开发门槛明显比React低很多。你可以直接在html文件中引入Vue的编译包，看下入门文档，稍微处理下代码入口就可以愉快的使用了，非常轻快。后续需要引入其它的组件、模块，也是比较容易的。它的设定更符合习惯，它没有发明太多的概念和独特的用法。Vue采用了清晰的三分法处理组件功能：结构 – template，功能 – script，表现 – style。这些概念符合开发者对html的习惯认知，理解起来毫不费力。

React不行，你至少得看完官方的一整套文档，这里：入门教程 ，然后在充满困惑和挑战中起步。别担心，后面等你爬的山还有很高。每个山头的路都很长，文档够你啃半天的。

究其原因，React框架并不是一个单纯的UI库，它创造了一个庞大的技术栈，里面充斥着各种新思想的试验品和废弃物。它发明了很多新概念，对Web技术的发展是有巨大贡献的，但是不等于说，里面的东西都是获得大家认可，都喜欢的。而且它也没什么标准一说，所有组件自由竞争。这是它的优点也是槽点。优点是总有新东西不断涌现，缺点是你需要学习和挑选。

因为是后起之秀，Vue的社区没有React的大，所以一些组件支持不如React的多，这个要承认差距。不过社区正在逐渐追赶中，差距在缩小。

设计思路

使用React，可以看做是，用户不断的修改、计算组件的状态，然后让状态从上到下流动下来，重新渲染出正确的界面的过程。因为React坚定的使用单向状态流这个模式。它是有好处的，只要状态一致，结果必然一致，可重复，非常可靠。问题在于使用过程并不怎么愉快。很多操作显得很机械、呆板，只因为规则规定如此。

状态管理是前端里面的重要内容。React的状态管理比较麻烦，redux没那么容易使用。自带的setState不是很简单么？哪里，这个小功能的坑是很多的，比如异步，比如更新后中途又被冲掉等等。

Vue的状态管理则容易很多，官方直接做了一个库，相对于React，估计10%的难度都没有。估计是跟作者开发使用过另外一个出名的前端框架：Angular有关系。Vue吸收了Angular的很多优点。

双向绑定功能是Vue的一个设计，一些其它前端库也有这个能力，但React是没有的。别小看这个小小的功能点，它影响很大。不信，你自己做一个表单，实际手把手的试一下，这个事儿带来多少的麻烦。保守的说，支持双向绑定功能，可以节省40%以上的代码量，而这些代码大部分都是机械代码，没有什么技术含量。有人说可以用别的方法模拟出来，但它毕竟不是官方的支持。

有个简单的例子，React表单输入，把输入转换成数字，这个事儿其实比想象的复杂，很容易出现bug，不信你试试看。Vue支持双向绑定，就不存在实现的需要。

**React倾向于使用受控组件，这大大加重了开发负担，特别是对于比较复杂的系统，更为明显。**所谓的“受控组件”，是自己管理这个组件的一切，包括行为、外观等等。相比之下，直接使用标准的HTML5组件 + CSS修饰，要容易的多。受控组件可以管理一切，但是你也得自己DIY一切，利弊自己体会。

使用React，你会发现总要不停的拆分组件，拆细，然后一堆参数传来传去。这个有好有坏。优点是拆细的组件可以实施单一职责，降低复杂度，缺点是管理麻烦。这在工程实践中，需要平衡的。

与React自创的jsx语法不同，Vue使用的是模板-Template模式。这个更符合通常的习惯。特别是以前做过后端模板开发会更为熟悉，它就是使用数据来渲染骨架里面的细节，得到可以展示的结果。React自创的jsx还有一套规则需要学习。

更进一步，React社区鼓吹“CSS-in-JS”。这个设计引发了很多争议，使用不是不可以，负担更加沉重。因为你无法按习惯的CSS模式编写样式了，需要按各种五花八门的实现规则来书写。这个地址有部分讨论：前端

还有一些UI框架，也是追随了React的模型，全部是受控组件，你需要熟悉框架的设定才能使用。而与此相对的实现是工具型。比如tailwind css。它的理念就是工具化，所有的设定都是用CSS Class实现。这个使用起来难度大大降低。

如果使用Vue，最容易选择的就是工具类UI框架。

React发展了很久，有一些历史包袱。比如最新的版本开始摒弃过去的React.Component实现模式，大力推广React.Hooks。我使用起来，感觉后者明显比前者优越，可是你又多了一个学习成本，外加一个选择困难症。

粗略估计，如果你的工程使用React实现，总体成本可能是使用Vue实现的5倍以上。计算方式：React的难度 + 组件开发难度 + UI框架使用难度 + CSS使用难度 + 其它杂项。

看到这里，可能读者会认为我一直在贬低React，鼓吹Vue，并不是这样。React足够伟大，它的创新足以在历史上留下浓重一笔，我非常的欣赏。但是别忘记，它是Facebook根据自己的需求，创造、开源、开发的，请记着这个起点。你的工程有Facebook大么？你有Facebook的工程能力么？恐怕没有几个能做到。同样的问题一样适用于谷歌。谷歌做出来的东西，即便很好，也未必适合所有人。它的起点是适合自己用。没有它的体量和工程能力，贸然使用往往跌入大坑。

为什么是 JavaScript？

https://acejoy.com/2017/05/17/248/

注：这是2015年写的文章，JavaScript还在疯狂的朝着各个领域进军。而JS自己，也在迅速的改进。更新的版本，具备更好的操作能力，更适应新一代环境的需求。想起那句话，不知道谁说的了：只要有足够的需求和时间，原本坏的也能改进成好的。拭目以待吧！

我从事软件开发的相关工作，已经有15年了。目前的工作，主要集中于Web和移动应用方面。在这么多年里面，我对javascript的态度可能会代表一大群程序员的看法：从一开始对js的不屑一顾到最后惊奇它的表现和潜力。

Javascript的创造者：Brendan Eich，在今年年5月份做了一个PPT，回顾了js语言的创造过程和这20年的发展、前景。地址在：http://brendaneich.github.io/ModernWeb.tw-2015/
10天设计完js的感受

Brendan Eich： 10天设计完js的感受

在2000年那会儿，我也从事过一段web应用开发。开发平台是Windows，主要使用Asp。那个时候的javascript，主要用途是检验页面输入数据是否正确，错误的时候，弹出个警告窗口。整个Web开发、应用环境，实际上都是十分简陋的。Web开发者看待javascript，估计就如同玩具一般。因为它能做的，真的是十分有限。如果你能找到2000年时候的有关js的IT图书，内容多半大同小异，充斥着告诉你怎么用js做个什么跑马灯，怎么制造烦死人的弹窗，如此这般。这些内容也进一步抑制了大家对js的期望。

后来，我转向C/C++，因为“真正的程序员使用C++”。这一转身就是很多年，我对js的印象，也就止于那点功用了。

这几年，因为种种变化，我又转回来了。这个时候再回顾Web开发，已经可以用天翻地覆来形容。相关的概念，层出不穷。发展出的各种技术、工具，五花八门，让人眼花缭乱。而且更要命的是，这些知识除了基础的几类，大部分都十分的不稳定，迅速发展、以疯狂的速度淘汰更新。今天还在用的工具，可能明天就有更新、更好的了。

为什么会这样，因为社会需要的热点在这里，需求推动。这个社会的生活、生产，逐渐转移到了网站上、移动端，这就是这些领域快速发展进步的主因。

这个时候再回头看当年的玩具语言 – javascript，早已今非昔比。它已经成长为网络时代不可或缺的前端顶梁柱。现在已经不可想象没有js的网站，是否还能正常运行。不仅如此，它的触角居然还深入到了后端服务，Node.js方兴未艾。一些新一代的产品，如MongoDB，甚至内置了js语言支持，作为应用交互的工具。

这是很多人都无法想象到的情景，包括我在内。对此，我不得不回过头看一下，思考javascript为什么会拥有现在的地位？

Javascript的总体设计有亮点，这稍后再说。但问题也很多，它是作者在10天内设计出来的。因为时间仓促，很多细节未及推敲、深思熟虑就推上了市场。未经打磨，以至于充斥了漏洞、糟粕。Douglas Crockford在《Javascript语言精粹》（英文名：Javascript: The Good Parts）里面提到：“Javascript中糟粕的比重超出了预期。”连Brendan Eich自己都说：”与其说我爱Javascript，不如说我恨它。它是C语言和Self语言一夜情的产物。十八世纪英国文学家约翰逊博士说得好：’它的优秀之处并非原创，它的原创之处并不优秀。‘（the part that is good is not original, and the part that is original is not good.）”

但是，似乎是在冥冥之中注定，Javascript在一开始就抓到了未来编程语言的方向：函数式编程。Crockford大叔说：”Javascript设计的最出色的就是它的函数的实现。它近乎接近于完美。…… 函数在javascript中是顶级对象，它是第一个成为主流的Lambada语言，它是披着C外衣的Lisp。”读过那本《黑客与画家》的人，都会记得作者的预言：Lisp才是语言的终极趋向。

这几年，函数式编程有流行的趋势。函数式编程并不是新发明，它的历史甚至比一些主流语言还早。因为性能和实现等问题，一直饱受冷落。而如今，计算机的硬件性能大大提高，改变了很多事物。原本不够经济的，变得可行；原本不够好的，在新条件下变得不错。鉴于函数式编程的优良特性和强大能力，它的流行其实并不意外。过程化->面向对象->函数式，这个应用开发范型发展趋势是可以预见的。这些年，脚本语言大行其道，使用Python/Ruby/PHP代替原本静态语言开发的应用比比皆是，传统的C/C++应用开始逐渐缩减到桌面应用、高性能服务器应用、驱动、系统接口等领域。因为大部分的应用的性能已经不是问题，CPU相对过剩，I/O、网速才是瓶颈。人们更重视开发效率。Javascript因为一开始就有这样的设计能力，把握住了技术的先机，紧随了这股浪潮。

运气也不可或缺。搞技术的会知道，世界上的编程语言至少也有个几百种。一种语言想获得认可并得到流行，光有好的技术设计是不够的，它还需要位置乃至契机。它要找到适合自己应用的领域，深深的扎下根来，并以此为基地，向外伸展。这个时间，有时候需要20年以上。比如PHP专注于Web开发，C对于系统开发不可缺少，因为接口都是C。Python在科学计算、网络编程有诸多应用。在2004年，Javascript得到了一次契机：Google推出了使用Ajax技术的Gmail邮箱，那堪比桌面的无刷体验，引发了业界轰动和模仿浪潮。Ajax的操作核心，就是Javascript。此后，js在浏览器中的地位变得十分稳固，已经成了事实标准。在2009年，基于Google强大V8 js引擎的Node.js出现了，它意味着js向其它领域开始进军，发挥它的语言威力。微软当年也宣称在服务器端可以内置支持jscript，不过这完全不可比。

网络时代的需要，Javascript捷足先登。浏览器一开始就绑定了js脚本技术，这让它取得先发优势。当年的浏览器大战后，微软的浏览器占据统治地位，IE里面是可以编写vbscript的，但微软在网络时代的停滞不前，丧掉了很多机会。因为网络带来的低成本信息交互以及更低的开发、部署成本，越来越多的产品基于浏览器做为界面。js在应用开发上，当仁不让。业界出于需求，制定了几版相关的技术标准，比如HTML、CSS、JS，都有了自己的位置和开发标准规范。相互紧密协作，融为一体。Web应用开始侵蚀以往的桌面应用。只要应用领域有足够的渴求，原本有很多不足的东西也会获得强大的推动力，把它改造的更好。

最后，借用Javascript创造者的话结尾 – My advice: always bet on JS.