这是一个创建于 1913 天前的主题，其中的信息可能已经有所发展或是发生改变。
webassembly 的性能现在已经很突出了，按照目前的发展趋势，wasm 的性能会逐渐逼近原生。
如果用 web canvas 做绘图层，用 wasm 做计算。在 wasm 返回给 web 的 buffer 里只有像素信息，它已经做好了布局之类的。
这样 canvas 只做绘图，而把计算交给了 wasm。或者说大部分情况下都是用的 canvas，相当于 canvas 成了最基本的组件。
如果 canvas 再使用 webgl 来绘图，性能会不会更好一点儿？
这样是不是更容易实现跨平台？
但我不确定，这样的话性能会如何？各位有没有这方面的研究？一起探讨下
 |
1
kamilic 2019-08-23 13:25:08 +08:00
flutter?
|
 |
2
VDimos OP @kamilic flutter 原理不了解，不是直接编译两套代码吗？用 wasm 的话可以忽略掉平台差异
|
 |
3
userdhf 2019-08-23 13:31:45 +08:00
想法挺好，是不是以后网页直接贴张设计稿上去，监听点击位置就好了...
|
 |
4
nicoljiang 2019-08-23 13:31:49 +08:00
感兴趣，静候大佬作答。
|
 |
5
love 2019-08-23 13:54:09 +08:00
然后不断加功能，再实现一遍 DOM
|
|
6
VDimos OP @love 没必要实现 dom 那么复杂的标准，如果只实现基本的功能呢？我记得国外是有全部用 canvas 实现的应用？
|
 |
7
murmur 2019-08-23 14:00:07 +08:00
可以，没必要，以前 react 就有 canvas 实现的版本，后面还是用了 react native
|
 |
8
tabris17 2019-08-23 14:03:05 +08:00
即便 canvas 渲染能力出众，wasm 性能贴近原生，但是真的能保证用 canvas 实现一套 ui 组件的性能可以接近原生 html 吗？
|
 |
9
augustheart 2019-08-23 14:11:35 +08:00
估摸了一下，可能要分你最终做的是什么东西吧。不过性能更好这个基本上不可能。
这东西就好比客户端的 duilib，会省去一些系统组件间的交互，某些方面可能会快一点，但是要综合起来谈性能更好，同样的渲染条件下没可能。 |
 |
10
Cooky 2019-08-23 14:17:30 +08:00 via Android
qt webgl 那个？
|
 |
11
momocraft 2019-08-23 14:20:05 +08:00
字体，排版，样式，每一个都是无底深坑
|
 |
12
loginbygoogle 2019-08-23 14:48:40 +08:00 via Android
不说性能问题，就一个简单的输入框控件就够你折腾
|
|
13
VDimos OP @loginbygoogle 主要就是性能允许与否
|
 |
15
gchxp 2019-08-23 16:08:20 +08:00
重复造了一个 js 游戏引擎？
|
 |
17
random0O 2019-08-23 16:35:05 +08:00 via Android
accessibility 也是个问题
|
 |
19
sujin190 2019-08-23 17:12:14 +08:00
没多大用吧，用户层缓冲帧率上不去，不直接用 canvas 绘图，你显卡不是毛用没有了
绘图渲染还是要用 canvas 直接完成，排版倒是可以用 wasm，感觉也比不了浏览器直接的体验更好吧 |
 |
20
MMMMMMMMMMMMMMMM 2019-08-23 17:13:02 +08:00
可以，但是应用场景不会多
因为现有的 web 无论是常规 site 还是 pwa，大部分瓶颈都不在性能上 游戏可能用的上，但是人家游戏引擎就是专门做这个的，unity,ureal 貌似现在都能直接发布到 Webassembly 了 强行 port 过去，重写一遍现有业务，npm 替代品没有的轮子再造一遍，你看大公司们乐意不 个人自己玩玩倒蛮有意思的 |
 |
21
exip 2019-08-23 17:19:04 +08:00 via Android
会不会出现把计算密集的实时性又不高的东西直接放到客户这边，类似 js 挖矿，只不过性能更高一点？
|
 |
22
doublleft 2019-08-23 17:44:41 +08:00
|
 |
23
secondwtq 2019-08-23 21:15:14 +08:00 via iPad  2
我看 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 ）的意思？ 楼主的意思就是，我能不能在一个“渣男框架”里面再嵌套一个“渣男框架”，理论上显然是可以的，你甚至可以继续嵌套 ... 至于实际有多大意义，那就是另一个话题了 |
 |
24
janus77 2019-08-23 21:28:33 +08:00
你只讨论了 UI 部分
我们说跨平台，不止包括 UI 部分，还有 界面交互——输入和输出，随数据动态 硬件交互——照相 定位 声音 还有各类设备上的独有功能（比如电话短信等） 如果这些都交给 WAS 来做，那么就是传统的 VM 模式了 如果这些交给设备本身来做，那就是目前的跨平台模式：在各设备里面嵌入一个处理层（比如手机上的 js 引擎），剩下的交给原生。 |
 |
25
areless 2019-08-23 21:58:51 +08:00
十多年前一个后端大佬看到我写前端，他说，你完全可以用 JS 生成并控制 DOM，这样更快。我还跟他争论前端讲究的是精简，class 或 id 用单字母就可以，能不使用 JS 就不使用，CSS 要兼容度 IE4.0 800 乘以 600 屏，2G 网络的 WAP 页要适配压缩中转后的一系列手机浏览器。
|
 |
26
agagega 2019-08-24 09:03:42 +08:00 via iPhone
Flipboard 这样搞过。
两年前也看过新闻，理论上 React 这种东西也可以输出到 DOM 以下的浏览器渲染层，不知道有没有下文。 |
 |
28
wsxyeah 2019-08-24 10:38:39 +08:00 via iPhone
“用 wasm 做计算”具体是指计算啥？
|
 |
29
starsriver 2019-08-24 17:46:33 +08:00 via Android
现在 js 也可以多线程计算，至于 canvas，我曾经想过这么干，后来放弃了。本来浏览器内核就干了这么一回事，你再浪费资源进行渲染，简直疯了。
|
Select Language