纯粹是微软被印度人统治之后疯了...

https://devblogs.microsoft.com/react-native/2025-05-09-office-modernize/

office 的新模块采用 React Native 开发。

看了一下论文原理，笼统来说，镜像有大量未使用的文件，比如基于 alpine-linux 的一堆容器，可能每个容器运行时你都只需要 usr 目录，别的比如 /bin /etc 压根不会动，那理论上我们可以把 /etc 之类的目录提取出来。

这个项目引入了一个 去膨胀层 的概念，通过分析容器运行时实际使用的文件，将他们提取出来成为去膨胀层，别的都剔除掉。

不过这种动态分析的方法可靠性我表示怀疑... 存在太多的 corner case 。有可能这个容器能跑起来别的就跑不起来了，或者基于这个容器导出的镜像打包出来的新镜像就跑不起来了。

@wxf666 这个我不太推荐，主要是保修最长的铭凡也只有 3 年，要是 boom 就是主板和 u 一起无。
而且单看板子的料就是比较垃的 a620 ，和 2600 的 7950x+500 块的丐 a620 性价比拉不开差距。
还有一点就是内存是笔记本那种，后续升级也不方便。

@leonme 全大核 d4 是 5950x ？

国内有个开发者搞了基于 Go 的凹语言。
但是说实话，定位很奇怪，品味也很奇怪，也许你可以参考它 fork 一个自己的。

先说是不是，再说为什么。

是不是？不是。
大型和超大型项目在前端的角度来看并不是“一个项目”，比如随便找一个互联网大厂的 App 都包含了海量的 h5 活动页，实际上这些活动页一个业务甚至一个模块就是一个 git repo 。
每一个产品都是来自于天南地北好几个办事处几百个外包攒出来的，这种情况下 JSP 热更新那套逻辑根本不适用。

再说为什么，因为这点损耗不是你需要担心的，容器有没有损耗？ k8s 有没有损耗？服务网格有没有损耗？ CI/CD 是不是成本呢？
现代软件开发逻辑本来就是用性能换可维护性并降低人力成本，人才是最贵的。如果对于这点没有实感的话，一个校招生一年的薪资够你加两台机器，更不用说开发人员数量增加后，配套人员和设施的成本了。

现代 JavaScript 教程 https://zh.javascript.info/
用 Go 语言自制编译器 https://www.ituring.com.cn/book/2882

没那么复杂，比如我们有一个 async 函数 foo ，代码执行到 await 的时候，控制权就从 foo 函数让出到别的代码块了，同时向待完成列表里插入 foo 。
等到 foo 的 await 任务完成后，就会向 eventloop 中插入类似于 “foo 已经完成啦，你应该继续 foo 的后续操作”的 task 。
等到 eventloop 循环到这个 task ，就会恢复上下文（也可以说是状态）到 foo ，这也就是为啥无栈协程也可以看做是一种状态机。
希望我的解释比较明朗。

赞同三楼，这不是技术问题，而是屁股问题。

@Radeon 那你自己用 rollup 把 cdn 上的 react.cjs 转一下就行了，不需要直接从源码 build esm 。

你可以参考一下我刚刚写的 demo 或者直接用 dist 文件夹下的产物。

https://github.com/Ray-D-Song/esm-react-transform

这个问题已经存在很多年了，不管是源码还是编译脚本没有考虑过 ESM ，要改的话至少需要几个人一起着手，不是 AI 能干的。
https://github.com/facebook/react/issues/11503
https://github.com/facebook/react/issues/10021

更关键的一点是，React 几乎所有子模块都是 internal ，没法进行摇树，所以提供 ESM 也没啥意义，你为什么不用 UMD 或者 CJS ？

@lisxour
和 pkg 以及 nexe 一样，需要自己使用 esbuild 、ncc 之类的工具把项目转换成单个的 js 文件，所以兼容性是那些工具保证的。

@byte10 你说的应该 nexe 和 pkg 吧，这俩也是打包可执行文件的工具，npx 是执行远程脚本用的。

其实原理都是把代码嵌入到 js 运行时里面，运行的时候再提取代码，不过因为 js 有 cjs 和 esm 两种格式，所以确实有可能兼容性问题。

这玩意 Ruby on Rails 社区早就有类似方案了，叫 Turbo 。

https://www.hotrails.dev/

和 HTMLX 一样，都是不堪重用的东西。

@dragondove 因为这个设置不能搭配 language server 使用，具体的表述是：
Include unimported packages in auto-complete suggestions. Not applicable when using the language server.

@songray 顺带提一嘴，Copilot 5 月开始高级模型调用限制 300 次，超出的 0.04 刀一次。
结合之前微软说过一个 Copilot 用户每个月亏损 80 美元，以及 Cursor 开始砍上下文长度和 Windsurf 涨价，明显各家开始烧不起了。
所以以后只会越来越难用，“想试试便宜的能搭配 deepseek 的看看效果” 还是算了吧...

Cursor 补全强是训练了自己的 MoE 模型，替代品是 Supermaven （已经被 Cursor 收购，但继续提供服务）。
至于 Chat 、Edit 、Agent 就全看上下文长度，Cursor 一开始一骑绝尘，最近也被砍成脑残了，动不动失忆，和 Copilot Chat 处于一个 60 一个 70 的水平。
最强的 Agent 插件还是 Cline + 自己提供 Claude3.7 或者 Gemini 2.5 的 API ，比 Cursor 那个砍了一刀的要强很多。

总结：Supermaven + Cline