【提案】将 svg-render 的不完善，作为一个客观的问题来看待

[Gaubee]

因为 svg 渲染引擎的问题，这行代码会导致非常巨大的渲染开销。这是作者的解释

1. 因为 svg 是 web 的标准，我们是一个 web-first 的平台，所以 svg 这个标准不能放弃，对于习惯了 web 生态的，开发人员来说，svg 的支持更是理所应当的。

2. 假若我们解决 svg 在非 DOM 环境下渲染的各种问题（以下简称为 NO-DOM-SVG），那么就要为 svg 的支持提供一系列的工具链来解决问题

   解决这些问题的核心原则是：对于用户仍然可以使用 svg，这个过程对他来说是无感的，但最终能正确在我们平台上使用。

   1. 接下来，我们将明确声明，只在 jmm 这个场景下的 manifest 的部分字段上提供 svg 的支持，目前有且仅有 icons 这个字段
   2. 接下来我们会在 plaoc 中提供工具，来规避 no-dom-svg 渲染的问题，确保两点：
      1. 渲染的资源占用符合预期：足够的快、且内存占用低

         这可能需要用 wasm 这种虚拟化技术，来监测内存占用是否超过预期。

      2. 渲染足够的正确，因为 svg 是一个非常大的标准，甚至还包括了动画，我们使用的 svg 渲染引擎只是实现了最常见的一部分 svg 标准，而且还不支持动画。
   3. plaoc 在打包阶段如果遇到 svg，需要同时调用浏览器来做原生的渲染（注意要使用 background-image-svg，而不是 dom-svg，避免 svg 被 dom 影响），将 svg 在标准浏览器中输出成位图，跟我们的 no-dom-svg-render（目前是 resvg）做对比，如果相似度达标，那么就保留对 svg 文件的直接使用，否则直接使用爆出警告，同时将输出的位图（webp）给打包人员，建议它用 webp 来替代 svg 做渲染。
   4. 目前明确禁止对动画的支持。

3. 我们将使用 webbundle 来打包应用，意味着将只存留单个 webbundle 文件，不再需要 manifest.json 与 xxx.zip 这样的双文件模式。

   1. 由于 webbundle 的特性是将 https 链接的请求静态化，因此未来 manifest.json 中的 https 链接，将会有明确的域名限制，同时也将被 webbundle 静态打包在一起、包括 icons、以及预览图、启动屏等等
   2. 此时对于动画的支持，我们将做出一些策略上的调整：
      1. 我们仍然不允许在 DOM 环境之外使用 svg 动画
      2. 但是打包工具将支持把 animated-svg 转化成 animated-webp
      3. 动画不能超过特定时长（根据场景需求进行限制：比如说 icons 不能超过 1s）
      4. 动画会有帧率限制（根据场景需求进行限制：比如说 icons 是 10fps）
      5. 转化出来的 animated-webp 会有一些默认的大小限制，（根据场景需求进行限制：比如说 icons 最大是 500px）
      6. 支持循环动画
      7. 对于完整的动画支持，建议使用 mp4，包括 应用启动，也是这个建议
      8. 动画将极大增加 webbundle 的大小，需谨慎使用
   3. 在 webbundle 中的所有资源都将在携带签名

[waterbang]

https://developer.chrome.com/docs/web-platform/web-bundles?hl=zh-cn
webbundle 已被google弃用，我们还要继续使用吗？git 看着也没人维护

[Gaubee]

https://developer.chrome.com/docs/web-platform/web-bundles?hl=zh-cn webbundle 已被google弃用，我们还要继续使用吗？git 看着也没人维护

我看了一圈，这个提案到v2之后，就放缓了发展进度了，社区对这个提案一直有很多讨论，Google自己好像也因为利益关系，导致没有再推动这个提案，以下是相关的链接：

• Web Bundles (Web Packaging) mozilla/standards-positions#264
• Correct / real URLs should be enforced, to avoid breaking adblockers WICG/webpackage#551
• [Meta] A long term plan for subresource loading WICG/webpackage#648

