这是一个创建于 1840 天前的主题，其中的信息可能已经有所发展或是发生改变。
除了 HTML、CSS 与 JavaScript，现在 WASM 也是标准 Web 语言 https://m.ithome.com/html/461467.htm
看到这个新闻，第一反应是又要学新语言了。细看之下，可能不用学新语言，但新的里程已经开启了。因为人家已经说了：
Ending 定律也称为终结者定律，它是 Ending 在 2016 年 Emscripten 技术交流会上给出的断言：所有可以用 WebAssembly 实现的终将会用 WebAssembly 实现。（ from： https://zh.wikipedia.org/wiki/WebAssembly ） 注：WebAssembly，即 WASM
理论上能编译成 LLVM 的语言，都能编程成 WASM，从而在浏览器上运行。（这家伙是跑在浏览器上的汇编语言么？这是 Java Applet 的加强版么？）然后那些没有 Web 版的软件，理论上都能在浏览器上跑了。信息量太大了！
Go 1.11 已支持 WASM。然后我写了个 GO 程序可以在浏览器跑了，界面直接使用 HTML 输出？
再看看那个只有浏览器的 Chrome OS。以前总是有评论说这系统太超前了，现在终于明白了。有了 WASM，未来的操作系统真的只需装个浏览器了。（呃，所以 FireFox OS 会重生么？）
此时已 high 爆，不敢再想下去……
 |
1
maomaomao001 2019-12-06 22:54:16 +08:00
可还是感觉没根本没有放开能力啊
你看看这个， https://gdevelop-app.com/ 作为游戏引擎，别说时离线运行了， 连 测试运行都要连云服务的样子 说到底还是没法做真正的本地应用 https://v2ex.com/t/612877#reply57 |
|
2
maomaomao001 2019-12-06 22:55:49 +08:00
而且，这个 https://bytecodealliance.org/ 字节码联盟，谷歌好像都没参与的样子
|
 |
3
Pastsong 2019-12-06 22:59:18 +08:00
好事啊，不过现在很多 WASM 标准还不成熟，浏览器实现也七七八八的，过几年再看看
|
 |
4
momocraft 2019-12-06 23:05:36 +08:00
看个新闻就沸腾不值得. 可以先用一下看看离你的 high 有多远.
|
 |
5
fox0001 OP @maomaomao001 #1
1 ）那个游戏引擎的离线运行的问题，我不清楚。但理论上是可以实现下载后，断网运行（除非要联网获取数据、文件之类） 2 ）不能做真正的本地应用。应该是看到老 IE 那个 ActiveX 控件爆出的诸多安全漏洞而限制的，未来会否实现安全地放权，那是以后的事情了 3 ） wiki 上提到 WASM 的开发团队分别来自 Mozilla、Google、Microsoft、Apple，代表着四大网络浏览器 Firefox、Chrome、Microsoft Edge、Safari。你提到的字节码联盟，好象是想搞个本地版的 WASM，而不是 Web 上的 WASM。 |
|
6
fox0001 OP @momocraft #4 正如 3 楼所言，目前还不成熟。虽然公司的项目目前不会用到，但是既然成为标准，而且各大浏览器都支持，还是值得玩玩
|
 |
7
ochatokori 2019-12-06 23:18:43 +08:00 via Android
前端又可以学习新知识了？
|
 |
8
alphatoad 2019-12-06 23:19:55 +08:00 via iPhone
前端也得学编译原理了哈哈哈哈哈
|
|
9
fox0001 OP @ochatokori #7 不，是后端可以玩前端了
|
|
10
momocraft 2019-12-06 23:31:35 +08:00  2
我更看好 wasm 在浏览器外的应用:
- 作为一种独立于 cpu arch 和 os 和源语言的, 对编译优化友好的中间语言 (不过这条路很长, 现在连个跨源语言的 abi 都没有) - 作为一种权限和调度更可控的沙盒语言 浏览器联盟中的 fastly 的 lucene 就是 wasm 到 native 的编译器, 已经用在 fastly 自己的 edge cloud 了. |
|
11
momocraft 2019-12-06 23:32:20 +08:00
#10: 记错了, 那个编译器叫 lucet
|
 |
