在微信小程序中使用 Javascript eval

单纯不能操作 DOM 的 JS 完全没什么用啊。

楼主可以学一下官方，把 quickjs 的 DOM 接口和小程序的 View 自定义组件对接一下，这样就可以动态执行 JS ，并生成动态 HTML 了。

不能拼接 HTML 的 JS ，不是好 JS 。

@3dwelcome 现在的 taro 和 kbone 的用户，自己对接一下应该不难。包括 view 部分的话，就很难移植现有的代码了。保持库本身的精简，也方便用来做 plugin 的基础设施，例如像 figma 这样 https://www.figma.com/blog/an-update-on-plugin-security/

@taowen 我们用 JS 操作的都是业务代码，都是需要操作 DOM 属性的。

纯 JS 的计算，小程序本身就支持，也不需要用额外插件。

辛辛苦苦写出的库，总要让别人用起来吧。

taro 和 kbone 已经是很好的动态拼接 HTML 更新 View 的解决方案了。这两个都是 wxml 的动态化的方案。从原理上也没法做到更好，想要完整不缩水的 DOM 那平台不支持也没办法。

@taowen 你没理解我的意思。

你既然有能力能从底层重构 Javascript ，自己控制运行期，那你自己就是一个完整的 runtime 平台。

可以类似 nodejs ，注入嵌入一些 document 元素，比如 getelementbyid ，比如支持一下 jquery 语法。

kbone 这种都是 VUE 组件和小程序组件之类的转换，没办法脱离 MVVM 写代码。你这个 WASM 的潜力，要比这几个框架大太多了。可以直接把 UI 和 Javascript 函数对接。

kbone 有相对完整的 DOM 模拟，支持 getElementById 这些。微信小程序的展示层只支持 wxml ，你有 wasm 也没有用。最终东西要往页面上渲染，就只能和 taro kbone 一样，难不成你要用 canvas api 直接 draw 么？ wxml 动态化都长这个样子 https://github.com/taowen/vue-fusion/blob/main/packages/vue-fusion-weapp/pages/Fragment.wxml

我指的是这种，可能和你的 fusion 库概念类似吧。

既然能支持 custom dom ，那就把 custom 元素能力最大化。小程序架构太像 VUE 了，以至于传统的 JS 字符串拼接代码，更新界面完全没发挥余地。

https://taro-docs.jd.com/taro/docs/html/ https://github.com/rikumi/kbone-svg 在 taro 和 kbone 上都能搞