微咸上个 issue 其实是失误，其实还并没有达到 50 这个数量，发布之后才发现的，本来想在下一个 issue 里面说一下，没想到拖到了现在，也只能将错就错了。
这些 issue 其实都是我每隔一段时间以来的阅读的摘抄。从 2022 年时候开始总结并且整理为 issue，那时候频率是每周阅读每周总结，但是结合工作来看，感觉时间的压力就会比较大。所以 2023 调整了频率，从发布频次也可以看出来，也和 2023 年工作和生活比较忙有关系。2023 年给 issue 调整了格式，添加了小标题。按理来说，2024 也会有点小变化，但是还没有想好，应该会在 2023 年度总结里面发布，随便安利一下我的博客 https://www.jwx.ink/
工程师
https://www.mayank.co/blog/react-server-components/
服务端组件好的坏的部分，赞同服务端组件进化的目标，但是确实有种 shit 上面再雕花的感觉。社区还是很多关心的问题没有解决，比如状态管理。按照 react 的进化速度来看，还有很长的一段路要走。很赞同里面的一句话，状态管理用什么库，当然是用内置的啦。
Lint 工具，但是不同的是需要配合 compiler 一起使用，将一些 react 范式中比较容易导致性能劣化的写法暴露出来，看了下文档是通过包裹组件，useState 这些方法，记录渲染次数，渲染耗时，我想这就是之前 react 团队一直想做的 forget 通过编译的手段找到哪些地方需要优化。我还记得 react 团队最开始说过做性能优化不需要太早，但是这句话并不是很对，反而应该比较早比较好，特别是知道自己维护的可能是一个特别大的项目，主要原因就是 react 性能分析的工具如果不是一个老手真的玩不转，给出的手段真的太少了，而且文档也没有特别指导性。
另外这个网站还有对 react-dom 的优化，可以看看。
https://parceljs.org/blog/v2-12-0/
parcel 支持 macro 实现，可以在构建阶段将一些运行时的代码替换掉，但是我不理解这东西好处是啥呢？
https://www.builder.io/blog/structured-clone
原生的 deep clone 方法，虽然有一些限制但是已经能够满足需求了。
https://humanwhocodes.com/blog/2023/09/javascript-wtf-why-does-every-return-true-for-empty-array/
才知道，every 这个方法，对于空数组永远都是返回 true。
https://dhwthompson.com/2019/my-favourite-git-commit
git commit 应该做到为什么这么做，而不是简单的 fix test，描述导致 test 失败的原因可能更加重要。一个规则判断 commit 是否是合理的，你看到这个 commit 是否能知道在做什么事情。
文章
一个仅仅在赛博朋克废土世界出现的场景，如果车贷没有还清，车子将不能用。不过现实世界时车子的公司没了，车子不能用了。不能说一摸一样吧。
https://blog.jim-nielsen.com/2023/most-profitable-ui-element-ever/
思路打开，做一个有市场份额的浏览器，然后卖浏览器输入框的默认浏览器，没想到可以这么值钱。
https://gist.github.com/mondaychen/e35960ad94ad43ac3e94098d6a7e2eff
在降本增效的视角下特别有感触，效率工具衡量价值永远都很难，只有收入部分才会得到重视。效率衡量的价值永远是节省人力。 https://gist.github.com/mondaychen/e35960ad94ad43ac3e94098d6a7e2eff 但是大公司往往是先裁员，节省成本。然后再在现有的人力基础上通过工具的方式提升效率，弥补缺人带来的问题，所以出现了又裁员有招人的情况。招的往往是真的需要人的地方。
https://mp.weixin.qq.com/s/3_LNM62zoHaJsmvAryujEw
一直以为高德的红绿灯倒计时是因为连接的云端的大数据，但是其实还用到了一些智能预测的能力。在我看来，或许是因为用高德人比较多，等红绿灯的时候上传的数据也比较多，所以才会有这个效果。
https://www.businessweekly.com.tw/management/blog/3014278 算是解决了一个疑惑，当你和别人讨论发生分歧的时候应该如何做：你可以不同意，发表你的意见，但是团队一旦决定了应该全力去做。