0%

WebAssembly 遐想

上次去省图偶然看到了《WebAssembly 实战》一书,之前就有关注到,于是就借了回来,刚好趁清明假期看看。之前有写过一篇《初试WebAssembly》,本身Rust语言不熟,虽然我买了本《Rust权威指南》,但一直没有什么项目可以练手,基本上没有进展。《WebAssembly 实战》一书是基于C/C++的,相对来说读起来障碍不大。实际我也跑了一个例子试了下,当然如果真拿C/C++来写Web应用的话,估计会很奔溃了。接着我又看了好几个关于WebAssembly的视频演讲,发现有了新的想法。

推出WebAssembly这个东西主要是因为现有的优化已经无法满足性能的进一步提升了,语言肯定不能大改了,JS这么用的广。记得早些年使用Flash的时候,那会是在嵌入式上跑AS2,性能的问题真的是让我当时无语。后来又推出了AS3性能又大幅的提升,但是很长一段时间,我们公司的引擎没有升级,所以我基本上还是用AS2。虽然现在的Web开发没有像当年那样,毕竟开放的环境还是不一样。回到正题,如果单纯的写WebAssembly的话,好像也没有这个必要,而且据说和JS的调用开销不小,所以到底什么时候用,是个问题。反过来想要是哪天整个的Web可以大部分都用WebAssembly来写的话,那就好了,不过目前还不能直接操作Dom,这是一个很大的问题,理论和JS是相互调用的,我看到Rust有个web_sys的库,可以操作dom,不过我想应该也是自己实现的吧。目前看到几个Rust的例子,是直接用WebAssembly来写整个的Web应用的,比如Yew这个Rust的框架允许你构建基于WebAssembly的应用。另外微软的Blazor,允许使用C#来编写基于WebAssembly的单页应用。还有Go的Vugu。

所以如果和JS混着用,那么实际上是把WebAssembly作为一个计算密集型的一个解决方案吧,实际开发中大部分的Web应用都是些轻客户端,主要还是界面相关的操作了,其实大部分情况下很难想到用WebAssembly了,这也是我最早尝试时的感想。但是如果未来解决了类似调DOM的成本比较高的的问题,那么有没有可能Web语言变成Rust为主,为什么是Rust呢?首先WebAssembly本身没有垃圾回收,内存是手动处理了。Rust呢?标榜的是一个没有垃圾回收的安全语言,与C/C++相比实际上是语言层面上处理内存管理的问题。这么一想Rust与WebAssembly真是绝配,当然其他的语言也可以编译成WebAssembly,但对于垃圾回收的语言,是比要实现一个垃圾回收的运行时环境,这样性能上就会有折扣。

总结

想来想去,最终落到Rust这个语言上了,或者说WebAssembly本身的设计这种在底层改变的东西无疑为未来提供了各种改变的可能性,即使不是Rust也许会是其他的语言。C/C++用户可以让现有的库移植到Web上使用,另外Web应用一定是现在这样的轻客户端的类型吗?WebAssembly的引入确实提供另一种可能。另外一定要用JS来写Web应用吗?过去是没有办法,但是底层的改变让未来可以使用统一基于WebAssembly的语言来写Web成为了可能,而不像过去所有新的语言实际上都得编译成JS。基于WebAssembly的框架,有微软这样的大厂,也有基于Go的,某种程度这是一场大厂利好的事,但坏处是当有各种的语言可以写Web时,会不会有点分裂,毕竟只学一个JS,大家共用资源,而用不同的语言有学习成本。