这样的想法可行不？

flutter?

@kamilic flutter 原理不了解，不是直接编译两套代码吗？用 wasm 的话可以忽略掉平台差异

想法挺好，是不是以后网页直接贴张设计稿上去，监听点击位置就好了...

感兴趣，静候大佬作答。

然后不断加功能，再实现一遍 DOM

@love 没必要实现 dom 那么复杂的标准，如果只实现基本的功能呢？我记得国外是有全部用 canvas 实现的应用？

可以，没必要，以前 react 就有 canvas 实现的版本，后面还是用了 react native

即便 canvas 渲染能力出众，wasm 性能贴近原生，但是真的能保证用 canvas 实现一套 ui 组件的性能可以接近原生 html 吗？

估摸了一下，可能要分你最终做的是什么东西吧。不过性能更好这个基本上不可能。
这东西就好比客户端的 duilib，会省去一些系统组件间的交互，某些方面可能会快一点，但是要综合起来谈性能更好，同样的渲染条件下没可能。

qt webgl 那个？

字体，排版，样式，每一个都是无底深坑

不说性能问题，就一个简单的输入框控件就够你折腾

@loginbygoogle 主要就是性能允许与否

@momocraft 那如果光探讨可行性，可行吗？

重复造了一个 js 游戏引擎？

@VDimos 做来玩随便，有期待不可行

accessibility 也是个问题

@gchxp 有点儿类似，但和游戏引擎的侧重点不太一样

没多大用吧，用户层缓冲帧率上不去，不直接用 canvas 绘图，你显卡不是毛用没有了
绘图渲染还是要用 canvas 直接完成，排版倒是可以用 wasm，感觉也比不了浏览器直接的体验更好吧

可以，但是应用场景不会多

因为现有的 web 无论是常规 site 还是 pwa，大部分瓶颈都不在性能上

游戏可能用的上，但是人家游戏引擎就是专门做这个的，unity,ureal 貌似现在都能直接发布到 Webassembly 了

强行 port 过去，重写一遍现有业务，npm 替代品没有的轮子再造一遍，你看大公司们乐意不

个人自己玩玩倒蛮有意思的

会不会出现把计算密集的实时性又不高的东西直接放到客户这边，类似 js 挖矿，只不过性能更高一点？

@murmur
@VDimos

flipboard 之前就是用 canvas 来替代 DOM，现在还能找到一些文章。
而且 做这个事的第一受益应该不是性能吧

我看 flipboard 那个文章的意思就是他主要是为了性能做的

这个问题我觉得可以换一个角度看

根据我的观察，UI 库（指广义的 UI 库，不是前端一亩三分地里面的那几个）按照其绘制界面的方式可以分为两个流派
一个是用更高（或不同）的抽象包装平台提供的 GUI 相关的 API 和控件，比如 Windows 平台的原生 API 是 Win32，微软就有 MFC、WinForms 等一堆库来做这个包装，Borland 的 VCL 应该也算（没记错的话应该是）。这种做的比较大的，跨平台的我就知道一个 wxWidget。还有 SwiftUI，按照 Apple 的说法（ SwiftUI 使用了 UIKit/AppKit ）。
SwiftUI 是属于这一类的，另外 UIKit 和 AppKit 的基本思路一样，但是确实是两套不同的 API，所以如果 SwiftUI 能实现一套代码在不同 Apple 平台上跑（这个我没了解过，我主要对框架设计思路感兴趣），那勉强也算个跨平台吧 ...
我们把这一种框架称为“老实人框架”

另一种就是我用平台原生的 API 帮我创建一个窗口，再让平台帮我在窗口里面搞一个 canvas （指代任意图形 API 的 context ），跑一个 event loop，然后就变身渣男把平台给踹飞了。窗口里面的控件则完全由 UI 库自己模拟出来。这种做的比较有名的，远有微软的 WPF ——虽然只能在一个平台上面跑，但是还是自己把 Ｗ in32 控件重新做了一遍 ... 然后到死都还有性能问题，近有 Flutter （ Flutter 用的应该是 Skia，Chrome 的 UI 应该也是这么画的，所以 Chrome 也 ...）
实际上 Qt、GTK、Swing、JavaFX 都是这种方式，几乎所有的游戏也是这种方式（ Apple 甚至默认了游戏可以随便折腾不用管他那一套理论）
我们把这一种框架称为“渣男框架”

