今天被人追着嘲讽了一下午。有些情绪不吐不快。
经常写公众号，有一个非常大的好处，就是当你慢慢有一点人气之后，你就可以看到人生百态。今天要跟大家讨论的话题，就是关于技术方案意见不同时，如何相互讨论的问题。
我写公众号文章，有一些自我要求：
1、 尽量写得更简单一些，让认真看完的人都能够参与进来讨论 2、 尽量明确自己的技术态度和技术主张，好与不好，都态度明确 3、 尽量分享自己的心得成长，做到简单、但有用、有深入思考的可能性
✓当然，我也不是没有尝试过写得深入一点，让大多数人都看不懂，这样可以显得自己高深莫测。但结果反响平平，这不符合做公众号自媒体的逻辑。因此逐渐尝试和调整形成的这些自我要求
当我明确的表达了技术主张和观点之后，自然就会有很多人有不同意见。实际上保持不同意见并不是什么坏事，在我看来反而是一件很好的事情，因为不同的思维碰撞往往更容易激发进步的可能性，能让我们保持多维度的思维方式，碰撞中对技术的理解会更加深刻。
但是呢，在这个过程中，我发现，其实有的程序员，也许本身的技术能力挺强，至少对自己还挺自信，可惜，表达方式和表达能力一言难尽。言语中非常喜欢透露出一种，类似于：你这都理解不到，你真的好菜鸡的语气。
说好听点，叫做不到求同存异，说难听点，就是素质低，思想道德没跟上。就比如像这种，明里暗里试图就是要嘲讽贬低他人来抬高自己装个 B
许多关于技术探讨引申出来的骂战，都是由此演变出来的。
一、不同意见的技术探讨本可以碰撞出更多的火花
我曾经参与过一些由各大厂名校程序员组织在一起讨论的技术探讨会。这种参与人员技术水平相对偏高的讨论会，理论本应该可以有更多的技术探讨空间，碰撞出更多的火花，但是其实恰恰相反。
整体感受下来，主要是两种气氛。
一种就是浅尝辄止，一团和气【这种情况比较多】。很多时候无法进行更加深入的探讨。至于原因，别的人我不知道，但是我当时自己存在的想法就是：有一点担心暴露自己技术上存在短板和缺陷，有一点心里包袱，问的问题不够刁钻，参与度不够深入
另外一种就是夹枪带炮，甚至演变成对喷。
实际上，有不同的技术主张是一件非常正常的事情。但是，有的人就非常容易带入一个视角：如果别人不理解我的观点，那么这个人的技术水平是一定有问题的。所以，我就不由自主的要嘲讽一下他。
就比如，我曾经在技术讨论沙龙里表达：我觉得，signal 代表不了前端发展的未来，也代表不了先进，他只能算是前端框架里其中一种解决方案。
于是，就有某大厂的大佬嘲讽我说：你被 React 毒害洗脑太深了，现在还陷在 React 那一套逻辑里，其他所有的前端框架都把底层重构成了基于 signal，甚至 signal 的标准化进程也在推进...
先嘲讽一顿，然后开始表达自己认为对的观点。很显然，为了避免当面撕破脸，我就退出了这样的讨论，毕竟以后再也不可能与这样的人聚在一起讨论问题了。
事实上，关于这个话题，我还有很多观点想拿出来讨论，但是他一开启嘲讽模式我就觉得没必要了。
例如：在大数据大列表之下，signal 的表现不一定比 diff 更快，甚至有可能是更慢的。同样底层基于 signal 的框架，也有不同的性能表现，其中的优化细节还是挺多的。如果 signal 变成了浏览器标准，他的性能表现也不一定比 solidjs 的处理方式更好。深度监听本身就是一个性能压力比较大的场景，并不是说，交给浏览器来做，就一定有更好的性能表现，就跟 Proxy 在chrome 和 safari 中的性能表现差异非常大一样，signal 交给浏览器来做，大概率也会存在相同的问题。甚至，如果框架开发团队愿意做的更多，充分利用编译手段，在性能表现上，还有比 Proxy 在性能上更激进的实现方式：未来大家可以关注一下华为团队研发的 openinula.
!还有，框架开发者，不一定比经验丰富的框架使用者更懂应用场景。而且，这是一个大概率事件。就跟你开发的软件，你没有你的用户用得多一样
所以并不是说，前端圈的技术讨论氛围诡异。
而是很多人根本不知道如何跟不同技术观点的人讨论。只要一旦觉得别人的意见可能有问题、错误、漏洞等，立马摆出一副他是 sb 的姿态开始发表意见。一副要装一波的原始冲动怎么都压制不住。
且先不管我的这些观点和想法是对或者错，当你不懂得如何跟技术主张不一致的人沟通的时候，那么沟通氛围的后续发展一定是与技术关系不大的，演变成互喷的概率会很大。
二、求同存异是我的追求
在我的技术群里，往往大家都有很大的意见出入。例如华为黑和华为粉共存在一个群里，米黑和米粉也在一个群里。大家都在各自发表自己的观点和意见，但是也能相互讨论技术。
所以有的时候群友会觉得我比较较真，为什么非要把一些事情说得那么清楚，旁观者都觉得我累。因为我确实想要营造一种求同存异的技术讨论环境。
在我的技术群里，有非常多的意见向左的讨论。
有的人不理解函数式，他认为面向对象才是正宗的开发模式。但是我更喜欢函数式的写法，也在开发的过程中借鉴面向对象的思维。
有的人觉得 Vue 给了他机会进入了前端有口饭吃。但是也有人觉得 Vue 拉低了入门门槛，加剧了行业的内卷。
有的人特别偏爱 tw，又有的人喜欢 unocss，还有的人对原子化 css 这个方案不屑一顾的。
群里也有 React 贬的一文不值的同学，也有觉得 Vue 垃圾的人。但是如果只是讨论技术本身，参与讨论的人往往能够对 react/vue/angular 有更深刻的理解。
但是我们的讨论只针对技术本身，而不是针对人。但是总有一些脑子不好使的人，压根就分不清自己的言论到底是在针对技术进行讨论，还是在进行人生攻击。
针对人的，大多数都被我怼得自己退群了。
我觉得技术人要学会理解和接受别人有不同的技术理念。且不说，有很多技术讨论本身就是没有定论的。
就算是别人发表了不成熟的观点。你也应该保持基本的尊重。
大家都是从菜鸟一步一步走过来的。别人当前处于的阶段，要么就是你以前经历过的，要么就是你未来会经历的。所代表的技术观点不管本身是否有局限性，实际上也是一种别人经过思考和学习传达出来的观点。
但是有的人非常擅长把与他理解不同的技术观点的人归类为：菜。我觉得，这样的人，个人修养还需要提高，甚至有可能他在技术上，也是菜的。至少技术视野还不够。
要分享的一个现象是：敢于在公共平台发表自己技术主张的人，不管别人写得简单还是复杂，基本上都是有几把刷子的。什么叫做技术主张呢？
例如，我写一篇文章，分享如何实现一个功能，然后就完事了。这个不叫技术主张。但是，如果我说，使用 tw 来解决 css 的样式问题，是一种非常棒的方案，在我用过的方案中，这是开发效率最高，开发体验最好的方案。这就叫技术主张。
当我这样说时，至少说明，我以前用过别的方案，例如 rem、css in js、css modules 等，或者私下进行过横向对比。所以一般来说，长期做技术博主的，并且敢于发表主张观点的，都是会在私下做挺多准备工作，而不是随便口嗨一句。
这也是为什么，有的人想写技术博客，发现很难写的原因。
三、vue3 是否拥抱了 hooks
给首图来个 callback。
Vue3 是否拥抱了 hook。首先必须明确的是，Vue 的组合式 API 的灵感主要来源于 React hooks。这是 Vue 官网的原话。他们也承认了这一点。
只是由于底层实现不一样，所以在表现上有一些区别。但是这些区别，并不能作为充足的理由来说明 Vue 的组合式 API，不能称为 hooks。
这里最核心的原因是，在应用层面的最佳实践的写法，Vue3 的组合式 API 和 React hooks 几乎一模一样。Vue 生态里有一个非常出名的库，叫做 VueUse，这里面定义了许多比较好用的 hook 函数，并且，里面的命名也是和 react hooks 一样，以 use 作为开头。
而这个库的核心开发者里有这位大佬
这些迹象都表明，Vue 开发团队，并不避讳 Vue3 的组合式 API 借鉴了 React hooks。开发团队在这个点上是很大方的。但是有的 Vue 粉丝，就很避讳讨论这一点，遮遮掩掩甚至极力反对，去用放大镜观察他们的差别，以此来说明这两者是不同的思维... 有没有搞错？react hooks 本身就是一种，从开发体验上而言，更好的代码组织方式。
所以，React 开发者，可以非常平滑的切换到 Vue3 里去。这里最核心的原因不是因为 Vue 学习成本更低，而是最佳实践是一致的。在 React 中是什么样的开发水平，切换过来大概率也是差不多水平的开发能力。
注意：这里的平滑切换可不是说，只上手使用哦，而是快速达到差不多的使用水平。
四、总结
有这样一类人，当看到技术观点不同的双方开始争执起来了之后，喜欢在旁边说：果然是前端娱乐圈。讨论这个还不如讨论xxx。都是牛马，讨论这些没意义... 等等。我暂且把他们归于中间派。
但我不是。我并不逃避争议和观点碰撞。因为不同的技术偏好碰撞，并不仅仅只是发生在前端。后端同样如此。
我的观点是，求同存异的技术探讨和思维的碰撞，是在开源社区里，自身进步最大的一种方式。但是在国内，这样的环境太少了。所以我想要把我的付费群打造成这样的环境，我也因此受益良多。我并不担心自己的想法是错误的，因为每个人都是成长的，我当然可以犯错。我也过很多经典的打脸案例。我的标准是，我发表的每一个观点都是经过我自己仔细推敲，反复斟酌过的，他大概率是有深入讨论的可能性。
但是很多人，喜欢讨论，也喜欢嘲讽。甚至很多人发一堆会自动被屏蔽的留言，虽然我也不知道发的啥，但大概率是不堪入耳的脏话... 我态度鲜明的批判这样的人。
在反对我的观点时，有的人是这样的，有的人是头图那样的。同样不认同我，但素质高下立判。
最后补充：简单回答一下这个问题
实际上当前这个局面下，认为 React 落后的人大有人在。但是我并不认同。我简单分享一下我的观点，如果还有不同意见我之后可以写文章详细阐述。
1、react 曾经从面向对象的主流开发方式，转向了基于 hooks 的开发方式。这里一个很重要的实事是：大多数情况下，面向对象的写法，性能更好！
但是，react hooks 依然流行起来了！而面向对象现在少有人问津。所以，对于 React 来说，性能肯定是要追求的，但这肯定不是最重要的标准。有的时候，为了开发体验、可维护性等，我都会选择牺牲一定的性能。
2、在性能优化上。假如出现性能问题，我们以堵车这个场景来类比。React 的做法是：加红绿灯、加交警、安排优先级、增加一个调度模块，加限流手段。
除此之外，React 还有把车变小的做法。弊端是，这需要开发者自己使用 useMemo、useCallback、memo 来做到，对于有的人来说有一定的难度。不过，近期更新之后，React Compiler 做到了自动缓存。经过我半年多的使用感受下来，感觉非常舒适。
Vue 的做法是，把车变小，这样同样宽的路，就能容纳下更多的车流畅的通过。从而可以更大程度的避免堵车的出现。
所以我以前说，在性能方面，React 能做到的上限更高。而 Vue 更均衡。当性能碰到上限时，React 还可以通过并发模式再拔高一下上限。
毫无疑问：有调度模块的存在，能够承载的性能上限是一定是更高的，调度模式允许牺牲一部分能力从而确保高优先级任务的流畅体验。这类似于限号限流。限号出行的方案，仅仅只在个别大城市中使用。但没有使用这个方案的城市，你也不能否认这个方案的可行性和存在价值。
因此，我从来不觉得，React 会因为性能问题而落后，React 在解决方案上是具备超前思维的。 反而他更可能因为政治问题而成为过去式。
在开发体验上，半年使用下来的感受是：React 19 做得更好了。我认为 Vue、 Solidjs 都比不上。当然，这是一个主观的感受，仁者见仁，智者见智。
推荐阅读
掌握 React 19，推荐付费小册 《React 19 全解》成为 React 高手，推荐 《React 哲学》夯实 JS 基础体系，推荐 《JavaScript 核心进阶》
