@xrr2016 谢谢

@molvqingtai 💪谢谢

@civet 😂好吧大家也就嚷嚷，写完 XDFrame 我才感觉到深抽象模型的意义，最终真正革命 UI 的方式应该是纯 gui 开发；

@lijsh 但 Vue 和 React 直接引用 script 写就没意义了，整套的预编译方案才是它们的精髓； XDFrame 只是想做浏览器引用就能开发，把 npm 的包管理模式直接集成到 web 上；

@civet 是的，其实我这个 XDFrame 也有封装一层融合模型的概念，现在我不提出，以后也会有人提出，抽象出来之后反而更容易做跨平台，行为和事件模型甚至做成 json 就能跑；所说的原生也只是浏览器支持的 api ；我想做的是除了核心工作，门槛都不应该存在；😂 感谢提出这个问题，其实 XDFrame 里面的三个子库都是正式的，分开来没人理解，所以最近才组合打成一个，后续文档和更多案例会补充；

@shell314 谢谢

@AlloVince 感谢指出问题，test case 在三个子项目库里，等手头东西放下后搬到这个打包项目里

@civet 这次摩尔定律应该不生效了，webpack 模式都坚挺 4 年了

@WittBulter 😂 那我只能在自己的项目上玩了

@littlebaozi 现在面临的困境，大厂卡学历，小厂看不起，一度怀疑人生。

@zyscn 谢谢

@XD2333 我会加油的

@hugee 不牛逼也就几十 kb 的东西，你去试试看，跟 jQuery 那个时代很像的语法，只是把 vm 绑定进去而已。

@mologo 谢谢，现在只做网页的功能普通人可能还是很少用；趁还没上班我这两天把 PPT 的功能做了，普通场景也都能用得上了。

@Carseason 谢谢

@runze 😹我简历补上

@Cbdy 当前 drill.js 支持还是很好，而且 drill.js 可以扩展 ts 之类的文件的支持，就是写 runtime 我还得恶补好多编译知识，当前经济状况之类的做考量这方案性价比太低了😭，会优先考虑能填饱肚子的方案；

@Cbdy 但是有几种需求不能满足，比如 drill.js 的异步模块，如果 'data'模块需要一次 ajax 请求数据，按照 es module 就只能返回一个 Promise 对象，后续逻辑再做一层包裹，才能做这种需求，而且 esm 是同步开发的模式来思考；
drill 的模块还有 task 模块和 init 模块，虽然这两种是非必须但是开发还是很实用的，还有就是 web 前端开发里的 非模块文件（普通 js ）, esm 没有把它思考进去； drill.js 就能当成默认文件插入；

还有一种未来一定会出现的一些模块类型，比如 点击按钮音效，按照 drill.js 的扩展开发模式，很容易就能做到如下：
let p = await load("xxx.mp3 -defer")
btn.on("click",e=>{
p.play()
})

不考虑做 esm 还有开发扩展上的考虑，现在 drill.js 开发扩展支持是很方便的，代码如下：

loaders.set("wasm", async (packData) => {
let data;
try {
// 请求数据
data = await fetch(packData.link);
} catch (e) {
packData.stat = 2;
return;
}
// 转换 arrayBuffer 格式
data = await data.arrayBuffer();

// 转换 wasm 模块
let module = await WebAssembly.compile(data);
const instance = new WebAssembly.Instance(module);

// 重置 getPack
packData.getPack = async () => {
return instance.exports;
}

// 设置完成
packData.stat = 3;
});

使用如下：
let xx = await load("xx.wasm")
xx(); // 这里直接用 xx 方法

drill.js 目前很容易就能开发扩展，esm 开发扩展会变得很麻烦，可能又要走预编译方案，还有得重写 map 映射，或者我还要在想想 esm 怎样开发扩展会更方便；

@Cbdy 你给的这些东西跟我说的不一样，只是限于当时的发展当时没法做，所以才到 grunt glup 后才 webpack ；现在浏览器已经发展的够好了，有能力抛弃预编译方案；我只是想探讨，假如非预编译方案已经和预编译方案一样了，有没有前途，没有的话我就不补文档了。