但并没有说明确的放弃这个提案，我看了一圈他们担忧的点，这些点在我们dweb架构下都不算问题。
因为我们本身就是奔着https://.dweb这个根域名去部署网站的，它们很多讨论的冲突都是围绕 https://.com 与 wbn://*.com 引发的矛盾点的。
同时也因为这些矛盾点，它们需要在现有的浏览器标准上缝合大量wbn相关的标准。
这些缝合，可能会导致这个提案最终过于复杂而长期搁置甚至流产。

我看了一圈issues，对于这个提案有强烈需求的，主要是针对它的离线访问的功能，而这个需求，可能会被国内在推进的 miniapp 给取代： https://www.w3.org/2021/miniapps/ 目前这个提案是 华为、阿里、百度 这三家在牵头。

miniapp 自己也有相关的打包标准 https://w3c.github.io/miniapp-packaging/
miniapp 的打包标准更像是一个完全独立的标准，并不是为了靠拢现有的website，而是另起门户，跟国内现有的小程序标准更加贴近。

[Gaubee]

我们可能需要参考目前它们的标准，推出自己的 dweb-bundle 标准，格式上可以参考 web-package / miniapp-packaging。
但我们要突出的是 dweb 的特点：

1. 以模块作为基础，模块体现的是隔离的特性，比如（只是比如，还未深思熟虑）：
   1. manifest.json 文件
   2. icons 文件夹，包含应用图标资源，允许国际化命名规则
   3. splashscreens 文件夹，包含应用启动屏相关的图片或者视频资源，允许国际化命名规则
   4. public 可读可写文件夹用来与其它模块共享静态资源（从而实现在不启动后端的情况下，也可以通过 file.std 访问一些必要资源文件，甚至可以用在边缘部署），甚至可以定义一些内容可被外部写入

      它时一个可读可写的文件夹，因此可以想象一下，当你要分享你的应用的时候，你的应用并不是一成不变的，而是会随着你的使用而改变，因此不同时期去分享应用，可能结果都会不一样。
      利用 public 文件夹甚至可以实现动态的应用

   5. usr 只读文件夹用来存储应用程序的私有内容，程序入口主要就是在这里
   6. sys 只读文件夹可以用来存储模块（沙盒）相关的垫片，可以用来替代 jmm 程序启动时的 bootstrap.js，从而实现一些向下兼容；甚至可以实现类似 nodejs 的 loader，这样就可以在 usr 的主程序启动之前，就先预装好 ts-loader，从而实现将 ts 文件作为源码来启动。
   7. data 只读文件夹可以用来存放应用程序的数据目录，在安装完成后这个文件夹将会被转移到 fileNMM 中为每个 MM 管理的 data 文件夹
   8. cache 只读文件夹同理，可以用来预埋一些缓存

总的来说，我们在思路上和 miniapp-package 有相似性，但是 dweb 本身的定位会更加的饱满，所以需要考虑相比 miniapp-package 更多方面的需求。

至于 miniapp-package 提到的国际化要用 i18n/*.json 这点，有待商榷，不过也有好处，就是如果国际化是一个 json 文件，那么未来内置的 ai 就能直接通过翻译 json 文件来自动实现应用的多语言。
类似的思路，我们可以多结合 AI 来考虑我们的格式，考虑有哪些资源文件是可以被 AI 处理的，比如 CSS？
但我并不想将这些绝对化，而是希望从一个更加开放的角度去思考，考虑插件化的可能。
否则对于比如现在用 angluar/flutter 做 webapp 开发，它并不会一定就会生成个这个 i18n/*.json 这些文件。

插件化这点我展开说说，还是围绕 public 这个文件夹，因为这个文件夹通过配置，可以被外部写入。
所以参考 firebase 的思路，我往 public/i18n.std.dweb 中存放一个 zh-CN.json 与 i18n.json 配置文件，外部插件模块监听到这个文件夹的变动，就开始基于 i18n.json 的配置，生成 en-US.json 文件。
这样一来，国际化就可以作为一种可选技术，通过社区插件来实现（参考 动态内核模块）

firebase 还有很多有趣的玩法，可以学习学习