jjwjiang

react 在 hooks 出现以前比 vue 心智负担更大

但是在 hooks 普及之后心智负担大大减小了，现在没做过 react 的新人培训两次，重点讲解一下 useState 和 useEffect ，已经完全可以胜任常规工作了，同等时间上手 vue 肯定需要更多的记忆和习惯。

当然一旦到了更深的层次其实都差不多，react 生态更好点吧。

别的我印象不深了，但是 java 的 stream 的啰嗦程度是真的相当之高

collect 就跟画蛇添足一样的感觉，跟泛型一起用太难受了，group 、sort 都是令人发指的反人类

c#的 linq 和 lambda 可以完爆这一项

C#完美满足你除了生态之外的所有需求
对于开发者的便利 C#说第一应该没人能说第二……
至于生态，仁者见仁吧，现在基本上该有的都有，社区小是真的，但是也都能用

@yazoox 正解，假设通过 memo 去避免了这次“计算”，但是又会增加 memo 本身缓存、比较的开销，哪个快哪个慢还不一定呢。
我觉得用 hooks 之后，真的出现了性能问题和重复刷新问题再去（通过拆分重构）解决比脑补要合理

第一，你的主题里描述的是完全不等价的判断，而你在#27 的补充里说这是你的失误，你想表达的是 length 和 length>0 ，但是这个概念过于基础我觉得已经深入了对 JS 稍有了解的开发者心中，所以我怀疑你自己可能一开始就没搞明白这其中的区别。
第二，.length 和.length>0 在 JS 里就是完全等价的，前者也是非常常规的写法，没有意义也没有必要去讨论这个点

和产品的沟通上面都说了我就不赘述了

说说和前端沟通，显然你俩应该最早就定下来前后端交互的数据结构才对，这样不影响双方进度，也好随时沟通变更。

约定好结构之后双方定好一个人来把数据以 mock 的方式全部写好一份，在前端也好后端也好，都不费劲，然后在开发的过程中双方都能第一时间发现不合理的地方，在沟通这个结构的过程里，互相也能加深对业务的了解。

@bthulu 这不是 EF 的范畴和问题，用表达式树可以很简单的解决这个问题

复杂的场景无论如何最后一定是存储过程，EF 或者 Dapper 这种情况就是调 script ，没区别

简单的场景显然 EF 要好用得多，所以个人认为 Dapper 可以退出历史舞台了

@YuiTH 就排序 搜索 前进后退 查看引用什么的吧……高频的用几次就记住了
VS 的搜索需要选一下 scope ，选成 solution 级别没感觉和 VSC 和 resharper 有什么区别？可能是你觉得 UI 不一样？
其实更好用，还能在搜索结果再次筛选