12
cest 2019-12-07 00:35:16 +08:00 1
write once, debug everywhere
|
 |
13
Austaras 2019-12-07 00:38:28 +08:00
奇妙的是 w3c 的通告下面只有 6 个中国公司。。。深表不安
|
 |
14
someonetwo 2019-12-07 00:44:50 +08:00
前端的门槛是越来越高了
|
 |
15
inhzus 2019-12-07 00:47:26 +08:00 via Android
看到 getting started 示例的 hello.c C++程序员留下了感动的泪水
|
 |
16
Mohanson 2019-12-07 01:46:08 +08:00 via Android
我前些年写的 wasm 虚拟机，是最早的纯 py 实现的 wasm 虚拟机：
https://github.com/mohanson/pywasm 现在 wasm 这门技术问题还很多，比如定位不准…说是给前端用，结果现在来玩的都是系统和底层的家伙，有拿来做嵌入式的，做区块链的，就是很少见到有人拿来写网页… |
 |
17
DOLLOR 2019-12-07 01:52:04 +08:00
已经有灰产开始利用 WASM 来挂挖矿程序了，性能比 JS 强，还更隐蔽。
|
 |
19
cxe2v 2019-12-07 02:06:58 +08:00
前几年已经激动过一波了，还是等等再看吧
|
 |
21
Buges 2019-12-07 05:29:03 +08:00 via Android
@momocraft 权限更可控吗。。这玩意感觉非常靠近“native”，越 native，API 靠近底层就越是难以“可控”，一直觉得一个现代的操作系统就该把所有东西套到一层 VM 里，实现更具体更精细的调度管理。
把 native 搬进 Web 总有一种开当年 IE 的 dao.车的感觉，也不知道会不会重蹈覆辙。 |
 |
22
prenwang 2019-12-07 08:36:14 +08:00
qt 的程序只需要加个参数运行就能用浏览器打开操作，就是 WASM，但是只在预览阶段， 两个明显问题， 同时只能一个连接，加载比较慢，操作起来是真的强大。
估计还要等等，值得期待。 |
 |
23
trait 2019-12-07 08:50:48 +08:00 via Android
wasm 应用很广，rust 里面甚至能做个单独的宏解析器外挂加快编译速度
|
 |
24
murmur 2019-12-07 08:54:24 +08:00
IE 不支持 wasm，所以再等等
|
|
25
murmur 2019-12-07 09:01:52 +08:00
前端的主要形式还是网页，瓶颈还是卡渲染能力，真要性能要么 unity 要么 native，选 wasm 提升 js 性能干嘛，除了加密用，挖矿？
|
 |
31
love 2019-12-07 11:39:27 +08:00
@murmur 目前的 h5 都用的是啥技术？人家目前做得怎么样，不代表浏览器没有能力。
https://docs.unity3d.com/Manual/webgl-performance.html 看第一段话 |
 |
32
hst001 2019-12-07 11:43:34 +08:00 via Android
只是对于计算量大的应用有用，一般的应用用不到这个，因为 UI 渲染还是得用传统的方式，所以没什么好嗨的
|
 |
33
flyzero 2019-12-07 14:15:43 +08:00
wasm 好像是沙盒的吧，有好多限制
|
 |
34
wangyzj 2019-12-07 16:58:45 +08:00
来吧
前端不如一起来写 cgi 吧 |
|
35
fox0001 OP @momocraft #10 纯个人看法，我不看好浏览器外的应用。对于 C、Go 这种语言，直接编译成本地执行代码，更能压榨机器性能。编译一次，到处运行的想法，必然带来性能的牺牲。
未来就看大佬们怎么玩了。上一个带着这种想法的语言，Java，最终沦为它本身没有想过的 Web 服务语言。 |
|
38
fox0001 OP @someonetwo #14 前端还是前段，只是后端过来拍拍肩膀“让我来”
|
 |