现在我们来证明“老实人框架”和“渣男框架”是可以无限互相嵌套的 ...

说到平台，这里的平台 API，在 Windows 指的是 Win32 那一套（ CreateWindow 之类的），在 Mac/iOS 指的是 Cocoa/CocoaTouch，在 Android 指的是 ... 好吧就是 Android 那个 ... 我也不知道叫什么，可能谷歌起名部需要努把力了
Linux 不存在（至少是不存在唯一的）平台原生 GUI API，非要说的话 libX11 算一个？好吧这个还是以你用 X 为前提的 ...

这里有意思的是，如果你把 GTK 看成“ Linux 原生 API ”的话（毕竟 GTK 在其他平台使用的很少），那 GTK 就可以被归类为“老实人框架”了 ... 其实还是有一点区别的，因为这种情况下你就是在直接调原生 API，而没有在用额外的 UI 框架 ... 所以应该说是 gtkmm 属于“老实人框架” ... 不过 anyway，这里的启发是，Cocoa 和 Android 这些框架在 UI 方面的内部实现实际上可能和“渣男框架”区别并不大，只是人为原因（官方钦定硬点）把它放到了“平台原生”这一层里面

有了上面的思考，现在我们就把 Android API 本身当成一个“第三方 UI 框架”，然后你写了个 Flutter 程序跑在 Android 上面，这就相当于你在一个“渣男框架”里面嵌套了另一个“渣男框架”
你写了个 React Native 程序跑在 Android 上面，React Native 是创建 native 控件的，因此属于“老实人框架”，这个相当于你在“渣男框架”里面嵌套了一个“老实人框架”

回到楼主的问题，首先 Web 这个东西可以被认为是一个拙劣的“渣男框架”
这个和计算机中另外一个规律，“ Greenspun ’ 10th rule ” 是异曲同工的：“任何 C 或 Fortran 程序复杂到一定程度之后，都会包含一个临时开发的、只有一半功能的、不完全符合规格的、到处都是 bug 的、运行速度很慢的 Common Lisp 实现。”
做过前端应该明白为什么 Web 可以被称为“拙劣的‘渣男框架’” ...

DOM+CSS 可以被看作是 Web Native API，从这个角度讲，Angular/React/Vue 这些可以被视为建构于 Web 之上的“老实人框架”

然后你在 Android 上面跑的 React Native 程序里面嵌套了一个 WebView，里面放了一个 React 应用，现在你在：
一个渣男框架里面 （ Android API ）
嵌套了一个老实人框架 （ React Native ）
里面又嵌套了一个渣男框架 （ Web ）
里面又嵌套了一个老实人框架 （ React ）

有没有一点 “ Java 应用调用栈”（ https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstack1.png ）的意思？

楼主的意思就是，我能不能在一个“渣男框架”里面再嵌套一个“渣男框架”，理论上显然是可以的，你甚至可以继续嵌套 ...
至于实际有多大意义，那就是另一个话题了

你只讨论了 UI 部分
我们说跨平台，不止包括 UI 部分，还有
界面交互——输入和输出，随数据动态
硬件交互——照相 定位 声音 还有各类设备上的独有功能（比如电话短信等）
如果这些都交给 WAS 来做，那么就是传统的 VM 模式了
如果这些交给设备本身来做，那就是目前的跨平台模式：在各设备里面嵌入一个处理层（比如手机上的 js 引擎），剩下的交给原生。

十多年前一个后端大佬看到我写前端，他说，你完全可以用 JS 生成并控制 DOM，这样更快。我还跟他争论前端讲究的是精简，class 或 id 用单字母就可以，能不使用 JS 就不使用，CSS 要兼容度 IE4.0 800 乘以 600 屏，2G 网络的 WAP 页要适配压缩中转后的一系列手机浏览器。

Flipboard 这样搞过。
两年前也看过新闻，理论上 React 这种东西也可以输出到 DOM 以下的浏览器渲染层，不知道有没有下文。

@areless 单个字母的 id 和 class 认真的吗？

“用 wasm 做计算”具体是指计算啥？

现在 js 也可以多线程计算，至于 canvas，我曾经想过这么干，后来放弃了。本来浏览器内核就干了这么一回事，你再浪费资源进行渲染，简直疯了。