posted by wap, platform: 小米 红米 NOTE
从Asm.js到WebAssembly

Firefox、Chromium、Edge（M$）和WebKit的工程师联合发起了一个源于Asm.js的新项目WebAssembly，它是一个二进制格式，本地解码速度比JS解析快得多（测试显示超过20倍），在移动设备上的使用体验更好。JavaScript作者Brendan Eich指出，Asm.js面临的一个问题是它的解析速度，这在移动设备上尤其致命，WebAssembly 让JS得到解脱，它不是取代而是补充JS。在可预见的未来JS不会消失。Brendan Eich说这是双赢。WebAssembly文件名后缀.wasm，它将支持广泛的编程语言。该项目已经获得了Mozilla、Google和微软的支持，苹果可能也会支持，参与该项目的WebKit工程师是苹果雇员。

=≠==============…………

牛逼，支持多种语言，很可能是llvm了，到时候移动设备也可以受益。

posted by wap, platform: Chrome

引用:

原帖由 @u571  于 2015-6-17 18:35 发表
可以绕过浏览器直接访问API么？

带我去查查看，我想可能类似JVM

posted by wap, platform: Chrome
边看边翻译：

开发的动机：有两个好处，一个是因为是直接的二进制代码所以比asm.js的js代码载入、解码的速度要快，二来是文件尺寸会小。在项目的github说明页面上注明了速度可能会有超过20倍提升（很正常，不用从js翻译到asm了，直接原生直接处理），大小也是asm.js的一半甚至1／3。

开发语言早期关注于C/C++上，可以方便的访问js写的库、js、DOM和Web API，使用LLVM编译，而且可以用右键查看源代码的方式看到代码！

posted by wap, platform: Chrome

引用:

原帖由 @elia  于 2015-6-17 18:57 发表
手机开机就进浏览器？没联网的怎么办？

和webapp一样，你下载安装好了，不需要联网也能用啊

posted by wap, platform: Chrome

引用:

原帖由 @卖哥  于 2015-6-17 18:51 发表
原来是把其他语言编译成Asm.js让浏览器做最后一步把Asm.js转成汇编
而这个WebAssembly其实把浏览器对代码的影响完全踢开了吧，打算直接在网页里嵌汇编，确实是把浏览器当操作系统用，浏览器只提供运行环境。

问题是，这样还能跨平台么？

各浏览器自己实现同样的底层，类似VM，然后用clang/LLVM生成二进制代码，就可以跨了。

他们还准备做基于CDN的动态链接库，就是常用的库直接放在CDN上，需要动态链接的时候直接从网络上取，不用本地存放一份了，貌似天朝要跪……

posted by wap, platform: Chrome

引用:

原帖由 @TUT  于 2015-6-17 21:00 发表
楼主对操作系统的概念理解有偏差，简单的说在硬件和浏览器之间那一层才叫操作系统，浏览器要取代操作系统那它一定要集成了操作系统的基本功能，例如硬件初始化、系统调用接口（对js或同类语言的解析勉强说、内存管理、进程管理、设备驱动、文件系统等。

我没说这个就能成为操作系统，只是说离那个阶段不远了。如今Firefox OS，ChromeOS从广义的角度都能定义为操作系统。

posted by wap, platform: Chrome

引用:

原帖由 @流浪的枪骑兵  于 2015-6-17 21:05 发表
10L过于认真了, LZ的意思只是表达浏览器已经非常接近操作系统的重要功能, 也就是随意运行二进制代码这个功能
我的理解, Web API的确可以在一定程度上替代操作系统的API

恩恩，就是这个意思。而且如果浏览器在FireFoxOS和ChromeOS上，已经是介于内核与APP之间的层面了，并提供图形、窗口之类的API，这已经算是比较底层的玩意了。如果能直接跑二进制代码，并且浏览器能抹平各类底层OS的差异，提供统一的API接口的话，搞不好会改变很多东西。

posted by wap, platform: Chrome

引用:

原帖由 @流浪的枪骑兵  于 2015-6-17 21:25 发表
我并不是太赞同你的观点, 因为我现在就有在做firefox os相关应用
从我个人的感觉, 这些年web api增强了太多, 单页应用可以做到很多过去不可想象的事情
但是, 在可预见的将来, web api提供的功能还是远远不够
举个具体的例子, 访问通讯录, 在android上, 可以通过contact provider来做, 在firefox os上, 需要通过contacts api, 而这个api, 不可能成为标准web api
当然解决办法也是有的, 用web service直接提供接口, 不过这就要求随时联网, 几年之内似乎还不可能

当然,这块现在大家都是在探索, 想象空间是很大的, 所以我不敢说的太死, 唯一确定的一点是, mozilla定的接口实在让人不爽.

通讯录之类的……，估计短期不行。

我觉得短期可能出现的，是各类音频、视频、2D3D图形方面的各种玩意。估计做游戏这种东西比较合适。

其它方面我觉得暂时提供一个统一接口的可能性不大。

posted by wap, platform: Chrome

引用:

原帖由 @TUT  于 2015-6-17 21:24 发表
这。。叫虚拟机或runtime environment适合些。

就是这个意思啦。

posted by wap, platform: Chrome

引用:

原帖由 @流浪的枪骑兵  于 2015-6-17 21:37 发表
做游戏的话, 技术上是可行了
不过考虑到各种浏览器和运行环境以及网络性能的不确定性, 游戏规模不可能太大, 再加上开发成本的考虑, 我还是不太看好,
我觉得恐怕只会有些技术demo出来, 想大行其道还需要各种基础设施, 比如更高带宽网络和高性能设备, 普及起来才有进一步发展的可能

现在也有比较成熟的浏览器端游戏引擎了

posted by wap, platform: 小米 红米 NOTE

引用:

原帖由 @国家重点型号  于 2015-6-18 11:44 发表
老大，1997年他们就是这么说的，未来属于web app，大家都不要学mfc了
结果18年后的今天，前端技术早都翻天覆地了，本地应用照样活得好好的
2010年他们又说，未来属于移动端web app，大家都不要学java oc了
结果5年后的今天，mas销售额还是打着滚地上涨，h5 app只见影子
思而不学则殆，建议楼主写写代码试试。就性能，功能这两点上讲，web app取代native app，五年也没戏

我不觉得Web app是将来啊，现在发展已经很快了，很多地方都在使用Web app了，很多都是混合代码，连offices这种生产力工具都推Web版我觉得很说明问题。

posted by wap, platform: Chrome

引用:

原帖由 @国家重点型号  于 2015-6-18 13:56 发表
那我们的观点是一致的。本地和网页各自发挥长处
我之前的回帖主要是针对标题

我说话兴奋起来就会有点夸张，哈哈