40
yksoft1test 2019-12-07 17:48:48 +08:00
问题是 Web 浏览器的这个模型，桌面软件的移植还是有很多困难的。
|
 |
42
dioxide 2019-12-07 17:56:32 +08:00
意味着 Web 端可以搞二进制部署了，不再像 JS 那样透明了...
|
|
43
yksoft1test 2019-12-07 17:56:52 +08:00
目前也只有使用 SDL 的那些软件比较容易移植到 Emscripten 平台，其他的基本也仅限于一些库之类。ffmpeg 见过好几个地方用 emscripten 版得了
|
 |
44
Athrob 2019-12-07 19:52:10 +08:00
突然就想到未来网络跟电力一样是必备的, 不再有带宽或线路之分.
假如网络是万兆起步的时候 玩个游戏还要下载客户端吗? 看个高清还要下到本地吗? 会不会改变生活呢. |
|
45
murmur 2019-12-07 20:43:57 +08:00 1
@Athrob 那个时候你的 MX250 就达到 MX1080ti 的级别了，云 3A 和云独~立小游戏还是有区别的，就算一个人分一个 1060 的显卡，一个机房的机器够多少人玩游戏，服务器 U 这种低频他就不适合打游戏
|
 |
46
Rorysky 2019-12-07 21:32:38 +08:00
还比较远，应用前景有限，有什么场景是 wasm 非用不可，或者说 明显受益的么？
|
 |
47
FrankHB 2019-12-07 22:25:11 +08:00
原来搞 Web 的另说，对圈外人来讲，撑死就是又多了个争风吃醋的 target 多找点事添乱而已。（对不少应用开发者来讲，还不如整活个干净点的 XUL 有意义。）
WASM 一开始的设计还有些新玩意儿，不过 AST 出局以后 Web 外也没什么标新立异的资本了。大概名字是原罪吧。 |
|
49
FrankHB 2019-12-07 22:37:17 +08:00
LLVM IR 是没戏一桶浆糊的。这玩意儿它存在的意义主要是让脑子不够好使到接受不了 CPS 之类的用户读写而已——然而这样的用户本来就不成气候；而 explicit SSA IR 远远也没简单到让剩下大多开发者日常能看能写的程度。因为本质上在结构化扩展性上是残的，根本不可能通过语法扩展取代高级语言前端之间的翻译；想自己扩充功能的用户有 IR 也多大没卵用，照样要跪在不稳定的 API 面前。
WASM 原来有甩掉这个缺陷的机会，不过给它自己糟践了，不提也罢。不过可笑的是，诸如格林斯潘第十定律和这里山寨的所谓的终结者定律原始都是用在具有（或者至少理论上允许直接修改局部特性扩充出来）同像性的语言上，WASM 这个恰恰就把这坨阉了……年轻人，还真敢说啊。 现在大抵是看透了，以二进制规格开始吹的，要么老实点不要想着一桶浆糊，否则还是都凉凉好了，别没事找事。 |
|
53
FrankHB 2019-12-08 00:20:16 +08:00
@Athrob 光速有限是指响应上的物理限制会让空间换时间的策略失效而必须从设计之初正面应对做好变通。比如说，现在的时钟频率已经让集成电路布线已经要考虑这个限制了。当然，网络没那么极端，但因为因果律限制，凡涉及到用户输入输出的交互，会有同样来自光速的限制。比如在线游戏用户的操作，几十毫秒的延迟可能就是省不掉的。所以只要尺度够大，物理上近一些的在一些关键问题上就是一定更占便宜，有时候可能会决定可行性；网络技术再怎么发展这都没法改变。
能改善的主要是吞吐量。但就算技术允许上限提高和单位传输的数据成本下降，这里总成本一直感人嘛……而且和计算资源一样，很难想象带宽过剩是什么情况。“网络跟电力一样是必备的，不再有带宽或线路之分”最后无非是用户不需要计较带宽具体有多少。然而物理上这些资源不可能凭空生出来，就要服务商做基建投入。羊毛是出在谁身上的呢…… |
Select Language