react 不来就不依赖 immutable 那些东西。
正常的机制就是你 setState 之后，react 新旧 state 做一遍 deep diff 。react 有 shouldComponentUpdate 这个 api ，让你可以自己处理 diff 机制。
当初 react 面世之后，Clojure 有个基于 react ，叫 om 的项目。因为 Clojure 是函数式编程，数据是 immutable 的，在 shouldComponentUpdate 里比较两个 immutable 就是 === 这么判断，这就大大提高了运行速度。接下来就出现了各种用 js 实现 immutable 的库。函数式编程也在 js 圈子开始流行起来。

技术圈有这种给项目加标签的行为。xx 项目用上了 xx 框架，xx 架构，xx 语言。最终产品可能是个没啥功能的博客之类的。
新手喜欢这样，显得自己潮。老手也喜欢这样，增加绩效。
举例讲，闲鱼那软件做的啥玩意，可技术面上可是各种创新，各种标签都能打上。
想学一个新技术，首先是明白作者的初衷是什么，要解决什么问题。为什么旧的东西不可以，要造个轮子。
以楼主你的例子来讲，mvc 框架之前就有，为什么要造 react ？ redux 不是 react 捆绑的东西，而是 react 出来有一阵子之后才出现的，它出现的背景是什么，为什么要做 redux 这个东西？
知道初衷就能知道使用场景，用起来自然就能游刃有余。

看到很多人花时间研究某个类型怎么推导出来，我感觉本末倒置，难以理解。
我觉得最终的 API 能有类型，好让编辑器可以提示就够了。可能是因为我从来不写什么 class 之类的东西，所以才有这种想法。

写俩函数，一个是把这种树形对象变成 html 。这样一来，增删改查的操作，可以直接用 dom api 。

<item label icon router>
<item label icon router></item>
<item label icon router></item>
</item>

然后再有一个函数能把这个 html 还原成 js 对象。实际也就遍历一遍，这一个是前面那个反过来而已。

三十那年刚好是疫情开始。三年过去了，真的是没什么感觉就过去了。

劝各位进区块链项目的，就别期待能干多久，走多远。

顺序问题。为了不绕自己，不绕他人，拒绝使用 ++ 操作符就完事了。

想象一下：等你孩子上学了，正在家上网课的时候，楼上小孩闹腾。你家孩子向你诉苦，你会是啥心情。

书太老了。
你这问题问的也莫名其妙。得出这结论之前，作者说了前端的性能瓶颈在哪，为什么优化那些地方性能提升大。你应该问那些瓶颈现在还有没有，而不是问这结论现在还对不对。
而且我记得那书里应该也说了，性能跟着时代进步，几年前的最佳实践几年后不一定就适用。

跟不懂规范意义的人谈规范没用。强制执行几天，就像楼上说的，他们自己把 lint 之类的关了。
很多人说“业务复杂，时间太紧，只能写出来屎一样的代码”，可实际上，你问他们，怎么写出来不像屎一样的代码，他们根本不知道。
写代码就像写文章，要反复推敲，斟酌文字。只有熟练了微重构代码的技能，才能在时间紧张时，写出不烂的代码。
只可惜“如何写好代码”，学校不教，面试不问，工作不查。

对左右撇子来讲，另一侧的 shift ，alt ，ctrl 也不常用。反正我都是把他们映射成别的键了。像 caps lock ，我给改成中英文切换。右边 alt ，ctrl ，我给改成 home ，end 。

事件一般是一对多的概念，这种一对一的确实没必要用事件。我写 vue 的时候都是直接传函数，保持一个单向的传递才不容易出错。

这问题 electron 做出来就有人讨论过了。它不只是自带 chrome ，还自带了一个 node 环境。问题就是版本一变，软件直接就可能不能用了。现在的做法也是取舍的结果。

大概率要跑路。本身老板招新领导，就是嫌你们现有员工不行。等你们觉得新来的干活也不怎么样的时候，矛盾就出来了。