知乎 · 2020 上半年

去掉 33 岁，或者改成国外的话我觉得是有机会的。

但如果不是的话，不建议。国内内卷程度会让你绝望，就怕你被割几轮韭菜（报培训啥的）后结果还是只能屁颠屁颠的逃离这个行业（狗头

1. 既能用上 JS 庞大的生态
2. 又能享受 TypeScript 不输于（甚至碾压）其他静态语言的类型系统
3. 有着世界上最庞大的工程师群体，可以跟你交流（/解决问题）

性能？讲真，你接触到的 99% 的项目可能都到不了需要通过切换语言来提高那丁点性能的地步。

而且你再往前看看？Serverless 上不也一样推荐跑 JS，语言（/解释器）上的那点性能损耗真不是事

Redux 确实是目前流行的状态「管理」方案，但实际上题主问出这种问题的时候，我在猜测很可能你的场景并不需要对状态进行「管理」，你可能仅仅想要在组件间「共享」状态而已。

如果你确定你是后者的话，那么我可以给你推荐下这个（被 Typora 的作者 Star 过哦哈哈）：

https://github.com/nekocode/use-shared-state

这是一个结合 React Context API 的一个状态共享库，用法和 useState 类似（仅需把 initialState 改成 SharedState 的 Context）:

const [state, setState] = useSharedState(UserNameContext);

为什么推荐它？因为它几乎是用法最贴近官方接口、没有额外概念的、高性能的、带单元测试的（狗头）、最轻量级的 State-Sharing 实现（对比其他一众花里胡哨的状态管理/分享方案来说）。

回到原题，之所以很多人会觉得 Redux 很繁琐很可能是因为你并不需要用到它，Redux 应该更适合用在需要状态机、状态可回溯、或大型复杂项目等场景（例如编辑器）。对于轻量级的项目、甚至是库项目，Redux 的各种范式、boilerplate code，以及可能对 Redux 无法熟练掌握的你，只会让你的工程最终变成一坨 Shit