2025 年，我又把前端"老古董"--AMD 给翻了出来

太长不看省流版:

一个具有较高可扩展性的 JS AMD 规范模块加载器 partic2-iamdee
Github
Gitee

在上面的基础上做了个早期形态的“全栈”包管理 pxseed ，并附带一个 Javascript Notebook 。
Github
Gitee

纯网页模式 Javascript Notebook 演示地址
Github Pages
之前 V 站大佬推广的平台 帽子云

关于做这个的动机和最终想实现的效果

在知道 Typescript 之前不习惯写 JS 的，然后接触到 Typescript 的时候第一个问题就是模块化的问题，当时比较多的模块化方案就是 CommonJS 和 AMD 了，为了在浏览器上用自然用的是 AMD 。虽然有 webpack 了但是 AMD 更简单，然后一直用到了现在。

到了现在已经出现了很多前端构建工具，但遗憾的是，Javascript 还是没有一个扩展性较强的统一的模块机制。
例如 Node ，早期用的 CommonJS ，现在开始转变为 ES Module ，浏览器都支持了 ES Module ，但是各种打包工具又会在打包后使用不同的加载方式。而且还有个特例-ServiceWorker 中不支持 ES Module 中的动态 import 。
同时，可能是照顾到打包工具等实现，ES Module 的可扩展性非常弱，可能只有 Import maps 改变映射这种级别的扩展。例如我想从内存/IndexedDB 中加载模块，ES Module 就不能支持。

同时我也接触了 Jupyter Notebook/Lab ，觉得是个很方便的平台，可以动态的执行 Python 并查看每一步的结果。于是也想在 JS 上实现个类似的东西，虽然有 IJavascript ，但是我想有能不依赖后台 python 的这么一个东西。

然后就有了做包管理的想法。

NPM 分发和获取的经常是编译产物。可以对比下 Golang 。Golang 虽然槽点不少，但包管理工具链还是比较优秀的。分发的是源码，对某个函数有疑问，可以在 IDE 中跟进源码，NPM 上则大多只能跟到类型声明。

Node/NPM 的设计对比 python/PIP 有一些地方对 Notebook 不太友好，PIP 默认装全局，NPM 默认装项目文件夹，当然 NPM 的设计一定程度解决了版本问题，不过我的观点是版本问题还是需要第三方库本身做好，包管理来处理兼容问题多少会有一些难以解决的 corner case 。

因此我尝试做了这个 pxseed“全栈”包管理，在这个框架下，前端浏览器和后端 Node 都可以用一套编译产物，并用 AMD 加载模块，Typescript 源码直接分发和下载，这样 IDE 里点一下可以跟进到源码。为了兼容 NPM 生态，pxseed 也添加了 Rollup 来打包 NPM 模块为 AMD 供前端使用。

当然 AMD 做前端是有致命缺点的，AMD 加载零碎文件的性能差，没有 Tree-Shaking ，没有 SEO 。但如果是想做成个类似 python 的属于 JS 的全栈包管理本地用，还是挺不错的。而且 partic2-iamdee 高度可定制化，也让优化上述问题成为可能，比如，你也可以用 Websocket 来加载 JS 模块。

当然这些东西都有点"路子野",说不定已经早有人做过更好更成熟的实现方案，如果有的话欢迎推荐给我。