@vulgur 了解了，thanks

感谢，很好的分享。想请教几个问题：
1. 组织账号的主要用途就是对外显示开发者为组织名称而非个人姓名吗，还有没有其他区别于个人帐号的地方？
2. 如果是全新启动一个开发者账号，可以一开始就注册为组织账号吗？

@thiiadoewjwe 倒也是，我先用备用机测测看，反正也暂时不会换主力机

@angkec 好的我去看看

想尝试，但是日常会严重依赖 Mac ，如果换安卓，有办法和 Mac/iPad 无缝联动吗？比如提醒事项、AirDrop 、共享剪贴板、切换流转音频输出等

@andyr145698 基本各家都是相同的姿势，可以直接导入其他浏览器的数据。多设备同步的话靠它的同步链。可能要梯子才能同步

@bs10081 有，和 edge 的差不多

确实，Edge 团队整天放着 Bug 不修，去搞一些整活 feature ，越用越烦已卸载。不过 Chrome 我也回不去了，没有垂直标签页是硬伤，现在所有设备全切到 Brave 了，感觉良好。

我对图表相关没有什么太多经验，可能无法从相关专业的角度给予建议，只能给一些通用的建议。

对于入门前端，还没有深入了解的同学，我一概不推荐 react 。除非你的需求命中以下任意一个：
1. 需要用的第三方库没有 vue 版本或原生 JS 版本，只提供 react 版本，而且没有其他同类替代方案
2. FP 爱好者、FP 原教旨主义者、Dan 的 nc 粉
3. 团队当前 react 技术栈已有较成熟的基建积累
4. 需要借助 react 实现 KPI

如果你没有命中以上，那自然是好事。大多数需求用任何框架都能做，主流的几大框架都能做的很好。但我会更推荐优先考虑 vue/ng ，你会获得几大额外优势：
1. 基础生态更完备。不要高估社区生态的质量（典型反面教材：react-router ），官方全家桶如果能包揽，可以大幅减少被社区库坑的挫败感和频繁调研选型的困扰
2. OOP 比 react 的 FP 更普适，更符合直觉，尤其在项目复杂度膨胀后 OO 的优势更明显

如果要扯详细的对比那就太长了，而且对初学者并不友好。我推荐的标准就是，在功能都差不多的前提下，面向工业界的解决方案永远优先于偏学术和研究向的方案（点名 react ，不要对一些不为软件工业负责的哲学家们抱有幻想），工具是用来解决问题的。

以上仅供参考，也是对一句话推荐风气的一点反击。你永远不知道那些人到底是资深专家，还是多年固化在某个技术栈慢慢形成偏见的老前端呢？

好几个说无脑选 react 的，这么不负责任的发言，是来提供帮助的还是坑别人的？建议 op 遇到这种楼层直接无视。

@realpg 认为 Vue 低级的大概率也不是大佬。React 一开始面向受众就不是广大开发者，更多的是满足 FB 内部那些哲学家的癖好，它也从来不对软件工程负责。而 Vue 和 Ng 相对就要好很多，也就是说更像工具应该有的样子。
早期一些大厂的团队选型主要是奔着 React 这东西 KPI 友好，越是基础的东西越有轮子和答辩素材可以做。如果选了 Vue 相对没那么多业务外的东西可以搞了。而现在不少大厂新项目用 React 是更多因为内部积累的基建已经比较成熟，用其他技术栈反而有很多东西要从头接入。

有几年没用过了，不过看陈成发的文章还是有点印象的。最近有个小项目要用 React ，为了快速有个脚手架可以撸起来项目就试了试 umi4 。

相比之前用过的 umi2 ，主要感受就是切 v4 到默认版本太不慎重了，各种周边插件和文档都还没做好就开始切了，目测文档完成度只有不到 50%，质量一言难尽不说，很多东西都查不到。而且已经默认开启的从上个版本就开始吹的 MFSU ，体验下来真的是慢的可以，完全没感觉到之前的吹 MFSU 比 Vite 快的软文到底有什么依据。初始的裸项目启动后 80% 时间花在等那个页面上的 loading ，启动时间至少 5-10s ；热更新更是慢，大概是 Vite 5 倍以上的时间，而且大部分时候都是修改代码后直接触发硬刷新，根本没感知到 HMR 在哪。

以上是 v4 的一些槽点，其他的算是 umi 从开始就有的问题了。比如做了太多约定和黑魔法，开发必须强依赖文档等，看个人喜好吧。

不用 Hooks ✅
不用 React ✅

一看看到箭头函数就猜到会出问题...不知道是不是从 React 类组件带过来的习惯？写 Vue 就用最符合直觉的方式去定义方法就好了，无论是写选项式组件还是类组件 /服务都是一样的。

赞，感觉很不错！如果以后有计划开发 Vue 版本就更好了

@4771314 深有体会，之前接手过隔壁组的 node 项目，屎山不说，各种内存泄漏、for 循环串行 rpc 、不写鉴权导致安全问题频出等等。拉前端来写 node 业务还是要有一定经验的才行

如果走前后端分离，前端业务逻辑占比应该不会少，前端复杂度会很高，除非是传统的异构 SSR + 前端仅处理少量交互代码。这个时候如果前后端同构都用 JS （ TS ），优势就体现出来了，前后端复用的校验、接口 DAO 、服务、工具类、配置等可以显著提升一把梭速度。我们组维护的几个 MAU 只有几百万的小项目就是从几年前开始一直在这么搞的，技术栈主要就是自研的 JS 全栈框架 + Vue 。当然运维相关对 Node.js 是个问题，公司有支持是最好，个人项目直接用 alinode 等也不错